From xuelei.fan at oracle.com Tue Apr 1 23:16:50 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 02 Apr 2014 07:16:50 +0800 Subject: Review Request of JDK Enhancement Proposal: DTLS In-Reply-To: <532A25EA.7040802@oracle.com> References: <532A25EA.7040802@oracle.com> Message-ID: <533B48E2.6050109@oracle.com> Here is the updated version: http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v01.txt The updates include: 1. added that PMTU discovery is not a goal to consider PMTU discovery in this JEP. 2. Updated the description section so that it is easier to understand. Thanks, Xuelei On 3/20/2014 7:19 AM, Xuelei Fan wrote: > Hi, > > Please review the JDK Enhancement Proposal, Support Datagram Transport > Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347) in the > JSSE API and the SunJSSE security provider. Detailed, please refer to > the draft JEP: > > http://cr.openjdk.java.net/~xuelei/7093601/jep-dtls-v00.txt > > Feel free to make comment and send your feedback to the alias. > > Thanks, > Xuelei > From xuelei.fan at oracle.com Tue Apr 1 23:19:25 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 02 Apr 2014 07:19:25 +0800 Subject: Review Request of JDK Enhancement Proposal: OCSP stapling In-Reply-To: <532A2455.9080902@oracle.com> References: <532A2455.9080902@oracle.com> Message-ID: <533B497D.1010304@oracle.com> Here is the updated version: http://cr.openjdk.java.net/~xuelei/8034248/jep-csre-v01.txt Updated the description section and a few words so that it is easier to understand. Thanks, Xuelei On 3/20/2014 7:12 AM, Xuelei Fan wrote: > Hi All, > > Please review the JDK Enhancement Proposal, support OCSP stapling in > SunJSSE security provider. Detailed, please refer to the draft JEP: > > http://cr.openjdk.java.net/~xuelei/8034248/jep-csre.txt > > Feel free to make comment and send your feedback to the alias. > > Thanks, > Xuelei > From weijun.wang at oracle.com Fri Apr 4 11:00:27 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 4 Apr 2014 19:00:27 +0800 Subject: RFR 8029995: accept yes/no for boolean krb5.conf settings In-Reply-To: <52E82549.7090705@oracle.com> References: <87A22155-BEB1-467C-82F2-A7E179115311@oracle.com> <52E82549.7090705@oracle.com> Message-ID: Updated webrev at http://cr.openjdk.java.net/~weijun/8029995/webrev.01 Several differences: 1. Only true/false/yes/no are supported now. 2. Some words in javax/security/auth/kerberos/package-info.java 3. getBoolean() renamed to getBooleanObject() because it's quite easy to forget the return value is a Boolean (instead of boolean) and could be null. Thanks Max On Jan 29, 2014, at 5:46, Sean Mullan wrote: > On 01/28/2014 03:53 AM, Wang Weijun wrote: >> Please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8029995/webrev.00/ >> >> The supported boolean values in this fix cover what MIT krb5 does and >> we also added 'f'. >> >> The old getBooleanValue() method returns true for ?true? and false >> otherwise but the new method returns null if the value is not >> supported. I?ve carefully changed how the method is called to ensure >> maximum compatibility, but there is still one left: >> >> We support DNS lookup for realm name by default, which means we do it >> if dns_lookup_realm is not set to false, or when unset, if >> dns_fallback is not set to false. Before this change, when >> dns_lookup_realm is set to ?unknown?, it means false so DNS lookup is >> not performed. After this change, it?s equivalent to dns_lookup_realm >> unset, and dns_fallback is used. I think the current behavior is >> better than the old one. > > I agree, but since it is a behavior change, it should be specified in the CCC and release notes. > > Fix looks fine otherwise. > > --Sean > From sean.mullan at oracle.com Fri Apr 4 13:07:36 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 04 Apr 2014 09:07:36 -0400 Subject: RFR 8029995: accept yes/no for boolean krb5.conf settings In-Reply-To: References: <87A22155-BEB1-467C-82F2-A7E179115311@oracle.com> <52E82549.7090705@oracle.com> Message-ID: <533EAE98.7020702@oracle.com> Looks fine, just one nit. On line 241 of Config.java can you add braces to the if-clause? Thanks, Sean On 04/04/2014 07:00 AM, Wang Weijun wrote: > Updated webrev at > > http://cr.openjdk.java.net/~weijun/8029995/webrev.01 > > Several differences: > > 1. Only true/false/yes/no are supported now. > > 2. Some words in javax/security/auth/kerberos/package-info.java > > 3. getBoolean() renamed to getBooleanObject() because it's quite easy to forget the return value is a Boolean (instead of boolean) and could be null. > > Thanks > Max > > On Jan 29, 2014, at 5:46, Sean Mullan wrote: > >> On 01/28/2014 03:53 AM, Wang Weijun wrote: >>> Please review the fix at >>> >>> http://cr.openjdk.java.net/~weijun/8029995/webrev.00/ >>> >>> The supported boolean values in this fix cover what MIT krb5 does and >>> we also added 'f'. >>> >>> The old getBooleanValue() method returns true for ?true? and false >>> otherwise but the new method returns null if the value is not >>> supported. I?ve carefully changed how the method is called to ensure >>> maximum compatibility, but there is still one left: >>> >>> We support DNS lookup for realm name by default, which means we do it >>> if dns_lookup_realm is not set to false, or when unset, if >>> dns_fallback is not set to false. Before this change, when >>> dns_lookup_realm is set to ?unknown?, it means false so DNS lookup is >>> not performed. After this change, it?s equivalent to dns_lookup_realm >>> unset, and dns_fallback is used. I think the current behavior is >>> better than the old one. >> >> I agree, but since it is a behavior change, it should be specified in the CCC and release notes. >> >> Fix looks fine otherwise. >> >> --Sean >> > From vincent.x.ryan at oracle.com Fri Apr 4 15:45:39 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 4 Apr 2014 16:45:39 +0100 Subject: [9] review request for 6977937: The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from SunJCE. Message-ID: <3F03DF2F-6C55-412F-8ED1-B05E5E6B6873@oracle.com> Hello, Please review the following fix to remove the requirement for the Mac algorithm used by a PBKDF2 algorithm to be supplied by the SunJCE provider. The SunJCE provider is still preferred (for compatibility with previous releases and for performance reasons) but it is no longer required. The com.sun.crypto.provider.PBKDF2KeyImpl class first searches SunJCE for the required Mac algorithm but fails over to searching the other installed JCE providers too. Bug: https://bugs.openjdk.java.net/browse/JDK-6977937 Webrev: http://cr.openjdk.java.net/~vinnie/6977937/webrev.00/ Thanks. From vincent.x.ryan at oracle.com Fri Apr 4 17:08:40 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 4 Apr 2014 18:08:40 +0100 Subject: Review request for JDK 9 Enhancement Proposal: Transitioning to a new default keystore type Message-ID: <3C2902B4-71C4-4EEF-B30C-11CCE08C389E@oracle.com> Hello, Please review this JDK 9 Enhancement Proposal to transition the default keystore type for the Java platform from Java keystone (JKS) to PKCS12, for improved security. The draft JEP is available at: http://cr.openjdk.java.net/~vinnie/jks-jep.txt Comments are welcome. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bradford.wetmore at oracle.com Fri Apr 4 21:23:43 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 04 Apr 2014 14:23:43 -0700 Subject: [9] review request for 6977937: The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from SunJCE. In-Reply-To: <3F03DF2F-6C55-412F-8ED1-B05E5E6B6873@oracle.com> References: <3F03DF2F-6C55-412F-8ED1-B05E5E6B6873@oracle.com> Message-ID: <533F22DF.3060605@oracle.com> With the current and proposed code, you are effectively requiring the MAC come from JCE, as all the algorithms exist in SunJCE. IIRC, when we discussed the previous change in this area, the idea was that the MAC would follow the standard JCA provider priority ordering. Brad On 4/4/2014 8:45 AM, Vincent Ryan wrote: > Hello, > > Please review the following fix to remove the requirement for the Mac algorithm used by a PBKDF2 algorithm to be supplied by the SunJCE provider. > The SunJCE provider is still preferred (for compatibility with previous releases and for performance reasons) but it is no longer required. > The com.sun.crypto.provider.PBKDF2KeyImpl class first searches SunJCE for the required Mac algorithm but fails over to searching the > other installed JCE providers too. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6977937 > Webrev: http://cr.openjdk.java.net/~vinnie/6977937/webrev.00/ > > Thanks. > From vincent.x.ryan at oracle.com Sat Apr 5 15:00:44 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 05 Apr 2014 16:00:44 +0100 Subject: [9] review request for 6977937: The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from SunJCE. In-Reply-To: <533F22DF.3060605@oracle.com> References: <3F03DF2F-6C55-412F-8ED1-B05E5E6B6873@oracle.com> <533F22DF.3060605@oracle.com> Message-ID: <53401A9C.5090304@oracle.com> I was concerned about the impact on applications of a different JCE provider being selected instead of SunJCE, on some platforms. I can change the fix to follow the standard JCE provider ordering. On 04/04/2014 22:23, Bradford Wetmore wrote: > With the current and proposed code, you are effectively requiring the > MAC come from JCE, as all the algorithms exist in SunJCE. > > IIRC, when we discussed the previous change in this area, the idea was > that the MAC would follow the standard JCA provider priority ordering. > > Brad > > > > On 4/4/2014 8:45 AM, Vincent Ryan wrote: >> Hello, >> >> Please review the following fix to remove the requirement for the Mac >> algorithm used by a PBKDF2 algorithm to be supplied by the SunJCE >> provider. >> The SunJCE provider is still preferred (for compatibility with >> previous releases and for performance reasons) but it is no longer >> required. >> The com.sun.crypto.provider.PBKDF2KeyImpl class first searches SunJCE >> for the required Mac algorithm but fails over to searching the >> other installed JCE providers too. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6977937 >> Webrev: http://cr.openjdk.java.net/~vinnie/6977937/webrev.00/ >> >> Thanks. >> From xuelei.fan at oracle.com Mon Apr 7 00:35:05 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 07 Apr 2014 08:35:05 +0800 Subject: Code review request, 8028192, Use of PKCS11-NSS provider in FIPS mode broken Message-ID: <5341F2B9.6050309@oracle.com> Hi, webrev: http://cr.openjdk.java.net/~xuelei/8028192/webrev.00/ This update fixes the SunJSSE problem that in FIPS mode, SunJSSE does not work because keys cannot be extracted from crypto device. Thanks, Xuelei From bradford.wetmore at oracle.com Mon Apr 7 19:21:21 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 07 Apr 2014 12:21:21 -0700 Subject: [9] review request for 6977937: The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from SunJCE. In-Reply-To: <53401A9C.5090304@oracle.com> References: <3F03DF2F-6C55-412F-8ED1-B05E5E6B6873@oracle.com> <533F22DF.3060605@oracle.com> <53401A9C.5090304@oracle.com> Message-ID: <5342FAB1.8010303@oracle.com> On 4/5/2014 8:00 AM, Vincent Ryan wrote: > > I was concerned about the impact on applications of a different JCE > provider being selected instead of SunJCE, on some platforms. > > I can change the fix to follow the standard JCE provider ordering. That would be my preference, but I can see both sides if someone has a strong case. Brad > > On 04/04/2014 22:23, Bradford Wetmore wrote: >> With the current and proposed code, you are effectively requiring the >> MAC come from JCE, as all the algorithms exist in SunJCE. >> >> IIRC, when we discussed the previous change in this area, the idea was >> that the MAC would follow the standard JCA provider priority ordering. >> >> Brad >> >> >> >> On 4/4/2014 8:45 AM, Vincent Ryan wrote: >>> Hello, >>> >>> Please review the following fix to remove the requirement for the Mac >>> algorithm used by a PBKDF2 algorithm to be supplied by the SunJCE >>> provider. >>> The SunJCE provider is still preferred (for compatibility with >>> previous releases and for performance reasons) but it is no longer >>> required. >>> The com.sun.crypto.provider.PBKDF2KeyImpl class first searches SunJCE >>> for the required Mac algorithm but fails over to searching the >>> other installed JCE providers too. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6977937 >>> Webrev: http://cr.openjdk.java.net/~vinnie/6977937/webrev.00/ >>> >>> Thanks. >>> > From weijun.wang at oracle.com Tue Apr 8 02:37:48 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 08 Apr 2014 10:37:48 +0800 Subject: RFR 8035986: KerberosKey algorithm names are not specified Message-ID: <534360FC.10309@oracle.com> Hi All Please review the code changes at http://cr.openjdk.java.net/~weijun/8035986/webrev.00/ It's about using IANA names in KerberosKey instead of old non-standard names. Thanks Max From sean.mullan at oracle.com Tue Apr 8 13:43:12 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 08 Apr 2014 09:43:12 -0400 Subject: Review Request for JDK-8038431: Close InputStream when finished retrieving XML Signature HTTP References Message-ID: <5343FCF0.6060503@oracle.com> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038431/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8038431 Thanks, Sean From xuelei.fan at oracle.com Tue Apr 8 13:47:42 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 08 Apr 2014 21:47:42 +0800 Subject: Review Request for JDK-8038431: Close InputStream when finished retrieving XML Signature HTTP References In-Reply-To: <5343FCF0.6060503@oracle.com> References: <5343FCF0.6060503@oracle.com> Message-ID: <5343FDFE.2000709@oracle.com> Looks fine to me. Xuelei On 4/8/2014 9:43 PM, Sean Mullan wrote: > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038431/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8038431 > > Thanks, > Sean From xuelei.fan at oracle.com Tue Apr 8 23:57:49 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Apr 2014 07:57:49 +0800 Subject: RFR 8035986: KerberosKey algorithm names are not specified In-Reply-To: <534360FC.10309@oracle.com> References: <534360FC.10309@oracle.com> Message-ID: <53448CFD.8070102@oracle.com> Looks fine to me. I was wondering, whether it is a little bit more instinctive to return a string with the type number for "unknown" and "private" algorithm in KerberosKey.getAlgorithm(). For example: "unknown" -> "kid-2014" "private" -> "kid-(2014)" Thanks, Xuelei On 4/8/2014 10:37 AM, Weijun Wang wrote: > Hi All > > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8035986/webrev.00/ > > It's about using IANA names in KerberosKey instead of old non-standard > names. > > Thanks > Max From weijun.wang at oracle.com Wed Apr 9 00:53:12 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 09 Apr 2014 08:53:12 +0800 Subject: RFR 8035986: KerberosKey algorithm names are not specified In-Reply-To: <53448CFD.8070102@oracle.com> References: <534360FC.10309@oracle.com> <53448CFD.8070102@oracle.com> Message-ID: <534499F8.60605@oracle.com> There is already getKeyType() and toString(). Also I don't think "kid-2014" is useful. If people really want to inspect the result, I expect they would fall into the "default" or "else" block anyway. --Max On 4/9/2014 7:57, Xuelei Fan wrote: > Looks fine to me. > > I was wondering, whether it is a little bit more instinctive to return a > string with the type number for "unknown" and "private" algorithm in > KerberosKey.getAlgorithm(). For example: > > "unknown" -> "kid-2014" > "private" -> "kid-(2014)" > > Thanks, > Xuelei > > On 4/8/2014 10:37 AM, Weijun Wang wrote: >> Hi All >> >> Please review the code changes at >> >> http://cr.openjdk.java.net/~weijun/8035986/webrev.00/ >> >> It's about using IANA names in KerberosKey instead of old non-standard >> names. >> >> Thanks >> Max > From xuelei.fan at oracle.com Wed Apr 9 01:15:58 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Apr 2014 09:15:58 +0800 Subject: RFR 8035986: KerberosKey algorithm names are not specified In-Reply-To: <534499F8.60605@oracle.com> References: <534360FC.10309@oracle.com> <53448CFD.8070102@oracle.com> <534499F8.60605@oracle.com> Message-ID: <53449F4E.10107@oracle.com> On 4/9/2014 8:53 AM, Weijun Wang wrote: > There is already getKeyType() and toString(). ;-) They should not lower the standards to design another good method. > Also I don't think > "kid-2014" is useful. If people really want to inspect the result, I > expect they would fall into the "default" or "else" block anyway. > There is a constructor to put unknown or private key type: KerberosKey(KerberosPrincipal principal, byte[] keyBytes, int keyType, int versionNum) Which will accept any kind of integer key type. I think it might be help to get the algorithm in string even if key type is not supported (getKeyType() is not as convenient as getAlgorithm() to get the string algorithm, toString() covers too much information if one only needs to know the algorithm). KerberosKey kk = new KerberosKey(..., 123, 0); String alg = kk.getAlgorithm(); // "unknown" returns KerberosKey kk = new KerberosKey(..., 124, 0); String alg = kk.getAlgorithm(); // "unknown" returns KerberosKey kk = new KerberosKey(..., -123, 0); String alg = kk.getAlgorithm(); // "private" returns KerberosKey kk = new KerberosKey(..., -124, 0); String alg = kk.getAlgorithm(); // "private" returns At least for meaningful debug log or exception message, "unknown" and "private" is not as instinctive as "xxx-123" and "xxx-124". Anyway, not a big concern of mine. Please go ahead if you prefer "unknown" and "private". Xuelei > --Max > > On 4/9/2014 7:57, Xuelei Fan wrote: >> Looks fine to me. >> >> I was wondering, whether it is a little bit more instinctive to return a >> string with the type number for "unknown" and "private" algorithm in >> KerberosKey.getAlgorithm(). For example: >> >> "unknown" -> "kid-2014" >> "private" -> "kid-(2014)" >> >> Thanks, >> Xuelei >> >> On 4/8/2014 10:37 AM, Weijun Wang wrote: >>> Hi All >>> >>> Please review the code changes at >>> >>> http://cr.openjdk.java.net/~weijun/8035986/webrev.00/ >>> >>> It's about using IANA names in KerberosKey instead of old non-standard >>> names. >>> >>> Thanks >>> Max >> From weijun.wang at oracle.com Wed Apr 9 01:50:53 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 09 Apr 2014 09:50:53 +0800 Subject: RFR 8035986: KerberosKey algorithm names are not specified In-Reply-To: <53449F4E.10107@oracle.com> References: <534360FC.10309@oracle.com> <53448CFD.8070102@oracle.com> <534499F8.60605@oracle.com> <53449F4E.10107@oracle.com> Message-ID: <5344A77D.6010905@oracle.com> On 4/9/2014 9:15, Xuelei Fan wrote: > On 4/9/2014 8:53 AM, Weijun Wang wrote: >> There is already getKeyType() and toString(). > ;-) They should not lower the standards to design another good method. I just meant different methods serve for different purposes. > >> Also I don't think >> "kid-2014" is useful. If people really want to inspect the result, I >> expect they would fall into the "default" or "else" block anyway. >> > There is a constructor to put unknown or private key type: > KerberosKey(KerberosPrincipal principal, > byte[] keyBytes, > int keyType, int versionNum) > > Which will accept any kind of integer key type. Yes, this method does not need to understand the keyType to generate a key. However, the one we are talking about now must understand the algorithm name and call its string2key() method to generate the key from a passphrase. So even if you provide "kid-2014", it still has to throw an IllegalArgumentException. > > I think it might be help to get the algorithm in string even if key type > is not supported (getKeyType() is not as convenient as getAlgorithm() to > get the string algorithm, toString() covers too much information if one > only needs to know the algorithm). > > KerberosKey kk = new KerberosKey(..., 123, 0); > String alg = kk.getAlgorithm(); // "unknown" returns > > KerberosKey kk = new KerberosKey(..., 124, 0); > String alg = kk.getAlgorithm(); // "unknown" returns > > KerberosKey kk = new KerberosKey(..., -123, 0); > String alg = kk.getAlgorithm(); // "private" returns > > KerberosKey kk = new KerberosKey(..., -124, 0); > String alg = kk.getAlgorithm(); // "private" returns I would expect actual developers calling getKeyType() more often because it's easy to deal with in Kerberos. In this sense, getAlgorithm() only exists to override the method in Key. > > At least for meaningful debug log or exception message, "unknown" and > "private" is not as instinctive as "xxx-123" and "xxx-124". > > Anyway, not a big concern of mine. Please go ahead if you prefer > "unknown" and "private". Yes, that is still my preference. Thanks Max > > Xuelei > >> --Max >> >> On 4/9/2014 7:57, Xuelei Fan wrote: >>> Looks fine to me. >>> >>> I was wondering, whether it is a little bit more instinctive to return a >>> string with the type number for "unknown" and "private" algorithm in >>> KerberosKey.getAlgorithm(). For example: >>> >>> "unknown" -> "kid-2014" >>> "private" -> "kid-(2014)" >>> >>> Thanks, >>> Xuelei >>> >>> On 4/8/2014 10:37 AM, Weijun Wang wrote: >>>> Hi All >>>> >>>> Please review the code changes at >>>> >>>> http://cr.openjdk.java.net/~weijun/8035986/webrev.00/ >>>> >>>> It's about using IANA names in KerberosKey instead of old non-standard >>>> names. >>>> >>>> Thanks >>>> Max >>> > From xuelei.fan at oracle.com Wed Apr 9 02:27:56 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Apr 2014 10:27:56 +0800 Subject: RFR 8035986: KerberosKey algorithm names are not specified In-Reply-To: <5344A77D.6010905@oracle.com> References: <534360FC.10309@oracle.com> <53448CFD.8070102@oracle.com> <534499F8.60605@oracle.com> <53449F4E.10107@oracle.com> <5344A77D.6010905@oracle.com> Message-ID: <5344B02C.40607@oracle.com> > Yes, that is still my preference. OK. Thanks, Xuelei On 4/9/2014 9:50 AM, Weijun Wang wrote: > > > On 4/9/2014 9:15, Xuelei Fan wrote: >> On 4/9/2014 8:53 AM, Weijun Wang wrote: >>> There is already getKeyType() and toString(). >> ;-) They should not lower the standards to design another good method. > > I just meant different methods serve for different purposes. > >> >>> Also I don't think >>> "kid-2014" is useful. If people really want to inspect the result, I >>> expect they would fall into the "default" or "else" block anyway. >>> >> There is a constructor to put unknown or private key type: >> KerberosKey(KerberosPrincipal principal, >> byte[] keyBytes, >> int keyType, int versionNum) >> >> Which will accept any kind of integer key type. > > Yes, this method does not need to understand the keyType to generate a > key. However, the one we are talking about now must understand the > algorithm name and call its string2key() method to generate the key from > a passphrase. So even if you provide "kid-2014", it still has to throw > an IllegalArgumentException. > >> >> I think it might be help to get the algorithm in string even if key type >> is not supported (getKeyType() is not as convenient as getAlgorithm() to >> get the string algorithm, toString() covers too much information if one >> only needs to know the algorithm). >> >> KerberosKey kk = new KerberosKey(..., 123, 0); >> String alg = kk.getAlgorithm(); // "unknown" returns >> >> KerberosKey kk = new KerberosKey(..., 124, 0); >> String alg = kk.getAlgorithm(); // "unknown" returns >> >> KerberosKey kk = new KerberosKey(..., -123, 0); >> String alg = kk.getAlgorithm(); // "private" returns >> >> KerberosKey kk = new KerberosKey(..., -124, 0); >> String alg = kk.getAlgorithm(); // "private" returns > > I would expect actual developers calling getKeyType() more often because > it's easy to deal with in Kerberos. In this sense, getAlgorithm() only > exists to override the method in Key. > >> >> At least for meaningful debug log or exception message, "unknown" and >> "private" is not as instinctive as "xxx-123" and "xxx-124". >> >> Anyway, not a big concern of mine. Please go ahead if you prefer >> "unknown" and "private". > > Yes, that is still my preference. > > Thanks > Max > >> >> Xuelei >> >>> --Max >>> >>> On 4/9/2014 7:57, Xuelei Fan wrote: >>>> Looks fine to me. >>>> >>>> I was wondering, whether it is a little bit more instinctive to >>>> return a >>>> string with the type number for "unknown" and "private" algorithm in >>>> KerberosKey.getAlgorithm(). For example: >>>> >>>> "unknown" -> "kid-2014" >>>> "private" -> "kid-(2014)" >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 4/8/2014 10:37 AM, Weijun Wang wrote: >>>>> Hi All >>>>> >>>>> Please review the code changes at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8035986/webrev.00/ >>>>> >>>>> It's about using IANA names in KerberosKey instead of old non-standard >>>>> names. >>>>> >>>>> Thanks >>>>> Max >>>> >> From will.sargent at gmail.com Wed Apr 9 04:58:30 2014 From: will.sargent at gmail.com (Will Sargent) Date: Tue, 8 Apr 2014 21:58:30 -0700 Subject: Recommendations for disabledAlgorithms? Message-ID: Hi all, I'm writing an HTTPS client for Play, and I would like to give some recommendations in the documentation for the current recommended key sizes in the server handshake and in the X.509 certificate. I'm using the key lengths as defined in http://www.keylength.com, but I am concerned that I may have confused the algorithm names and key sizes, as Diffie Hellman in particular seems to have a number of different relevant key sizes floating around for p and q. The current text of the document is as follows: ----------- The `jdk.tls.disabledAlgorithms` can be used to prevent weak ciphers, and can also be used to prevent small key sizes from being used in a handshake. This is a [useful feature]( http://sim.ivi.co/2013/11/harness-ssl-and-jsse-key-size-control.html) that is only available in JDK 1.7 and later. The official documentation for disabled algorithms is [here]( http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#DisabledAlgorithms ). The parameter names to use for the disabled algorithms are not obvious, but are listed in the [Providers documentation]( http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html ). For X.509 certificates, the public key algorithms used in signatures can be RSA, DSA or EC (listed as "ECDSA"): ``` jdk.certpath.disabledAlgorithms="RSA keySize < 2048, DSA keySize < 2048, EC keySize < 224" ``` The digest algorithms used in signatures can be "NONE, MD2, MD4, MD5, SHA1, SHA256, SHA512, SHA384": ``` jdk.certpath.disabledAlgorithms="MD2, MD4, MD5" ``` For TLS handshakes, the code will match the first part of the cipher suite after the protocol, i.e. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 has ECDHE as the relevant cipher, giving "DHE, ECDH, ECDHE, RSA": ``` jdk.tls.disabledAlgorithms="DHE keySize < 2048, ECDH keySize < 2048, ECDHE keySize < 2048, RSA keySize < 2048" ``` Note that if you set `DHE keySize < 2048`, you will also want to set `jdk.tls.ephemeralDHKeySize=2048` (and be running JDK 1.8). JDK 1.7 has a [bug]( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014618) that may cause Diffie Hellman algorithms to fail 0.05% of the time, so you may want to disable it or upgrade to JDK 1.8. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Apr 9 09:45:08 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 09 Apr 2014 17:45:08 +0800 Subject: RFR 8039575: liberate two manual kerberos tests Message-ID: <534516A4.5000106@oracle.com> Hi All These two tests were changed from @ignore to @manual in JDK-8033271. They can be liberated into automatic tests. Please review the changes at http://cr.openjdk.java.net/~weijun/8039575/webrev.00/ Thanks Max From xuelei.fan at oracle.com Wed Apr 9 10:35:47 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Apr 2014 18:35:47 +0800 Subject: RFR 8039575: liberate two manual kerberos tests In-Reply-To: <534516A4.5000106@oracle.com> References: <534516A4.5000106@oracle.com> Message-ID: <53452283.8070502@oracle.com> Looks fine to me. Xuelei On 4/9/2014 5:45 PM, Weijun Wang wrote: > Hi All > > These two tests were changed from @ignore to @manual in JDK-8033271. > They can be liberated into automatic tests. Please review the changes at > > http://cr.openjdk.java.net/~weijun/8039575/webrev.00/ > > Thanks > Max From anthony.scarpino at oracle.com Wed Apr 9 16:55:19 2014 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 9 Apr 2014 09:55:19 -0700 Subject: [9] review request for 6977937: The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from SunJCE. In-Reply-To: <5342FAB1.8010303@oracle.com> References: <3F03DF2F-6C55-412F-8ED1-B05E5E6B6873@oracle.com> <533F22DF.3060605@oracle.com> <53401A9C.5090304@oracle.com> <5342FAB1.8010303@oracle.com> Message-ID: <70FE7534-6052-43F5-B16C-1587C5B3FFB8@oracle.com> If my memory is right I think performance gains via hardware were limited with MAC algorithms. Also isn't PBKDF2 only for small operations? Because searching for another provider could take longer than doing the operation in SunJCE Tony > On Apr 7, 2014, at 12:21 PM, Bradford Wetmore wrote: > > > > >> On 4/5/2014 8:00 AM, Vincent Ryan wrote: >> >> I was concerned about the impact on applications of a different JCE >> provider being selected instead of SunJCE, on some platforms. >> >> I can change the fix to follow the standard JCE provider ordering. > > That would be my preference, but I can see both sides if someone has a strong case. > > Brad > > >> >>> On 04/04/2014 22:23, Bradford Wetmore wrote: >>> With the current and proposed code, you are effectively requiring the >>> MAC come from JCE, as all the algorithms exist in SunJCE. >>> >>> IIRC, when we discussed the previous change in this area, the idea was >>> that the MAC would follow the standard JCA provider priority ordering. >>> >>> Brad >>> >>> >>> >>>> On 4/4/2014 8:45 AM, Vincent Ryan wrote: >>>> Hello, >>>> >>>> Please review the following fix to remove the requirement for the Mac >>>> algorithm used by a PBKDF2 algorithm to be supplied by the SunJCE >>>> provider. >>>> The SunJCE provider is still preferred (for compatibility with >>>> previous releases and for performance reasons) but it is no longer >>>> required. >>>> The com.sun.crypto.provider.PBKDF2KeyImpl class first searches SunJCE >>>> for the required Mac algorithm but fails over to searching the >>>> other installed JCE providers too. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-6977937 >>>> Webrev: http://cr.openjdk.java.net/~vinnie/6977937/webrev.00/ >>>> >>>> Thanks. >> From weijun.wang at oracle.com Thu Apr 10 11:40:00 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Apr 2014 19:40:00 +0800 Subject: RFR 8029994: Support "include" and "includedir" in krb5.conf Message-ID: <53468310.2090506@oracle.com> Hi All Please review the code changes at http://cr.openjdk.java.net/~weijun/8029994/webrev.01/ Two major changes made: 1. The include and includedir directives are supported now. Read http://web.mit.edu/kerberos/krb5-current/doc/admin/conf_files/krb5_conf.html for a description. The part we support in this RFE is: -----START----- The krb5.conf file can include other files using either of the following directives at the beginning of a line: include FILENAME includedir DIRNAME FILENAME or DIRNAME should be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. Included profile files are syntactically independent of their parents, so each included file must begin with a section header. -----END----- 2. When the same key appears more than once in krb5.conf, Java used to choose the last value, while MIT krb5 chooses the first one. While it's debatable whether latecomers should be able to override earlier definitions or not, it's more important to have consistent behavior across implementations. Therefore we adopt the MIT krb5 way. The compatibility risk should be very low since it's very unlikely people assigns values to duplicate keys in a single krb5.conf file, which is what we support before this enhancement. One code change that might look strange is in the Config constructor: } catch (IOException ioe) { - // I/O error, mostly like krb5.conf missing. - // No problem. We'll use DNS or system property etc. + throw new KrbException(ioe); } Before this, the only possible IOException thrown is FileNotFoundException when krb5.conf is not found, but now there can be much more. So I move the FNFE check inside the loadConfigFile() method as + Path path = Paths.get(fileName); + if (!Files.exists(path)) { + // This is OK. There are other ways to get + // Kerberos 5 settings + return null; + } else { + return readConfigFileLines( + fullp, raw, dupsCheck); + } Thanks Max From xuelei.fan at oracle.com Thu Apr 10 12:17:47 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 10 Apr 2014 20:17:47 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout Message-ID: <53468BEB.8090804@oracle.com> Hi, Please review this test case update: http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ This is a test timeout issue. Cause is still unknown. I guess that one or more of the server threads had not yet been scheduled to run by the system within the timeout of the testing. I added more timeout in the code. Hope next time timeout failure, we can get more information. Thanks, Xuelei From weijun.wang at oracle.com Thu Apr 10 12:42:28 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Apr 2014 20:42:28 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <53468BEB.8090804@oracle.com> References: <53468BEB.8090804@oracle.com> Message-ID: <534691B4.6040500@oracle.com> The code change looks harmless, but I am not sure how it could provide more information next time. --Max On 4/10/2014 20:17, Xuelei Fan wrote: > Hi, > > Please review this test case update: > http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ > > This is a test timeout issue. Cause is still unknown. I guess that one > or more of the server threads had not yet been scheduled to run by the > system within the timeout of the testing. I added more timeout in the > code. Hope next time timeout failure, we can get more information. > > Thanks, > Xuelei > From xuelei.fan at oracle.com Thu Apr 10 12:45:04 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 10 Apr 2014 20:45:04 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <534691B4.6040500@oracle.com> References: <53468BEB.8090804@oracle.com> <534691B4.6040500@oracle.com> Message-ID: <53469250.8090001@oracle.com> On 4/10/2014 8:42 PM, Weijun Wang wrote: > The code change looks harmless, but I am not sure how it could provide > more information next time. > Next time, with accept timeout and read timeout, we would know on which point the threads is more easier to get timeout. Xuelei > --Max > > > On 4/10/2014 20:17, Xuelei Fan wrote: >> Hi, >> >> Please review this test case update: >> http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ >> >> This is a test timeout issue. Cause is still unknown. I guess that one >> or more of the server threads had not yet been scheduled to run by the >> system within the timeout of the testing. I added more timeout in the >> code. Hope next time timeout failure, we can get more information. >> >> Thanks, >> Xuelei >> From weijun.wang at oracle.com Thu Apr 10 14:51:53 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Apr 2014 22:51:53 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <53469250.8090001@oracle.com> References: <53468BEB.8090804@oracle.com> <534691B4.6040500@oracle.com> <53469250.8090001@oracle.com> Message-ID: <5346B009.9080003@oracle.com> So you want to see which line throws SocketTimeoutException? What does that thread.join(120000) do? Is it possible that after it finishes no exception was thrown yet and your test shown as succeeded? --Max On 4/10/2014 20:45, Xuelei Fan wrote: > On 4/10/2014 8:42 PM, Weijun Wang wrote: >> The code change looks harmless, but I am not sure how it could provide >> more information next time. >> > Next time, with accept timeout and read timeout, we would know on which > point the threads is more easier to get timeout. > > Xuelei > >> --Max >> >> >> On 4/10/2014 20:17, Xuelei Fan wrote: >>> Hi, >>> >>> Please review this test case update: >>> http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ >>> >>> This is a test timeout issue. Cause is still unknown. I guess that one >>> or more of the server threads had not yet been scheduled to run by the >>> system within the timeout of the testing. I added more timeout in the >>> code. Hope next time timeout failure, we can get more information. >>> >>> Thanks, >>> Xuelei >>> > From xuelei.fan at oracle.com Thu Apr 10 23:10:31 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Apr 2014 07:10:31 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <5346B009.9080003@oracle.com> References: <53468BEB.8090804@oracle.com> <534691B4.6040500@oracle.com> <53469250.8090001@oracle.com> <5346B009.9080003@oracle.com> Message-ID: <534724E7.4090605@oracle.com> On 4/10/2014 10:51 PM, Weijun Wang wrote: > So you want to see which line throws SocketTimeoutException? > the line calling accept() and read(). > What does that thread.join(120000) do? Is it possible that after it > finishes no exception was thrown yet and your test shown as succeeded? > IO exception should be thrown when the client cannot read and write. Thanks, Xuelei > --Max > > On 4/10/2014 20:45, Xuelei Fan wrote: >> On 4/10/2014 8:42 PM, Weijun Wang wrote: >>> The code change looks harmless, but I am not sure how it could provide >>> more information next time. >>> >> Next time, with accept timeout and read timeout, we would know on which >> point the threads is more easier to get timeout. >> >> Xuelei >> >>> --Max >>> >>> >>> On 4/10/2014 20:17, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review this test case update: >>>> http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ >>>> >>>> This is a test timeout issue. Cause is still unknown. I guess that >>>> one >>>> or more of the server threads had not yet been scheduled to run by the >>>> system within the timeout of the testing. I added more timeout in the >>>> code. Hope next time timeout failure, we can get more information. >>>> >>>> Thanks, >>>> Xuelei >>>> >> From weijun.wang at oracle.com Fri Apr 11 01:36:08 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 11 Apr 2014 09:36:08 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <534724E7.4090605@oracle.com> References: <53468BEB.8090804@oracle.com> <534691B4.6040500@oracle.com> <53469250.8090001@oracle.com> <5346B009.9080003@oracle.com> <534724E7.4090605@oracle.com> Message-ID: <53474708.2080000@oracle.com> On 4/11/2014 7:10, Xuelei Fan wrote: >> What does that thread.join(120000) do? Is it possible that after it >> finishes no exception was thrown yet and your test shown as succeeded? >> > IO exception should be thrown when the client cannot read and write. This is what I am worried about: Suppose serverThread.join(120000) timeouts. At this time, somewhere inside server thread is waiting. Now the main thread starts executing lines 374- and since no exception has been thrown it will execute to line 416 and the main thread exits without a problem. After a while, the server thread fails but since its exception is stored in a variable (serverException) and not thrown out, the test seems to pass. Why are thread.join() necessary? Except for socket timeout, are you expecting other calls spending too much time? --Max > > Thanks, > Xuelei > >>>>> http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ From xuelei.fan at oracle.com Fri Apr 11 02:15:23 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Apr 2014 10:15:23 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <53474708.2080000@oracle.com> References: <53468BEB.8090804@oracle.com> <534691B4.6040500@oracle.com> <53469250.8090001@oracle.com> <5346B009.9080003@oracle.com> <534724E7.4090605@oracle.com> <53474708.2080000@oracle.com> Message-ID: <5347503B.9050804@oracle.com> On 4/11/2014 9:36 AM, Weijun Wang wrote: > > > On 4/11/2014 7:10, Xuelei Fan wrote: >>> What does that thread.join(120000) do? Is it possible that after it >>> finishes no exception was thrown yet and your test shown as succeeded? >>> >> IO exception should be thrown when the client cannot read and write. > > This is what I am worried about: > > Suppose serverThread.join(120000) timeouts. At this time, somewhere > inside server thread is waiting. Now the main thread starts executing > lines 374- This line (374) will not be able to get executed until the client finished its job (line 347). When line 374 get called, the test is nearly done (client complete its jobs, and server accepted all connections). serverThread.join(120000) is just want to make sure that if the termination of this thread is not scheduled to complete within the overall testing timeout, it can be better controlled here. Actually, there are four server threads in this test. Only the latest one is joined. It's not a good practice. But as the update to re-org the test is huge, I don't want to touch this point this time. Thanks, Xuelei > and since no exception has been thrown it will execute to > line 416 and the main thread exits without a problem. After a while, the > server thread fails but since its exception is stored in a variable > (serverException) and not thrown out, the test seems to pass. > > Why are thread.join() necessary? Except for socket timeout, are you > expecting other calls spending too much time? > > --Max > >> >> Thanks, >> Xuelei > >> >>>>> http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ From weijun.wang at oracle.com Fri Apr 11 02:36:41 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 11 Apr 2014 10:36:41 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <5347503B.9050804@oracle.com> References: <53468BEB.8090804@oracle.com> <534691B4.6040500@oracle.com> <53469250.8090001@oracle.com> <5346B009.9080003@oracle.com> <534724E7.4090605@oracle.com> <53474708.2080000@oracle.com> <5347503B.9050804@oracle.com> Message-ID: <53475539.20901@oracle.com> On 4/11/2014 10:15, Xuelei Fan wrote: > When line 374 get called, the test is nearly done (client complete its > jobs, and server accepted all connections). If it's nearly done and no bad thing will happen, then you don't need to call serverThread.join(120000). Otherwise, you risk a false success. Is there a way to find out if the exit of thread.join(time) is due to thread exit or timeout? If so, you can throw an exception if it's a timeout. --Max >> >>>>>>>> http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ > From xuelei.fan at oracle.com Fri Apr 11 02:58:36 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 11 Apr 2014 10:58:36 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <53475539.20901@oracle.com> References: <53468BEB.8090804@oracle.com> <534691B4.6040500@oracle.com> <53469250.8090001@oracle.com> <5346B009.9080003@oracle.com> <534724E7.4090605@oracle.com> <53474708.2080000@oracle.com> <5347503B.9050804@oracle.com> <53475539.20901@oracle.com> Message-ID: <53475A5C.4010901@oracle.com> updated: http://cr.openjdk.java.net/~xuelei/8037557/webrev.01/ On 4/11/2014 10:36 AM, Weijun Wang wrote: > > > On 4/11/2014 10:15, Xuelei Fan wrote: >> When line 374 get called, the test is nearly done (client complete its >> jobs, and server accepted all connections). > > If it's nearly done and no bad thing will happen, then you don't need to > call serverThread.join(120000). Otherwise, you risk a false success. > It's nearly done, and bad thing may still happen (Threads may have not scheduled to completed, and join may be still cannot return within the overall testing timeout). OK. From the debug log, this should not be the cause of the timeout. Removed this update. Thanks, Xuelei > Is there a way to find out if the exit of thread.join(time) is due to > thread exit or timeout? If so, you can throw an exception if it's a > timeout. > > --Max > >>> >>>>>>>>> http://cr.openjdk.java.net/~xuelei/8037557/webrev.00/ >> From weijun.wang at oracle.com Fri Apr 11 03:02:35 2014 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 11 Apr 2014 11:02:35 +0800 Subject: Code review request, 8037557 test SessionCacheSizeTests.java timeout In-Reply-To: <53475A5C.4010901@oracle.com> References: <53468BEB.8090804@oracle.com> <534691B4.6040500@oracle.com> <53469250.8090001@oracle.com> <5346B009.9080003@oracle.com> <534724E7.4090605@oracle.com> <53474708.2080000@oracle.com> <5347503B.9050804@oracle.com> <53475539.20901@oracle.com> <53475A5C.4010901@oracle.com> Message-ID: <53475B4B.8040802@oracle.com> Looks fine to me. Thanks Max On 4/11/2014 10:58, Xuelei Fan wrote: > updated: http://cr.openjdk.java.net/~xuelei/8037557/webrev.01/ From xuelei.fan at oracle.com Mon Apr 14 10:04:40 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 14 Apr 2014 18:04:40 +0800 Subject: Code review request, JDK-8040062 Need to add new methods in BaseSSLSocketImpl Message-ID: <534BB2B8.8010604@oracle.com> Hi, Please review the fix for JDK-8040062: http://cr.openjdk.java.net/~xuelei/8040062/webrev.00/ In JDK-8036979, there are news methods are added to java.net.Socket. These methods need to be overridden in SSL socket implementation, sun/security/ssl/BaseSSLSocketImpl.java. No new regression test. The existing test: sun/security/ssl/SSLSocketImpl/CheckMethods.java can be used to verify this fix. Thanks, Xuelei From sean.mullan at oracle.com Mon Apr 14 12:59:35 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Apr 2014 08:59:35 -0400 Subject: Code review request, JDK-8040062 Need to add new methods in BaseSSLSocketImpl In-Reply-To: <534BB2B8.8010604@oracle.com> References: <534BB2B8.8010604@oracle.com> Message-ID: <534BDBB7.2060204@oracle.com> Looks fine to me. Can you add a relates to link to JDK-8036979 and an appropriate noreg label? --Sean On 04/14/2014 06:04 AM, Xuelei Fan wrote: > Hi, > > Please review the fix for JDK-8040062: > > http://cr.openjdk.java.net/~xuelei/8040062/webrev.00/ > > In JDK-8036979, there are news methods are added to java.net.Socket. > These methods need to be overridden in SSL socket implementation, > sun/security/ssl/BaseSSLSocketImpl.java. > > No new regression test. The existing test: > > sun/security/ssl/SSLSocketImpl/CheckMethods.java > > can be used to verify this fix. > > Thanks, > Xuelei > From xuelei.fan at oracle.com Mon Apr 14 13:03:19 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 14 Apr 2014 21:03:19 +0800 Subject: Code review request, JDK-8040062 Need to add new methods in BaseSSLSocketImpl In-Reply-To: <534BDBB7.2060204@oracle.com> References: <534BB2B8.8010604@oracle.com> <534BDBB7.2060204@oracle.com> Message-ID: <534BDC97.8050305@oracle.com> On 4/14/2014 8:59 PM, Sean Mullan wrote: > Looks fine to me. Can you add a relates to link to JDK-8036979 and an > appropriate noreg label? > Made the update in JBS. Thanks for the review. Xuelei > --Sean > > On 04/14/2014 06:04 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the fix for JDK-8040062: >> >> http://cr.openjdk.java.net/~xuelei/8040062/webrev.00/ >> >> In JDK-8036979, there are news methods are added to java.net.Socket. >> These methods need to be overridden in SSL socket implementation, >> sun/security/ssl/BaseSSLSocketImpl.java. >> >> No new regression test. The existing test: >> >> sun/security/ssl/SSLSocketImpl/CheckMethods.java >> >> can be used to verify this fix. >> >> Thanks, >> Xuelei >> From chris.hegarty at oracle.com Mon Apr 14 13:45:28 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Apr 2014 14:45:28 +0100 Subject: Code review request, JDK-8040062 Need to add new methods in BaseSSLSocketImpl In-Reply-To: <534BDBB7.2060204@oracle.com> References: <534BB2B8.8010604@oracle.com> <534BDBB7.2060204@oracle.com> Message-ID: <534BE678.6080106@oracle.com> +1 . Thanks for updating this Xuelei. Nice test that caught this. -Chris. On 14/04/14 13:59, Sean Mullan wrote: > Looks fine to me. Can you add a relates to link to JDK-8036979 and an > appropriate noreg label? > > --Sean > > On 04/14/2014 06:04 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the fix for JDK-8040062: >> >> http://cr.openjdk.java.net/~xuelei/8040062/webrev.00/ >> >> In JDK-8036979, there are news methods are added to java.net.Socket. >> These methods need to be overridden in SSL socket implementation, >> sun/security/ssl/BaseSSLSocketImpl.java. >> >> No new regression test. The existing test: >> >> sun/security/ssl/SSLSocketImpl/CheckMethods.java >> >> can be used to verify this fix. >> >> Thanks, >> Xuelei >> From sean.mullan at oracle.com Mon Apr 14 18:55:14 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Apr 2014 14:55:14 -0400 Subject: Review Request: 8038184: XMLSignature throws StringIndexOutOfBoundsException if ID attribute value is empty String Message-ID: <534C2F12.8020600@oracle.com> Please review the following simple fix for JDK-8038184: Bug: https://bugs.openjdk.java.net/browse/JDK-8038184 Webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038184/webrev.01/ Thanks, Sean From bradford.wetmore at oracle.com Mon Apr 14 22:25:27 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 14 Apr 2014 15:25:27 -0700 Subject: Code review request, JDK-8040062 Need to add new methods in BaseSSLSocketImpl In-Reply-To: <534BE678.6080106@oracle.com> References: <534BB2B8.8010604@oracle.com> <534BDBB7.2060204@oracle.com> <534BE678.6080106@oracle.com> Message-ID: <534C6057.2010707@oracle.com> There is a similar one for HttpsURLConnection, as we had problems in the past where the networking changes didn't update the SSL code. jdk/sun/net/www/protocol/https/HttpsURLConnection/CheckMethods.java Just a reminder to please include the JSSE reg tests when making Socket/HttpsURLConnection/etc. API changes or when changing code that is common to these methods. Thankfully we were running it anyway and was caught quickly. Thanks, Brad On 4/14/2014 6:45 AM, Chris Hegarty wrote: > +1 . Thanks for updating this Xuelei. Nice test that caught this. > > -Chris. > > On 14/04/14 13:59, Sean Mullan wrote: >> Looks fine to me. Can you add a relates to link to JDK-8036979 and an >> appropriate noreg label? >> >> --Sean >> >> On 04/14/2014 06:04 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the fix for JDK-8040062: >>> >>> http://cr.openjdk.java.net/~xuelei/8040062/webrev.00/ >>> >>> In JDK-8036979, there are news methods are added to java.net.Socket. >>> These methods need to be overridden in SSL socket implementation, >>> sun/security/ssl/BaseSSLSocketImpl.java. >>> >>> No new regression test. The existing test: >>> >>> sun/security/ssl/SSLSocketImpl/CheckMethods.java >>> >>> can be used to verify this fix. >>> >>> Thanks, >>> Xuelei >>> From xuelei.fan at oracle.com Tue Apr 15 00:56:45 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Apr 2014 08:56:45 +0800 Subject: Review Request: 8038184: XMLSignature throws StringIndexOutOfBoundsException if ID attribute value is empty String In-Reply-To: <534C2F12.8020600@oracle.com> References: <534C2F12.8020600@oracle.com> Message-ID: <534C83CD.5010008@oracle.com> Looks fine to me. Xuelei On 4/15/2014 2:55 AM, Sean Mullan wrote: > Please review the following simple fix for JDK-8038184: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8038184 > Webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038184/webrev.01/ > > Thanks, > Sean From weijun.wang at oracle.com Tue Apr 15 08:03:15 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 15 Apr 2014 16:03:15 +0800 Subject: RFR 8039853: Provider.Service.newInstance() does not work with current JDK JGSS Mechanisms Message-ID: <0BAC77E4-2AD7-46DA-97ED-86881A0C758A@oracle.com> Please review the code changes at http://cr.openjdk.java.net/~weijun/8039853/webrev.00/ If you find it confused, I have mistakenly pushed some code changes in http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6e2fcdfa15 and the current code change is trying to fix/enhance it. Altogether, the actual change I want to make is: diff --git a/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java --- a/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java +++ b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java @@ -86,6 +86,10 @@ return result; } + public Krb5MechFactory() { + this(GSSCaller.CALLER_UNKNOWN); + } + public Krb5MechFactory(GSSCaller caller) { this.caller = caller; } diff --git a/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java b/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java --- a/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java +++ b/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java @@ -96,6 +96,10 @@ return result; } + public SpNegoMechFactory() { + this(GSSCaller.CALLER_UNKNOWN); + } + public SpNegoMechFactory(GSSCaller caller) { manager = new GSSManagerImpl(caller, false); Oid[] mechs = manager.getMechs(); Please note that the previous change made in src/share/classes/java/security/Provider.java is now backed out. Thanks Max From alexander.v.stepanov at oracle.com Tue Apr 15 12:24:39 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Tue, 15 Apr 2014 16:24:39 +0400 Subject: [9] Review Request: 8040260 Tidy warnings cleanup for javax.crypto, javax.net Message-ID: <534D2507.2000600@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8040260 Webrev corresponding: http://cr.openjdk.java.net/~yan/8040260/webrev.00/ Just a very minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From sean.mullan at oracle.com Tue Apr 15 15:01:01 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Apr 2014 11:01:01 -0400 Subject: RFR 8039853: Provider.Service.newInstance() does not work with current JDK JGSS Mechanisms In-Reply-To: <0BAC77E4-2AD7-46DA-97ED-86881A0C758A@oracle.com> References: <0BAC77E4-2AD7-46DA-97ED-86881A0C758A@oracle.com> Message-ID: <534D49AD.7020006@oracle.com> Looks fine to me. --Sean On 04/15/2014 04:03 AM, Wang Weijun wrote: > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8039853/webrev.00/ > > If you find it confused, I have mistakenly pushed some code changes in > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6e2fcdfa15 > > and the current code change is trying to fix/enhance it. Altogether, the actual change I want to make is: > > diff --git a/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java > --- a/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java > +++ b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java > @@ -86,6 +86,10 @@ > return result; > } > > + public Krb5MechFactory() { > + this(GSSCaller.CALLER_UNKNOWN); > + } > + > public Krb5MechFactory(GSSCaller caller) { > this.caller = caller; > } > diff --git a/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java b/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java > --- a/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java > +++ b/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java > @@ -96,6 +96,10 @@ > return result; > } > > + public SpNegoMechFactory() { > + this(GSSCaller.CALLER_UNKNOWN); > + } > + > public SpNegoMechFactory(GSSCaller caller) { > manager = new GSSManagerImpl(caller, false); > Oid[] mechs = manager.getMechs(); > > Please note that the previous change made in src/share/classes/java/security/Provider.java is now backed out. > > Thanks > Max > From bradford.wetmore at oracle.com Wed Apr 16 22:49:54 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Apr 2014 15:49:54 -0700 Subject: RFR 8039853: Provider.Service.newInstance() does not work with current JDK JGSS Mechanisms In-Reply-To: <534D49AD.7020006@oracle.com> References: <0BAC77E4-2AD7-46DA-97ED-86881A0C758A@oracle.com> <534D49AD.7020006@oracle.com> Message-ID: <534F0912.2070100@oracle.com> Thanks Weijun, The main class is fine. In the test case, I would suggest adding a comment before the InvalidAlgorithmParameterException that some engines require certain parameters to be be present on creation, and a newInstance(null) will trigger that exception. HTH, Brad On 4/15/2014 8:01 AM, Sean Mullan wrote: > Looks fine to me. > > --Sean > > On 04/15/2014 04:03 AM, Wang Weijun wrote: >> Please review the code changes at >> >> http://cr.openjdk.java.net/~weijun/8039853/webrev.00/ >> >> If you find it confused, I have mistakenly pushed some code changes in >> >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6e2fcdfa15 >> >> and the current code change is trying to fix/enhance it. Altogether, >> the actual change I want to make is: >> >> diff --git >> a/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java >> b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java >> --- a/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java >> +++ b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java >> @@ -86,6 +86,10 @@ >> return result; >> } >> >> + public Krb5MechFactory() { >> + this(GSSCaller.CALLER_UNKNOWN); >> + } >> + >> public Krb5MechFactory(GSSCaller caller) { >> this.caller = caller; >> } >> diff --git >> a/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java >> b/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java >> --- a/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java >> +++ b/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java >> @@ -96,6 +96,10 @@ >> return result; >> } >> >> + public SpNegoMechFactory() { >> + this(GSSCaller.CALLER_UNKNOWN); >> + } >> + >> public SpNegoMechFactory(GSSCaller caller) { >> manager = new GSSManagerImpl(caller, false); >> Oid[] mechs = manager.getMechs(); >> >> Please note that the previous change made in >> src/share/classes/java/security/Provider.java is now backed out. >> >> Thanks >> Max >> From bradford.wetmore at oracle.com Wed Apr 16 22:54:33 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Apr 2014 15:54:33 -0700 Subject: [9] Review Request: 8040260 Tidy warnings cleanup for javax.crypto, javax.net In-Reply-To: <534D2507.2000600@oracle.com> References: <534D2507.2000600@oracle.com> Message-ID: <534F0A29.9020601@oracle.com> We generally update the copyright dates to 2014. Since you are changing line numbers, please work with the JCE team to get the JCE provider rebuilt/signed/integrated. make/closed/tools/crypto/jce/jce.jar I wasn't aware of the ™, nice to know! ;) Thanks, Brad On 4/15/2014 5:24 AM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8040260 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/8040260/webrev.00/ > > Just a very minor cleanup of javadoc to avoid tidy warnings; no other > code affected. > > Thanks. > > Regards, > Alexander From weijun.wang at oracle.com Thu Apr 17 01:49:34 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 17 Apr 2014 09:49:34 +0800 Subject: RFR 8039853: Provider.Service.newInstance() does not work with current JDK JGSS Mechanisms In-Reply-To: <534F0912.2070100@oracle.com> References: <0BAC77E4-2AD7-46DA-97ED-86881A0C758A@oracle.com> <534D49AD.7020006@oracle.com> <534F0912.2070100@oracle.com> Message-ID: <6EDF141E-B7DB-4AC9-A71D-0E6730CCFC90@oracle.com> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d993a3fc9b19 Thanks Max On Apr 17, 2014, at 6:49, Bradford Wetmore wrote: > Thanks Weijun, > > The main class is fine. > > In the test case, I would suggest adding a comment before the InvalidAlgorithmParameterException that some engines require certain parameters to be be present on creation, and a newInstance(null) will trigger that exception. > > HTH, > > Brad > > > > On 4/15/2014 8:01 AM, Sean Mullan wrote: >> Looks fine to me. >> >> --Sean >> >> On 04/15/2014 04:03 AM, Wang Weijun wrote: >>> Please review the code changes at >>> >>> http://cr.openjdk.java.net/~weijun/8039853/webrev.00/ >>> >>> If you find it confused, I have mistakenly pushed some code changes in >>> >>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ba6e2fcdfa15 >>> >>> and the current code change is trying to fix/enhance it. Altogether, >>> the actual change I want to make is: >>> >>> diff --git >>> a/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java >>> b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java >>> --- a/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java >>> +++ b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java >>> @@ -86,6 +86,10 @@ >>> return result; >>> } >>> >>> + public Krb5MechFactory() { >>> + this(GSSCaller.CALLER_UNKNOWN); >>> + } >>> + >>> public Krb5MechFactory(GSSCaller caller) { >>> this.caller = caller; >>> } >>> diff --git >>> a/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java >>> b/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java >>> --- a/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java >>> +++ b/src/share/classes/sun/security/jgss/spnego/SpNegoMechFactory.java >>> @@ -96,6 +96,10 @@ >>> return result; >>> } >>> >>> + public SpNegoMechFactory() { >>> + this(GSSCaller.CALLER_UNKNOWN); >>> + } >>> + >>> public SpNegoMechFactory(GSSCaller caller) { >>> manager = new GSSManagerImpl(caller, false); >>> Oid[] mechs = manager.getMechs(); >>> >>> Please note that the previous change made in >>> src/share/classes/java/security/Provider.java is now backed out. >>> >>> Thanks >>> Max >>> From weijun.wang at oracle.com Thu Apr 17 11:38:11 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 17 Apr 2014 19:38:11 +0800 Subject: RFR 8040068 and 8039951: platform-related JAAS login modules on all platforms Message-ID: <00A85461-5D68-4946-9265-A68875A75926@oracle.com> Hi All There are two bugs. The first one is: https://bugs.openjdk.java.net/browse/JDK-8040068 8040068: SolarisSystem should be @Deprecated and @jdk.Exported(false) of which the code change is simply --- a/src/share/classes/com/sun/security/auth/module/SolarisSystem.java +++ b/src/share/classes/com/sun/security/auth/module/SolarisSystem.java @@ -29,8 +29,10 @@ *

This class implementation retrieves and makes available Solaris * UID/GID/groups information for the current user. * + * @deprecated replaced by {@link UnixSystem}. */ - at jdk.Exported + at jdk.Exported(false) + at Deprecated public class SolarisSystem { The second one is: https://bugs.openjdk.java.net/browse/JDK-8039951 8039951: com.sun.security.auth.module missing classes on some platforms of which the code change is at http://cr.openjdk.java.net/~weijun/8039951/webrev.00/ This webrev contains two parts: 1. Changes to make/CompileJavaClasses.gmk to make sure the classes are now created on all platforms, including the deprecated one in 8040068. 2. Tweaks in the login modules to show a more friendly message. Not sure if you like it, but the code change here has a side benefit that allows the JAAS login config file below working on all platforms (This is proved in the newly added regression test): hello { com.sun.security.auth.module.UnixLoginModule optional; com.sun.security.auth.module.NTLoginModule optional; com.sun.security.auth.module.SolarisLoginModule optional; }; In fact, when a login module is not found, an exception will be thrown immediately even if it's marked optional. Now that these modules are available on all platforms, this won't happen anymore. If you think this behavior is incorrect, we can fix it in another bug. Thanks Max From sean.mullan at oracle.com Thu Apr 17 18:22:15 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 17 Apr 2014 14:22:15 -0400 Subject: RFR 8029994: Support "include" and "includedir" in krb5.conf In-Reply-To: <53468310.2090506@oracle.com> References: <53468310.2090506@oracle.com> Message-ID: <53501BD7.9000508@oracle.com> * Config.java - update copyright year [202] can you log the IOException? will finish reviewing later ... --Sean On 04/10/2014 07:40 AM, Weijun Wang wrote: > Hi All > > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8029994/webrev.01/ > > Two major changes made: > > 1. The include and includedir directives are supported now. Read > http://web.mit.edu/kerberos/krb5-current/doc/admin/conf_files/krb5_conf.html > for a description. The part we support in this RFE is: > > -----START----- > The krb5.conf file can include other files using either of the following > directives at the beginning of a line: > > include FILENAME > includedir DIRNAME > > FILENAME or DIRNAME should be an absolute path. The named file or > directory must exist and be readable. Including a directory includes all > files within the directory whose names consist solely of alphanumeric > characters, dashes, or underscores. Included profile files are > syntactically independent of their parents, so each included file must > begin with a section header. > -----END----- > > 2. When the same key appears more than once in krb5.conf, Java used to > choose the last value, while MIT krb5 chooses the first one. While it's > debatable whether latecomers should be able to override earlier > definitions or not, it's more important to have consistent behavior > across implementations. Therefore we adopt the MIT krb5 way. The > compatibility risk should be very low since it's very unlikely people > assigns values to duplicate keys in a single krb5.conf file, which is > what we support before this enhancement. > > One code change that might look strange is in the Config constructor: > > } catch (IOException ioe) { > - // I/O error, mostly like krb5.conf missing. > - // No problem. We'll use DNS or system property etc. > + throw new KrbException(ioe); > } > > Before this, the only possible IOException thrown is > FileNotFoundException when krb5.conf is not found, but now there can be > much more. So I move the FNFE check inside the loadConfigFile() method as > > + Path path = Paths.get(fileName); > + if (!Files.exists(path)) { > + // This is OK. There are other ways to get > + // Kerberos 5 settings > + return null; > + } else { > + return readConfigFileLines( > + fullp, raw, dupsCheck); > + } > > Thanks > Max From weijun.wang at oracle.com Fri Apr 18 15:01:41 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 18 Apr 2014 23:01:41 +0800 Subject: RFR 8039358 & 8038837: tSAPolicyID and tSADigestAlg for jarsigner Message-ID: <0A98D0AE-A49F-4442-A61D-6CD3B3632884@oracle.com> Please review these two code changes: 8039358: com.sun.jarsigner.ContentSignerParameters.getTSAPolicyID() should be a default method http://cr.openjdk.java.net/~weijun/8039358/webrev.01/ 8038837: Add support to jarsigner for specifying timestamp hash algorithm http://cr.openjdk.java.net/~weijun/8038837/webrev.01/ Thanks Max From vincent.x.ryan at oracle.com Fri Apr 18 15:59:58 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 18 Apr 2014 16:59:58 +0100 Subject: RFR 8039358 & 8038837: tSAPolicyID and tSADigestAlg for jarsigner In-Reply-To: <0A98D0AE-A49F-4442-A61D-6CD3B3632884@oracle.com> References: <0A98D0AE-A49F-4442-A61D-6CD3B3632884@oracle.com> Message-ID: <7C356F6A-0509-4EA6-9532-0AC2EB176B1C@oracle.com> Your 2 fixes look good. Thanks. On 18 Apr 2014, at 16:01, Wang Weijun wrote: > Please review these two code changes: > > 8039358: com.sun.jarsigner.ContentSignerParameters.getTSAPolicyID() should be a default method > http://cr.openjdk.java.net/~weijun/8039358/webrev.01/ > > 8038837: Add support to jarsigner for specifying timestamp hash algorithm > http://cr.openjdk.java.net/~weijun/8038837/webrev.01/ > > Thanks > Max > From sean.mullan at oracle.com Fri Apr 18 17:14:26 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 18 Apr 2014 13:14:26 -0400 Subject: RFR 8040068 and 8039951: platform-related JAAS login modules on all platforms In-Reply-To: <00A85461-5D68-4946-9265-A68875A75926@oracle.com> References: <00A85461-5D68-4946-9265-A68875A75926@oracle.com> Message-ID: <53515D72.6040708@oracle.com> On 04/17/2014 07:38 AM, Wang Weijun wrote: > Hi All > > There are two bugs. The first one is: > > https://bugs.openjdk.java.net/browse/JDK-8040068 8040068: > SolarisSystem should be @Deprecated and @jdk.Exported(false) > > of which the code change is simply > > --- > a/src/share/classes/com/sun/security/auth/module/SolarisSystem.java > +++ > b/src/share/classes/com/sun/security/auth/module/SolarisSystem.java > @@ -29,8 +29,10 @@ *

This class implementation retrieves and > makes available Solaris * UID/GID/groups information for the current > user. * + * @deprecated replaced by {@link UnixSystem}. */ > - at jdk.Exported + at jdk.Exported(false) + at Deprecated public class > SolarisSystem { Looks fine. > The second one is: > > https://bugs.openjdk.java.net/browse/JDK-8039951 8039951: > com.sun.security.auth.module missing classes on some platforms > > of which the code change is at > > http://cr.openjdk.java.net/~weijun/8039951/webrev.00/ > > This webrev contains two parts: > > 1. Changes to make/CompileJavaClasses.gmk to make sure the classes > are now created on all platforms, including the deprecated one in > 8040068. Looks fine. > > 2. Tweaks in the login modules to show a more friendly message. > > Not sure if you like it, but the code change here has a side benefit > that allows the JAAS login config file below working on all platforms > (This is proved in the newly added regression test): > > hello { com.sun.security.auth.module.UnixLoginModule optional; > com.sun.security.auth.module.NTLoginModule optional; > com.sun.security.auth.module.SolarisLoginModule optional; }; > > In fact, when a login module is not found, an exception will be > thrown immediately even if it's marked optional. Now that these > modules are available on all platforms, this won't happen anymore. If > you think this behavior is incorrect, we can fix it in another bug. Is that because before your fix, it would throw NoClassDefFoundError? I think the new behavior makes more sense and is definitely more user friendly. However, even though it is probably an obscure case, technically it is a change in behavior, so I think you should describe it in the CCC. I noticed in a few classes, the previous code had a bug in it, ex: 143 if (ntSystem == null) { which is not possible. So it's good you cleaned that up too. --Sean From weijun.wang at oracle.com Sat Apr 19 15:14:50 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 19 Apr 2014 23:14:50 +0800 Subject: RFR 8040068 and 8039951: platform-related JAAS login modules on all platforms In-Reply-To: <53515D72.6040708@oracle.com> References: <00A85461-5D68-4946-9265-A68875A75926@oracle.com> <53515D72.6040708@oracle.com> Message-ID: <4871BD64-56D6-46B8-B3B0-44172D3A4CF6@oracle.com> On Apr 19, 2014, at 1:14, Sean Mullan wrote: >> In fact, when a login module is not found, an exception will be >> thrown immediately even if it's marked optional. Now that these >> modules are available on all platforms, this won't happen anymore. If >> you think this behavior is incorrect, we can fix it in another bug. > > Is that because before your fix, it would throw NoClassDefFoundError? It's ClassNotFoundException. In LoginContext.invoke(), only when it's an InvocationTargetException, the code will save the exception and decides what to do depending on if the module is requisite or required or optional. > > I think the new behavior makes more sense and is definitely more user friendly. However, even though it is probably an obscure case, technically it is a change in behavior, so I think you should describe it in the CCC. OK, I can. Also I am thinking we should enhance LoginContext so that ClassNotFoundException be treated the same as InvocationTargetException. Thanks Max From weijun.wang at oracle.com Mon Apr 21 02:53:25 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Apr 2014 10:53:25 +0800 Subject: RFR 8029994: Support "include" and "includedir" in krb5.conf In-Reply-To: <53501BD7.9000508@oracle.com> References: <53468310.2090506@oracle.com> <53501BD7.9000508@oracle.com> Message-ID: On Apr 18, 2014, at 2:22, Sean Mullan wrote: > * Config.java > > - update copyright year Will add it before the push. I could work on multiple bugs of a single file and cannot determine which one gets pushed first. > [202] can you log the IOException? OK. Thanks Max >> http://cr.openjdk.java.net/~weijun/8029994/webrev.01/ From alexander.v.stepanov at oracle.com Mon Apr 21 09:57:32 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Mon, 21 Apr 2014 13:57:32 +0400 Subject: [9] Review Request: 8040260 Tidy warnings cleanup for javax.crypto, javax.net In-Reply-To: <534F0A29.9020601@oracle.com> References: <534D2507.2000600@oracle.com> <534F0A29.9020601@oracle.com> Message-ID: <5354EB8C.2070600@oracle.com> Thank! On 17.04.2014 2:54, Bradford Wetmore wrote: > We generally update the copyright dates to 2014. > > Since you are changing line numbers, please work with the JCE team to > get the JCE provider rebuilt/signed/integrated. > > make/closed/tools/crypto/jce/jce.jar > > I wasn't aware of the ™, nice to know! ;) > > Thanks, > > Brad > > > > On 4/15/2014 5:24 AM, alexander stepanov wrote: >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8040260 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/8040260/webrev.00/ >> >> Just a very minor cleanup of javadoc to avoid tidy warnings; no other >> code affected. >> >> Thanks. >> >> Regards, >> Alexander From alexander.v.stepanov at oracle.com Mon Apr 21 10:11:52 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Mon, 21 Apr 2014 14:11:52 +0400 Subject: [9] Review Request: 8028266 Tidy warnings cleanup for packages java.security/javax.security Message-ID: <5354EEE8.8040303@oracle.com> Hello, Could you please review the fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-8028266 Webrev corresponding: http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.00/ Just a minor cleanup of javadoc to avoid tidy warnings; no other code affected. Thanks. Regards, Alexander From bradford.wetmore at oracle.com Mon Apr 21 21:08:56 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 21 Apr 2014 14:08:56 -0700 Subject: [9] Review Request: 8028266 Tidy warnings cleanup for packages java.security/javax.security In-Reply-To: <5354EEE8.8040303@oracle.com> References: <5354EEE8.8040303@oracle.com> Message-ID: <535588E8.5080200@oracle.com> We usually update the copyright dates: * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved. javax/security/auth/kerberos/package-info.java ============================================== "yes", or "no", case-insensitive. -> "yes", or "no", and values are case-insensitive. I noticed in several places that while your changes are ok, it doesn't update the value instead of switching to {@code value}. In a previous webrev, I mentioned that you'll need to work with someone to update the built JCE binaries for the javax.crypto changes. Who is going to help you with that? Brad On 4/21/2014 3:11 AM, alexander stepanov wrote: > Hello, > > Could you please review the fix for the following bug: > https://bugs.openjdk.java.net/browse/JDK-8028266 > > Webrev corresponding: > http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.00/ > > Just a minor cleanup of javadoc to avoid tidy warnings; no other code > affected. > > Thanks. > > Regards, > Alexander From alexander.v.stepanov at oracle.com Tue Apr 22 13:41:55 2014 From: alexander.v.stepanov at oracle.com (alexander stepanov) Date: Tue, 22 Apr 2014 17:41:55 +0400 Subject: [9] Review Request: 8028266 Tidy warnings cleanup for packages java.security/javax.security In-Reply-To: <535588E8.5080200@oracle.com> References: <5354EEE8.8040303@oracle.com> <535588E8.5080200@oracle.com> Message-ID: <535671A3.2070804@oracle.com> Hello Bradford, Thanks, Could you please review again: http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.01/ > Who is going to help you with that? I didn't communicate with JCE team before. So could you please appoint me someone to contact? Thanks. Regards, Alexander On 22.04.2014 1:08, Bradford Wetmore wrote: > We usually update the copyright dates: > > * Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights > reserved. > > javax/security/auth/kerberos/package-info.java > ============================================== > > "yes", or "no", case-insensitive. > -> > "yes", or "no", and values are case-insensitive. > > I noticed in several places that while your changes are ok, it doesn't > update the value instead of switching to {@code value}. > > In a previous webrev, I mentioned that you'll need to work with > someone to update the built JCE binaries for the javax.crypto > changes. Who is going to help you with that? > > Brad > > > > On 4/21/2014 3:11 AM, alexander stepanov wrote: >> Hello, >> >> Could you please review the fix for the following bug: >> https://bugs.openjdk.java.net/browse/JDK-8028266 >> >> Webrev corresponding: >> http://cr.openjdk.java.net/~yan/JDK-8028266/webrev.00/ >> >> Just a minor cleanup of javadoc to avoid tidy warnings; no other code >> affected. >> >> Thanks. >> >> Regards, >> Alexander From mandy.chung at oracle.com Tue Apr 22 19:39:57 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Apr 2014 12:39:57 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission Message-ID: <5356C58D.5070805@oracle.com> This change proposes to remove granting all permissions for extensions as the default and implements the principle of least privilege.In JDK 9, we want to reduce the privileges of as many system classes as possible. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/ This patch has reduced the zipfs, localedata and cldrdata to grant the permissions they require. It grants AllPermission to other jar files in the lib/ext directory shipped with JDK and this change is intended to enable the component teams to identify the minimum permissions and fix any issue, if any. Libraries installed in the extensions directory depending on AllPermission granted by default are impacted. Making this change as early in JDK 9 allows us to identify any customer impacted by this change. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernd-2014 at eckenfels.net Tue Apr 22 21:54:08 2014 From: bernd-2014 at eckenfels.net (Bernd Eckenfels) Date: Tue, 22 Apr 2014 23:54:08 +0200 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <5356C58D.5070805@oracle.com> References: <5356C58D.5070805@oracle.com> Message-ID: <20140422235408.00007a75.bernd-2014@eckenfels.net> Hello, I do like to restrict the permissions granted, especially for client deployments. in a related note: why is JavaFX shipped by default as an extension? Or better asked, how is the admin in the future supposed to maintain a minimum JRE? Randomly deleting extension jars? Would it be better to ship the JAR only in a dir where they CAN be added to the classpath, but are not by default (similiar to javadb/derby). Gruss Bernd Am Tue, 22 Apr 2014 12:39:57 -0700 schrieb Mandy Chung : > This change proposes to remove granting all permissions for > extensions as the default and implements the principle of least > privilege.In JDK 9, we want to reduce the privileges of as many > system classes as possible. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/ > > This patch has reduced the zipfs, localedata and cldrdata to grant > the permissions they require. It grants AllPermission to other jar > files in the lib/ext directory shipped with JDK and this change is > intended to enable the component teams to identify the minimum > permissions and fix any issue, if any. > > Libraries installed in the extensions directory depending on > AllPermission granted by default are impacted. Making this change > as early in JDK 9 allows us to identify any customer impacted by this > change. > > Mandy > From mandy.chung at oracle.com Tue Apr 22 22:36:31 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Apr 2014 15:36:31 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <20140422235408.00007a75.bernd-2014@eckenfels.net> References: <5356C58D.5070805@oracle.com> <20140422235408.00007a75.bernd-2014@eckenfels.net> Message-ID: <5356EEEF.8080107@oracle.com> On 4/22/14 2:54 PM, Bernd Eckenfels wrote: > Hello, > > I do like to restrict the permissions granted, especially for client > deployments. > > in a related note: why is JavaFX shipped by default as an extension? JavaFX is coinstalled with Oracle JDK and not in the OpenJDK. I will take out jfxrt.jar from the java.policy and the build should augment the system java.policy with any cobundled/coinstalled components. Thanks for bringing up this question. I missed to mention the open question to follow up how we want to build the system java.policy. There are platform-specific jar file and also different jar files in Oracle JDK build. I currently list them all in java.policy in this initial patch. One solution is to have one version of java.policy for each OS. However this will suffer from the maintenance burden and also error-prone as the current java.security file. I'd like to get the feedback from the security team before attempting to modify the makefiles. > Or better asked, how is the admin in the future supposed to maintain a > minimum JRE? Randomly deleting extension jars? Would it be better to > ship the JAR only in a dir where they CAN be added to the classpath, > but are not by default (similiar to javadb/derby). Jigsaw/Modularity would be the answer and that will allow you to install the modules you want. JFX is not built with OpenJDK. Are you questioning why JavaFX is coinstalled with Oracle JDK? Mandy > > Gruss > Bernd > > Am Tue, 22 Apr 2014 12:39:57 -0700 > schrieb Mandy Chung : > >> This change proposes to remove granting all permissions for >> extensions as the default and implements the principle of least >> privilege.In JDK 9, we want to reduce the privileges of as many >> system classes as possible. >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/ >> >> This patch has reduced the zipfs, localedata and cldrdata to grant >> the permissions they require. It grants AllPermission to other jar >> files in the lib/ext directory shipped with JDK and this change is >> intended to enable the component teams to identify the minimum >> permissions and fix any issue, if any. >> >> Libraries installed in the extensions directory depending on >> AllPermission granted by default are impacted. Making this change >> as early in JDK 9 allows us to identify any customer impacted by this >> change. >> >> Mandy >> From sean.mullan at oracle.com Wed Apr 23 15:19:20 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 Apr 2014 11:19:20 -0400 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <5356EEEF.8080107@oracle.com> References: <5356C58D.5070805@oracle.com> <20140422235408.00007a75.bernd-2014@eckenfels.net> <5356EEEF.8080107@oracle.com> Message-ID: <5357D9F8.4060804@oracle.com> On 04/22/2014 06:36 PM, Mandy Chung wrote: > Thanks for bringing up this question. I missed to mention the open > question to follow up how we want to build the system java.policy. There > are platform-specific jar file and also different jar files in Oracle > JDK build. I currently list them all in java.policy in this initial > patch. One solution is to have one version of java.policy for each OS. > However this will suffer from the maintenance burden and also > error-prone as the current java.security file. I'd like to get the > feedback from the security team before attempting to modify the makefiles. We had a similar issue with the java.security file where Oracle-specific packages were being added to the package.access/definition properties in the OpenJDK java.security files; thus polluting the source code with packages that were Oracle-specific. I fixed this in JDK 8: https://bugs.openjdk.java.net/browse/JDK-8007292 Basically it involved keeping a list of the non-OpenJDK packages that were to be restricted in the closed repo, and creating a Java program that appended these to the properties in the java.security file when the build included the closed sources. --Sean From mandy.chung at oracle.com Wed Apr 23 16:14:16 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Apr 2014 09:14:16 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <5357D9F8.4060804@oracle.com> References: <5356C58D.5070805@oracle.com> <20140422235408.00007a75.bernd-2014@eckenfels.net> <5356EEEF.8080107@oracle.com> <5357D9F8.4060804@oracle.com> Message-ID: <5357E6D8.5050403@oracle.com> On 4/23/2014 8:19 AM, Sean Mullan wrote: > On 04/22/2014 06:36 PM, Mandy Chung wrote: >> Thanks for bringing up this question. I missed to mention the open >> question to follow up how we want to build the system java.policy. There >> are platform-specific jar file and also different jar files in Oracle >> JDK build. I currently list them all in java.policy in this initial >> patch. One solution is to have one version of java.policy for each OS. >> However this will suffer from the maintenance burden and also >> error-prone as the current java.security file. I'd like to get the >> feedback from the security team before attempting to modify the >> makefiles. > > We had a similar issue with the java.security file where > Oracle-specific packages were being added to the > package.access/definition properties in the OpenJDK java.security > files; thus polluting the source code with packages that were > Oracle-specific. > > I fixed this in JDK 8: > https://bugs.openjdk.java.net/browse/JDK-8007292 > > Basically it involved keeping a list of the non-OpenJDK packages that > were to be restricted in the closed repo, and creating a Java program > that appended these to the properties in the java.security file when > the build included the closed sources. > Thanks Sean. This patch separates the Oracle-specific content from the OpenJDK java.security files. Is there any plan to handle java.security- differently (I recalled there is a RFE for it and a large part of the content is duplicated)? If this is work-in-progress, I want to make sure to use a similar mechanism for java.policy. Mandy From sean.mullan at oracle.com Wed Apr 23 16:42:02 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 Apr 2014 12:42:02 -0400 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <5357E6D8.5050403@oracle.com> References: <5356C58D.5070805@oracle.com> <20140422235408.00007a75.bernd-2014@eckenfels.net> <5356EEEF.8080107@oracle.com> <5357D9F8.4060804@oracle.com> <5357E6D8.5050403@oracle.com> Message-ID: <5357ED5A.7020209@oracle.com> On 04/23/2014 12:14 PM, Mandy Chung wrote: > Thanks Sean. This patch separates the Oracle-specific content from the > OpenJDK java.security files. Is there any plan to handle > java.security- differently (I recalled there is a RFE for it and a > large part of the content is duplicated)? If this is work-in-progress, > I want to make sure to use a similar mechanism for java.policy. Yes, see https://bugs.openjdk.java.net/browse/JDK-6997010 I haven't started that one yet though. --Sean From sean.mullan at oracle.com Wed Apr 23 20:10:30 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 Apr 2014 16:10:30 -0400 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <5356C58D.5070805@oracle.com> References: <5356C58D.5070805@oracle.com> Message-ID: <53581E36.7030004@oracle.com> Just a few comments: 1. When you write a test that uses the jtreg /policy option, the policy file overrides the system policy file. If the test depends on a standard extension, then you may get SecurityExceptions unless additional perms are granted. Thus, there are quite a few tests that define their own policy files and duplicate the grant statement for extensions from the system policy: grant codeBase "file:${{java.ext.dirs}}/*" { permission java.security.AllPermission; } These tests should be modified to only grant the necessary permissions. However, ideally I think that a better solution would be to add a jtreg /policy option that doesn't override the system policy file, but rather appends to it, for example, using "==" : @run main/othervm/policy==test.policy (this is the reverse behavior of the java.security.policy system property, so it might be a little confusing, so maybe it is better to add a new option) 2. test/lib/security/java.policy/Ext_AllPolicy.java I think you should also add a check for AllPermission. 3. jdk/nio/zipfs/ZipFileSystem.java If I understand the changes, the previous code would throw SecurityExceptions when run under a SecurityManager? It's not specifically related to this bug, is it? 4. lib/security/java.policy grant codeBase "file:${java.home}/lib/ext/zipfs.jar" { permission java.io.FilePermission "<>", "read,write,delete"; Hmm, granting that likely means you are just a hop away from getting AllPermission ... not sure what to advise here, but there are several cases like this for certain permissions (ex: RuntimePermission "createClassLoader" is another one). --Sean On 04/22/2014 03:39 PM, Mandy Chung wrote: > This change proposes to remove granting all permissions for extensions > as the default and implements the principle of least privilege.In JDK 9, > we want to reduce the privileges of as many system classes as possible. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/ > > This patch has reduced the zipfs, localedata and cldrdata to grant the > permissions they require. It grants AllPermission to other jar files in > the lib/ext directory shipped with JDK and this change is intended to > enable the component teams to identify the minimum permissions and fix > any issue, if any. > > Libraries installed in the extensions directory depending on > AllPermission granted by default are impacted. Making this change as > early in JDK 9 allows us to identify any customer impacted by this change. > > Mandy From mandy.chung at oracle.com Wed Apr 23 21:29:16 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Apr 2014 14:29:16 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <53581E36.7030004@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> Message-ID: <535830AC.5070003@oracle.com> On 4/23/2014 1:10 PM, Sean Mullan wrote: > Just a few comments: > > 1. When you write a test that uses the jtreg /policy option, the > policy file overrides the system policy file. If the test depends on a > standard extension, then you may get SecurityExceptions unless > additional perms are granted. Thus, there are quite a few tests that > define their own policy files and duplicate the grant statement for > extensions from the system policy: > > grant codeBase "file:${{java.ext.dirs}}/*" { > permission java.security.AllPermission; > } > > These tests should be modified to only grant the necessary > permissions. However, ideally I think that a better solution would be > to add a jtreg /policy option that doesn't override the system policy > file, but rather appends to it, for example, using "==" : > I suspect most of the tests only want to grant the permissions for the test itself rather than overriding the system policy file. Having a new jtreg/policy option not to override the system policy file may be a better solution. This would avoid updating the test's policy file every time the system's policy is modified. On the other hand, I think the test policy may not need to grant permissions to the extensions directory if it doesn't use the classes in extensions. It's a good opportunity to clean that up. This will require some closer look at the tests. If you are okay, I'd like to separate the test's custom policy update as a follow-on work. > @run main/othervm/policy==test.policy > > (this is the reverse behavior of the java.security.policy system > property, so it might be a little confusing, so maybe it is better to > add a new option) > "==" is a confusing syntax. -Djava.security.policy==test.policy overrides the system policy file ("=" prefix) whereas jtreg uses the reverse syntax? I think it would be better to make jtreg/policy consistent with -Djava.security.policy (i.e. default is to extend the system java.security). > 2. test/lib/security/java.policy/Ext_AllPolicy.java > > I think you should also add a check for AllPermission. Will look into it. > > 3. jdk/nio/zipfs/ZipFileSystem.java > > If I understand the changes, the previous code would throw > SecurityExceptions when run under a SecurityManager? It's not > specifically related to this bug, is it? > It's a bug in the zipfs provider and I can file a new JBS issue for the zipfs change. I prefer to push them in the same changeset that reduces zipfs's privileges and added tests to run with security manager. > 4. lib/security/java.policy > > grant codeBase "file:${java.home}/lib/ext/zipfs.jar" { > permission java.io.FilePermission "<>", > "read,write,delete"; > > Hmm, granting that likely means you are just a hop away from getting > AllPermission ... not sure what to advise here, but there are several > cases like this for certain permissions (ex: RuntimePermission > "createClassLoader" is another one). I think we could grant "delete" only to the temp files that zipfs creates as implementation details. I'll let Sherman follow up and fine-tune the permission set. Thanks for the feedback. I'll send an updated webrev that will also have the change for os-specific version of java.policy. Mandy > > --Sean > > On 04/22/2014 03:39 PM, Mandy Chung wrote: >> This change proposes to remove granting all permissions for extensions >> as the default and implements the principle of least privilege.In JDK 9, >> we want to reduce the privileges of as many system classes as possible. >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.00/ >> >> This patch has reduced the zipfs, localedata and cldrdata to grant the >> permissions they require. It grants AllPermission to other jar files in >> the lib/ext directory shipped with JDK and this change is intended to >> enable the component teams to identify the minimum permissions and fix >> any issue, if any. >> >> Libraries installed in the extensions directory depending on >> AllPermission granted by default are impacted. Making this change as >> early in JDK 9 allows us to identify any customer impacted by this >> change. >> >> Mandy From weijun.wang at oracle.com Thu Apr 24 11:17:49 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 24 Apr 2014 19:17:49 +0800 Subject: RFR 8040321: keytool and jarsigner tests doesn't pass though VM tools to tools Message-ID: <79CA92F1-60E4-4EF9-BF25-693D9B64B0FB@oracle.com> Please review the changes at http://cr.openjdk.java.net/~weijun/8040321/webrev.00 Most are simple, except that ts.sh needs to call TimeSTampCheck.java which then calls jarsigner, therefore more hops. To test the change, I modify my own keytool and jarsigner so that they fails when a certain system property is set, and then I run the tests with that system property on. I see no problem. JPRT is running. Thanks Max From weijun.wang at oracle.com Thu Apr 24 11:21:13 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 24 Apr 2014 19:21:13 +0800 Subject: RFR 8040321: keytool and jarsigner tests doesn't pass though VM tools to tools In-Reply-To: <79CA92F1-60E4-4EF9-BF25-693D9B64B0FB@oracle.com> References: <79CA92F1-60E4-4EF9-BF25-693D9B64B0FB@oracle.com> Message-ID: On Apr 24, 2014, at 19:17, Wang Weijun wrote: > Please review the changes at > > http://cr.openjdk.java.net/~weijun/8040321/webrev.00 > > Most are simple, except that ts.sh needs to call TimeSTampCheck.java which then calls jarsigner, therefore more hops. > > To test the change, I modify my own keytool and jarsigner so that they fails when a certain system property is set, and then I run the tests with that system property on. I see no problem. Oh, it should be "fails when a certain system property is NOT set". And when I don't provide the system property on jtreg command line, tests do fail. --Max > > JPRT is running. > > Thanks > Max > From Alan.Bateman at oracle.com Thu Apr 24 13:25:13 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Apr 2014 14:25:13 +0100 Subject: RFR 8040321: keytool and jarsigner tests doesn't pass though VM tools to tools In-Reply-To: <79CA92F1-60E4-4EF9-BF25-693D9B64B0FB@oracle.com> References: <79CA92F1-60E4-4EF9-BF25-693D9B64B0FB@oracle.com> Message-ID: <535910B9.5080103@oracle.com> On 24/04/2014 12:17, Wang Weijun wrote: > Please review the changes at > > http://cr.openjdk.java.net/~weijun/8040321/webrev.00 > > Most are simple, except that ts.sh needs to call TimeSTampCheck.java which then calls jarsigner, therefore more hops. > > To test the change, I modify my own keytool and jarsigner so that they fails when a certain system property is set, and then I run the tests with that system property on. I see no problem. > The change looks good, thank you. Another way to test this would be to just run jtreg with -vmoption and then using ps to look at the keytool processes as they run (they run a long time so easy to spot). -Alan. From sean.mullan at oracle.com Thu Apr 24 18:32:58 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Apr 2014 14:32:58 -0400 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <535830AC.5070003@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> Message-ID: <535958DA.2010307@oracle.com> On 04/23/2014 05:29 PM, Mandy Chung wrote: > > On 4/23/2014 1:10 PM, Sean Mullan wrote: >> Just a few comments: >> >> 1. When you write a test that uses the jtreg /policy option, the >> policy file overrides the system policy file. If the test depends on a >> standard extension, then you may get SecurityExceptions unless >> additional perms are granted. Thus, there are quite a few tests that >> define their own policy files and duplicate the grant statement for >> extensions from the system policy: >> >> grant codeBase "file:${{java.ext.dirs}}/*" { >> permission java.security.AllPermission; >> } >> >> These tests should be modified to only grant the necessary >> permissions. However, ideally I think that a better solution would be >> to add a jtreg /policy option that doesn't override the system policy >> file, but rather appends to it, for example, using "==" : >> > > I suspect most of the tests only want to grant the permissions for the > test itself rather than overriding the system policy file. Having a new > jtreg/policy option not to override the system policy file may be a > better solution. This would avoid updating the test's policy file > every time the system's policy is modified. On the other hand, I think > the test policy may not need to grant permissions to the extensions > directory if it doesn't use the classes in extensions. It's a good > opportunity to clean that up. This will require some closer look at the > tests. > > If you are okay, I'd like to separate the test's custom policy update as > a follow-on work. That's fine with me. >> @run main/othervm/policy==test.policy >> >> (this is the reverse behavior of the java.security.policy system >> property, so it might be a little confusing, so maybe it is better to >> add a new option) >> > > "==" is a confusing syntax. -Djava.security.policy==test.policy > overrides the system policy file ("=" prefix) whereas jtreg uses the > reverse syntax? I think it would be better to make jtreg/policy > consistent with -Djava.security.policy (i.e. default is to extend the > system java.security). Would be nice, but not sure if we can change it at this point. Anyway, one of us should file a jtreg RFE. >> 3. jdk/nio/zipfs/ZipFileSystem.java >> >> If I understand the changes, the previous code would throw >> SecurityExceptions when run under a SecurityManager? It's not >> specifically related to this bug, is it? >> > > It's a bug in the zipfs provider and I can file a new JBS issue for the > zipfs change. I prefer to push them in the same changeset that reduces > zipfs's privileges and added tests to run with security manager. Sure, it is fine with me to include them with this. I just wanted to make sure I understood the changes. --Sean From mandy.chung at oracle.com Thu Apr 24 23:07:30 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Apr 2014 16:07:30 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <535958DA.2010307@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com> Message-ID: <53599932.4090307@oracle.com> Thanks Sean. I have updated the webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/ Erik - I'm including build-dev to review the build change for java.policy file. Thanks Mandy On 4/24/14 11:32 AM, Sean Mullan wrote: > On 04/23/2014 05:29 PM, Mandy Chung wrote: >> >> On 4/23/2014 1:10 PM, Sean Mullan wrote: >>> Just a few comments: >>> >>> 1. When you write a test that uses the jtreg /policy option, the >>> policy file overrides the system policy file. If the test depends on a >>> standard extension, then you may get SecurityExceptions unless >>> additional perms are granted. Thus, there are quite a few tests that >>> define their own policy files and duplicate the grant statement for >>> extensions from the system policy: >>> >>> grant codeBase "file:${{java.ext.dirs}}/*" { >>> permission java.security.AllPermission; >>> } >>> >>> These tests should be modified to only grant the necessary >>> permissions. However, ideally I think that a better solution would be >>> to add a jtreg /policy option that doesn't override the system policy >>> file, but rather appends to it, for example, using "==" : >>> >> >> I suspect most of the tests only want to grant the permissions for the >> test itself rather than overriding the system policy file. Having a new >> jtreg/policy option not to override the system policy file may be a >> better solution. This would avoid updating the test's policy file >> every time the system's policy is modified. On the other hand, I think >> the test policy may not need to grant permissions to the extensions >> directory if it doesn't use the classes in extensions. It's a good >> opportunity to clean that up. This will require some closer look at the >> tests. >> >> If you are okay, I'd like to separate the test's custom policy update as >> a follow-on work. > > That's fine with me. > >>> @run main/othervm/policy==test.policy >>> >>> (this is the reverse behavior of the java.security.policy system >>> property, so it might be a little confusing, so maybe it is better to >>> add a new option) >>> >> >> "==" is a confusing syntax. -Djava.security.policy==test.policy >> overrides the system policy file ("=" prefix) whereas jtreg uses the >> reverse syntax? I think it would be better to make jtreg/policy >> consistent with -Djava.security.policy (i.e. default is to extend the >> system java.security). > > Would be nice, but not sure if we can change it at this point. Anyway, > one of us should file a jtreg RFE. > >>> 3. jdk/nio/zipfs/ZipFileSystem.java >>> >>> If I understand the changes, the previous code would throw >>> SecurityExceptions when run under a SecurityManager? It's not >>> specifically related to this bug, is it? >>> >> >> It's a bug in the zipfs provider and I can file a new JBS issue for the >> zipfs change. I prefer to push them in the same changeset that reduces >> zipfs's privileges and added tests to run with security manager. > > Sure, it is fine with me to include them with this. I just wanted to > make sure I understood the changes. > > --Sean From erik.joelsson at oracle.com Fri Apr 25 07:55:45 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Apr 2014 09:55:45 +0200 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <53599932.4090307@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com> <53599932.4090307@oracle.com> Message-ID: <535A1501.20500@oracle.com> Hello Mandy, The logic looks fine. Just some style issues. I would like indentation for the conditionals to be 2 spaces as is currently the standard in the makefiles. I would also like to have POLICY_SRC_LIST to be declared empty with := instead of just =. We only use = assignment when explicitly needed. /Erik On 2014-04-25 01:07, Mandy Chung wrote: > Thanks Sean. > > I have updated the webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/ > > Erik - I'm including build-dev to review the build change for > java.policy file. > > Thanks > Mandy > > On 4/24/14 11:32 AM, Sean Mullan wrote: >> On 04/23/2014 05:29 PM, Mandy Chung wrote: >>> >>> On 4/23/2014 1:10 PM, Sean Mullan wrote: >>>> Just a few comments: >>>> >>>> 1. When you write a test that uses the jtreg /policy option, the >>>> policy file overrides the system policy file. If the test depends on a >>>> standard extension, then you may get SecurityExceptions unless >>>> additional perms are granted. Thus, there are quite a few tests that >>>> define their own policy files and duplicate the grant statement for >>>> extensions from the system policy: >>>> >>>> grant codeBase "file:${{java.ext.dirs}}/*" { >>>> permission java.security.AllPermission; >>>> } >>>> >>>> These tests should be modified to only grant the necessary >>>> permissions. However, ideally I think that a better solution would be >>>> to add a jtreg /policy option that doesn't override the system policy >>>> file, but rather appends to it, for example, using "==" : >>>> >>> >>> I suspect most of the tests only want to grant the permissions for the >>> test itself rather than overriding the system policy file. Having a new >>> jtreg/policy option not to override the system policy file may be a >>> better solution. This would avoid updating the test's policy file >>> every time the system's policy is modified. On the other hand, I >>> think >>> the test policy may not need to grant permissions to the extensions >>> directory if it doesn't use the classes in extensions. It's a good >>> opportunity to clean that up. This will require some closer look at the >>> tests. >>> >>> If you are okay, I'd like to separate the test's custom policy >>> update as >>> a follow-on work. >> >> That's fine with me. >> >>>> @run main/othervm/policy==test.policy >>>> >>>> (this is the reverse behavior of the java.security.policy system >>>> property, so it might be a little confusing, so maybe it is better to >>>> add a new option) >>>> >>> >>> "==" is a confusing syntax. -Djava.security.policy==test.policy >>> overrides the system policy file ("=" prefix) whereas jtreg uses the >>> reverse syntax? I think it would be better to make jtreg/policy >>> consistent with -Djava.security.policy (i.e. default is to extend the >>> system java.security). >> >> Would be nice, but not sure if we can change it at this point. >> Anyway, one of us should file a jtreg RFE. >> >>>> 3. jdk/nio/zipfs/ZipFileSystem.java >>>> >>>> If I understand the changes, the previous code would throw >>>> SecurityExceptions when run under a SecurityManager? It's not >>>> specifically related to this bug, is it? >>>> >>> >>> It's a bug in the zipfs provider and I can file a new JBS issue for the >>> zipfs change. I prefer to push them in the same changeset that reduces >>> zipfs's privileges and added tests to run with security manager. >> >> Sure, it is fine with me to include them with this. I just wanted to >> make sure I understood the changes. >> >> --Sean > From sean.mullan at oracle.com Fri Apr 25 14:36:32 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Apr 2014 10:36:32 -0400 Subject: JEP Review Request: Improve Security Manager Performance Message-ID: <535A72F0.3050800@oracle.com> Please review a draft of a proposed research JEP to improve the performance of the Security Manager: http://cr.openjdk.java.net/~mullan/jeps/Improve-Security-Manager-Performance.00 I am particularly interested in any experience you have measuring or profiling the performance of your code when run with a Security Manager, and any potential ideas for optimizations that you may have. Thanks, Sean From david.lloyd at redhat.com Fri Apr 25 14:54:21 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Apr 2014 09:54:21 -0500 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <535A72F0.3050800@oracle.com> References: <535A72F0.3050800@oracle.com> Message-ID: <535A771D.7010302@redhat.com> On 04/25/2014 09:36 AM, Sean Mullan wrote: > Please review a draft of a proposed research JEP to improve the > performance of the Security Manager: > > http://cr.openjdk.java.net/~mullan/jeps/Improve-Security-Manager-Performance.00 > > I am particularly interested in any experience you have measuring or > profiling the performance of your code when run with a Security Manager, > and any potential ideas for optimizations that you may have. Great! Security manager performance is a constant source of difficulty for us. Some optimization ideas I've had in the past: - Add a ParametricPrivileged*Action which accepts a single parameter, with corresponding doPrivileged()-style methods which accept a parameter of the same type. This can in many cases mitigate the need to construct new PrivilegedActions, encouraging reuse instead. - Use annotations to designate privileged methods (perhaps in combination with a requirement that the annotated method be package-private or private). The main expense points we've observed in the past mainly revolve around the actual permission check (chiefly the compilation of the ACC) and doPrivileged itself though, so in terms of simply optimizing code, those two areas seem like the best place to start; I think I could probably get more detailed information about this, time permitting. Relatedly, it would also be nice if there were some way to simplify or improve the JAAS Subject association mechanism, which also relies on the ACC, causing a substantial enough performance cost that (AFAICT) no major Java EE application server actually prefers this mechanism. -- - DML From mandy.chung at oracle.com Fri Apr 25 15:42:02 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 25 Apr 2014 08:42:02 -0700 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <535A1501.20500@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com> <53599932.4090307@oracle.com> <535A1501.20500@oracle.com> Message-ID: <535A824A.6090606@oracle.com> On 4/25/2014 12:55 AM, Erik Joelsson wrote: > Hello Mandy, > > The logic looks fine. Just some style issues. I would like indentation > for the conditionals to be 2 spaces as is currently the standard in > the makefiles. I would also like to have POLICY_SRC_LIST to be > declared empty with := instead of just =. We only use = assignment > when explicitly needed. Thanks for the review Erik. I'll make the change before the push. Mandy > > /Erik > > On 2014-04-25 01:07, Mandy Chung wrote: >> Thanks Sean. >> >> I have updated the webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/ >> >> Erik - I'm including build-dev to review the build change for >> java.policy file. >> >> Thanks >> Mandy >> >> On 4/24/14 11:32 AM, Sean Mullan wrote: >>> On 04/23/2014 05:29 PM, Mandy Chung wrote: >>>> >>>> On 4/23/2014 1:10 PM, Sean Mullan wrote: >>>>> Just a few comments: >>>>> >>>>> 1. When you write a test that uses the jtreg /policy option, the >>>>> policy file overrides the system policy file. If the test depends >>>>> on a >>>>> standard extension, then you may get SecurityExceptions unless >>>>> additional perms are granted. Thus, there are quite a few tests that >>>>> define their own policy files and duplicate the grant statement for >>>>> extensions from the system policy: >>>>> >>>>> grant codeBase "file:${{java.ext.dirs}}/*" { >>>>> permission java.security.AllPermission; >>>>> } >>>>> >>>>> These tests should be modified to only grant the necessary >>>>> permissions. However, ideally I think that a better solution would be >>>>> to add a jtreg /policy option that doesn't override the system policy >>>>> file, but rather appends to it, for example, using "==" : >>>>> >>>> >>>> I suspect most of the tests only want to grant the permissions for the >>>> test itself rather than overriding the system policy file. Having a >>>> new >>>> jtreg/policy option not to override the system policy file may be a >>>> better solution. This would avoid updating the test's policy file >>>> every time the system's policy is modified. On the other hand, I >>>> think >>>> the test policy may not need to grant permissions to the extensions >>>> directory if it doesn't use the classes in extensions. It's a good >>>> opportunity to clean that up. This will require some closer look at >>>> the >>>> tests. >>>> >>>> If you are okay, I'd like to separate the test's custom policy >>>> update as >>>> a follow-on work. >>> >>> That's fine with me. >>> >>>>> @run main/othervm/policy==test.policy >>>>> >>>>> (this is the reverse behavior of the java.security.policy system >>>>> property, so it might be a little confusing, so maybe it is better to >>>>> add a new option) >>>>> >>>> >>>> "==" is a confusing syntax. -Djava.security.policy==test.policy >>>> overrides the system policy file ("=" prefix) whereas jtreg uses the >>>> reverse syntax? I think it would be better to make jtreg/policy >>>> consistent with -Djava.security.policy (i.e. default is to extend the >>>> system java.security). >>> >>> Would be nice, but not sure if we can change it at this point. >>> Anyway, one of us should file a jtreg RFE. >>> >>>>> 3. jdk/nio/zipfs/ZipFileSystem.java >>>>> >>>>> If I understand the changes, the previous code would throw >>>>> SecurityExceptions when run under a SecurityManager? It's not >>>>> specifically related to this bug, is it? >>>>> >>>> >>>> It's a bug in the zipfs provider and I can file a new JBS issue for >>>> the >>>> zipfs change. I prefer to push them in the same changeset that >>>> reduces >>>> zipfs's privileges and added tests to run with security manager. >>> >>> Sure, it is fine with me to include them with this. I just wanted to >>> make sure I understood the changes. >>> >>> --Sean >> > From sean.mullan at oracle.com Fri Apr 25 19:35:37 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Apr 2014 15:35:37 -0400 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <535A771D.7010302@redhat.com> References: <535A72F0.3050800@oracle.com> <535A771D.7010302@redhat.com> Message-ID: <535AB909.5010003@oracle.com> On 04/25/2014 10:54 AM, David M. Lloyd wrote: > On 04/25/2014 09:36 AM, Sean Mullan wrote: >> Please review a draft of a proposed research JEP to improve the >> performance of the Security Manager: >> >> http://cr.openjdk.java.net/~mullan/jeps/Improve-Security-Manager-Performance.00 >> >> >> I am particularly interested in any experience you have measuring or >> profiling the performance of your code when run with a Security Manager, >> and any potential ideas for optimizations that you may have. > > Great! Security manager performance is a constant source of difficulty > for us. > > Some optimization ideas I've had in the past: > > - Add a ParametricPrivileged*Action which accepts a single > parameter, with corresponding doPrivileged()-style methods which accept > a parameter of the same type. This can in many cases mitigate the need > to construct new PrivilegedActions, encouraging reuse instead. Can you give an example of how this works so I can understand it better? > - Use annotations to designate privileged methods (perhaps in > combination with a requirement that the annotated method be > package-private or private). I agree that sounds useful, but how does it improve performance? > The main expense points we've observed in the past mainly revolve around > the actual permission check (chiefly the compilation of the ACC) and > doPrivileged itself though, so in terms of simply optimizing code, those > two areas seem like the best place to start; I think I could probably > get more detailed information about this, time permitting. I agree. The permission check is expensive, although doPrivileged is also an area that we would like to improve because it impacts code regardless if they are running with a Security Manager. > Relatedly, it would also be nice if there were some way to simplify or > improve the JAAS Subject association mechanism, which also relies on the > ACC, causing a substantial enough performance cost that (AFAICT) no > major Java EE application server actually prefers this mechanism. Yes, this one I already know about and hope to improve and test as part of this JEP. Thanks, Sean From david.lloyd at redhat.com Fri Apr 25 19:44:49 2014 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 25 Apr 2014 14:44:49 -0500 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <535AB909.5010003@oracle.com> References: <535A72F0.3050800@oracle.com> <535A771D.7010302@redhat.com> <535AB909.5010003@oracle.com> Message-ID: <535ABB31.7080907@redhat.com> On 04/25/2014 02:35 PM, Sean Mullan wrote: > On 04/25/2014 10:54 AM, David M. Lloyd wrote: >> On 04/25/2014 09:36 AM, Sean Mullan wrote: >>> Please review a draft of a proposed research JEP to improve the >>> performance of the Security Manager: >>> >>> http://cr.openjdk.java.net/~mullan/jeps/Improve-Security-Manager-Performance.00 >>> >>> >>> >>> I am particularly interested in any experience you have measuring or >>> profiling the performance of your code when run with a Security Manager, >>> and any potential ideas for optimizations that you may have. >> >> Great! Security manager performance is a constant source of difficulty >> for us. >> >> Some optimization ideas I've had in the past: >> >> - Add a ParametricPrivileged*Action which accepts a single >> parameter, with corresponding doPrivileged()-style methods which accept >> a parameter of the same type. This can in many cases mitigate the need >> to construct new PrivilegedActions, encouraging reuse instead. > > Can you give an example of how this works so I can understand it better? Sure, basically the interfaces look like this: public interface ParametricPrivilegedAction { T run(P parameter); } public interface ParametricPrivilegedExceptionAction { T run(P parameter) throws PrivilegedActionException; } then we have these new methods on AccessController: public static T doPrivileged(P parameter, ParametricPrivilegedAction action); public static T doPrivileged(P parameter, ParametricPrivilegedExceptionAction action) throws PrivilegedActionException; ...with the other additional variants on AccessController (i.e. accepting an ACC, an ACC + a permission set, *WithCombiner variants). Then the same action object can be reused, as long as there is a single object parameter (a fairly common case by my experience). >> - Use annotations to designate privileged methods (perhaps in >> combination with a requirement that the annotated method be >> package-private or private). > > I agree that sounds useful, but how does it improve performance? It improves performance by completely eliminating the need to construct privileged actions for most use cases, and also by removing bumps to exception handling. Privileged actions which are methods (particularly private or static methods) can be invoked with the most minimal overhead possible, regardless of the number of parameters the action requires. The value of simplifying the programming model is also substantial I think, though maybe not directly performance benefiting. >> The main expense points we've observed in the past mainly revolve around >> the actual permission check (chiefly the compilation of the ACC) and >> doPrivileged itself though, so in terms of simply optimizing code, those >> two areas seem like the best place to start; I think I could probably >> get more detailed information about this, time permitting. > > I agree. The permission check is expensive, although doPrivileged is > also an area that we would like to improve because it impacts code > regardless if they are running with a Security Manager. > >> Relatedly, it would also be nice if there were some way to simplify or >> improve the JAAS Subject association mechanism, which also relies on the >> ACC, causing a substantial enough performance cost that (AFAICT) no >> major Java EE application server actually prefers this mechanism. > > Yes, this one I already know about and hope to improve and test as part > of this JEP. -- - DML From xuelei.fan at oracle.com Tue Apr 29 14:05:19 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 29 Apr 2014 22:05:19 +0800 Subject: Code review request, a simple fix to remove the incorrect comment in RSAClientKeyExchange.java Message-ID: <535FB19F.9030702@oracle.com> Hi, As this is a simple comment fix, I will not generate a webrev as general. In sun/security/ssl/RSAClientKeyExchange.java: 116 // Cannot generate key here, please don't use Cipher.UNWRAP_MODE! 117 cipher.init(Cipher.UNWRAP_MODE, privateKey, 118 new TlsRsaPremasterSecretParameterSpec( 119 maxVersion.v, currentVersion.v), 120 generator); We've a comment indicating not to use UNWRAP_MODE. However, in line 117, the UNWRAP_MODE is used instead in a recent fix. The comment need to go. I will remove line 116 in this fix. - // Cannot generate key here, please don't use Cipher.UNWRAP_MODE! Thanks, Xuelei From Alan.Bateman at oracle.com Tue Apr 29 14:57:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Apr 2014 15:57:34 +0100 Subject: Review request: 8040059 Change default policy for extensions to no permission In-Reply-To: <53599932.4090307@oracle.com> References: <5356C58D.5070805@oracle.com> <53581E36.7030004@oracle.com> <535830AC.5070003@oracle.com> <535958DA.2010307@oracle.com> <53599932.4090307@oracle.com> Message-ID: <535FBDDE.8040707@oracle.com> On 25/04/2014 00:07, Mandy Chung wrote: > Thanks Sean. > > I have updated the webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8040059/webrev.01/ > > Erik - I'm including build-dev to review the build change for > java.policy file. Just catching up on this thread. The update to ZipFileSystem and the policy file look good to me. I only skimmed over the test changes and agree with the the comments that tests usually just want to configure the policy for the test and not have to repeat the grants in the system policy. A minor comment on the policy files is that there is mix of indentation styles (4 and 8 in the same file in some cases). There is also inconsistent indentation in Ext_AllPolicy.java (pre-dates your changes). -Alan From sean.mullan at oracle.com Tue Apr 29 18:26:18 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 29 Apr 2014 14:26:18 -0400 Subject: Code review request, a simple fix to remove the incorrect comment in RSAClientKeyExchange.java In-Reply-To: <535FB19F.9030702@oracle.com> References: <535FB19F.9030702@oracle.com> Message-ID: <535FEECA.2070804@oracle.com> Looks fine to me. --Sean On 04/29/2014 10:05 AM, Xuelei Fan wrote: > Hi, > > As this is a simple comment fix, I will not generate a webrev as general. > > In sun/security/ssl/RSAClientKeyExchange.java: > > 116 // Cannot generate key here, please don't use Cipher.UNWRAP_MODE! > 117 cipher.init(Cipher.UNWRAP_MODE, privateKey, > 118 new TlsRsaPremasterSecretParameterSpec( > 119 maxVersion.v, currentVersion.v), > 120 generator); > > We've a comment indicating not to use UNWRAP_MODE. However, in line 117, > the UNWRAP_MODE is used instead in a recent fix. The comment need to > go. I will remove line 116 in this fix. > > - // Cannot generate key here, please don't use Cipher.UNWRAP_MODE! > > Thanks, > Xuelei > From sean.mullan at oracle.com Tue Apr 29 20:48:55 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 29 Apr 2014 16:48:55 -0400 Subject: JDK 9 Review Request for 8038349: Signing XML with DSA throws Exception when key is larger than 1024 bits Message-ID: <53601037.3090307@oracle.com> Please review the following change which adds support for 2048-bit DSA keys and the DSA-SHA256 algorithm to the XML Signature implementation: webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038349/webrev.00/ JDK 8 already includes the underlying support for both of these in the Sun provider. For 2048 bit keys, the ASN.1 parsing code in the XML Signature layer needed to be adapted to handle 2048 bit keys, and for SHA-256 it was just a matter of registering the algorithm URI and instantiating a Signature object with the SHA256WithDSA algorithm. Thanks, Sean From xuelei.fan at oracle.com Wed Apr 30 02:26:43 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 30 Apr 2014 10:26:43 +0800 Subject: JDK 9 Review Request for 8038349: Signing XML with DSA throws Exception when key is larger than 1024 bits In-Reply-To: <53601037.3090307@oracle.com> References: <53601037.3090307@oracle.com> Message-ID: <53605F63.1030003@oracle.com> Minor comments. algorithms/implementations/SignatureDSA.java ============================================ 51 public static final String URI = XMLSignature.ALGO_ID_SIGNATURE_DSA; With this update, this variable can be declared as private, I think. Is it still necessary to define this variable? I think we may want to use the uniform XMLSignature definition instead. security/utils/JavaUtils.java ============================= 162 public static byte[] convertASN1toXMLDSIG ... 201 public static byte[] convertXMLDSIGtoASN1 ... As the methods above only apply to DSA, and the class now is in utils package, we might want to use a little bit more instinctive method name to indicate the DSA algorithm, for example, convertDsaASN1toXMLDSIG. Need more time to read the update in JavaUtils.java Xuelei On 4/30/2014 4:48 AM, Sean Mullan wrote: > Please review the following change which adds support for 2048-bit DSA > keys and the DSA-SHA256 algorithm to the XML Signature implementation: > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038349/webrev.00/ > > JDK 8 already includes the underlying support for both of these in the > Sun provider. For 2048 bit keys, the ASN.1 parsing code in the XML > Signature layer needed to be adapted to handle 2048 bit keys, and for > SHA-256 it was just a matter of registering the algorithm URI and > instantiating a Signature object with the SHA256WithDSA algorithm. > > Thanks, > Sean From sean.mullan at oracle.com Wed Apr 30 12:39:31 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 30 Apr 2014 08:39:31 -0400 Subject: JDK 9 Review Request for 8038349: Signing XML with DSA throws Exception when key is larger than 1024 bits In-Reply-To: <53605F63.1030003@oracle.com> References: <53601037.3090307@oracle.com> <53605F63.1030003@oracle.com> Message-ID: <5360EF03.7060004@oracle.com> On 04/29/2014 10:26 PM, Xuelei Fan wrote: > Minor comments. > > algorithms/implementations/SignatureDSA.java > ============================================ > 51 public static final String URI = XMLSignature.ALGO_ID_SIGNATURE_DSA; > > With this update, this variable can be declared as private, I think. > > Is it still necessary to define this variable? I think we may want to > use the uniform XMLSignature definition instead. I will remove it. I was a little concerned there may be someone depending on it (and didn't want to diverge from the Apache code), but most likely not. > security/utils/JavaUtils.java > ============================= > 162 public static byte[] convertASN1toXMLDSIG ... > 201 public static byte[] convertXMLDSIGtoASN1 ... > > As the methods above only apply to DSA, and the class now is in utils > package, we might want to use a little bit more instinctive method name > to indicate the DSA algorithm, for example, convertDsaASN1toXMLDSIG. Yes, sounds like a good suggestion. > Need more time to read the update in JavaUtils.java Ok, thanks. --Sean > > Xuelei > > On 4/30/2014 4:48 AM, Sean Mullan wrote: >> Please review the following change which adds support for 2048-bit DSA >> keys and the DSA-SHA256 algorithm to the XML Signature implementation: >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8038349/webrev.00/ >> >> JDK 8 already includes the underlying support for both of these in the >> Sun provider. For 2048 bit keys, the ASN.1 parsing code in the XML >> Signature layer needed to be adapted to handle 2048 bit keys, and for >> SHA-256 it was just a matter of registering the algorithm URI and >> instantiating a Signature object with the SHA256WithDSA algorithm. >> >> Thanks, >> Sean > From fweimer at redhat.com Wed Apr 30 15:16:09 2014 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 30 Apr 2014 17:16:09 +0200 Subject: JEP Review Request: Improve Security Manager Performance In-Reply-To: <535A771D.7010302@redhat.com> References: <535A72F0.3050800@oracle.com> <535A771D.7010302@redhat.com> Message-ID: <536113B9.1060005@redhat.com> On 04/25/2014 04:54 PM, David M. Lloyd wrote: > Relatedly, it would also be nice if there were some way to simplify or > improve the JAAS Subject association mechanism, which also relies on the > ACC, causing a substantial enough performance cost that (AFAICT) no > major Java EE application server actually prefers this mechanism. Hotspot is supposed to optimize this scenario eventually, eliding the allocation and inlining the code, as long as you use a lambda. Maybe we won't get there during OpenJDK 9, but optimizing this by hand looks a lot like defeat to me. -- Florian Weimer / Red Hat Product Security Team