(10) RFR of JDK-8184234: sun.security.provider.AuthPolicyFile$PolicyEntry.toString() throws MissingResourceException
Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8184234 webrev: http://cr.openjdk.java.net/~mli/8184234/webrev.00/ Thank you -Hamlin
Re: (10) RFR of JDK-8184165: sun.security.provider.PolicyFile$PolicyEntry.toString() throws MissingResourceException
I manually checked *Resources.java under sun/security and usage of them,
my investigation shows that overall quality of "static" resource usage
is good (by "static" I mean it uses hard code resource string like
rb.getString("") rather than rb.getString(aStringVariable) ), except
of this issue and another new issue:
https://bugs.openjdk.java.net/browse/JDK-8184234, in which similar issue
in sun.security.provider.AuthPolicyFile$PolicyEntry is reported.
For new issue JDK-8184234, it existed since jdk6 to 10.
Thank you
-Hamlin
On 2017/7/12 11:36, Hamlin Li wrote:
On 2017/7/12 11:06, Weijun Wang wrote:
On Jul 12, 2017, at 11:03 AM, Hamlin Li wrote:
Hi Max,
On 2017/7/12 10:50, Weijun Wang wrote:
Change looks fine.
Please remember to add a noreg-trivial label.
Added the label, and will push the change.
Also, can you do some more investigation when this starts to
happen? The bug says affected versions are 9 and 10 but
PolicyFile.java has been there long long ago. Was there a regression?
The same code is there since jdk6
(http://hg.openjdk.java.net/jdk6/jdk6/jdk) , I did not check jdk5...
I don't think it's a regression, it should be just a missing
resource, as the failure only occurs when accessing very details of
sun.security.provider.PolicyFile by reflection, I guess people
seldom do that.
Is it easy to verify?
I asked if it’s a regression because I remember some time last year
there is some rearrangement of codes in this area.
I just checked jdk6, 7, 8. You're right, there is a regression in jdk 8.
In summary,
in jdk6, the issue exists;
in jdk7 some resources were added which I believe fixed this issue;
(too many, I can not list it here.)
in jdk8 the added resources were totally removed, and another 2
resources are added:
> {"duplicate.keystore.domain.name","duplicate keystore domain
name: {0}"},
> {"duplicate.keystore.name","duplicate keystore name: {0}"},
But currently I don't know how big the change impacts, as there are
many resource usage under sun/security which use
sun/security/util/[Resources|AuthResources].java
sun/security/util/Resources in jdk6,
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/62df9772b849/src/share/classes/sun/security/util/Resources.java
sun/security/util/Resources in jdk7,
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/share/classes/sun/security/util/Resources.java
sun/security/util/Resources in jdk8,
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/security/util/Resources.java
Thank you
-Hamlin
--Max
Thank you
-Hamlin
Thanks
Max
On Jul 12, 2017, at 10:28 AM, Hamlin Li
wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8184165
webrev: http://cr.openjdk.java.net/~mli/8184165/webrev.00/
Thank you
-Hamlin
Re: (10) RFR of JDK-8184165: sun.security.provider.PolicyFile$PolicyEntry.toString() throws MissingResourceException
On 2017/7/12 11:06, Weijun Wang wrote:
On Jul 12, 2017, at 11:03 AM, Hamlin Li wrote:
Hi Max,
On 2017/7/12 10:50, Weijun Wang wrote:
Change looks fine.
Please remember to add a noreg-trivial label.
Added the label, and will push the change.
Also, can you do some more investigation when this starts to happen? The bug
says affected versions are 9 and 10 but PolicyFile.java has been there long
long ago. Was there a regression?
The same code is there since jdk6 (http://hg.openjdk.java.net/jdk6/jdk6/jdk) ,
I did not check jdk5...
I don't think it's a regression, it should be just a missing resource, as the
failure only occurs when accessing very details of
sun.security.provider.PolicyFile by reflection, I guess people seldom do that.
Is it easy to verify?
I asked if it’s a regression because I remember some time last year there is
some rearrangement of codes in this area.
I just checked jdk6, 7, 8. You're right, there is a regression in jdk 8.
In summary,
in jdk6, the issue exists;
in jdk7 some resources were added which I believe fixed this issue;
(too many, I can not list it here.)
in jdk8 the added resources were totally removed, and another 2
resources are added:
> {"duplicate.keystore.domain.name","duplicate keystore domain
name: {0}"},
> {"duplicate.keystore.name","duplicate keystore name: {0}"},
But currently I don't know how big the change impacts, as there are many
resource usage under sun/security which use
sun/security/util/[Resources|AuthResources].java
sun/security/util/Resources in jdk6,
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/62df9772b849/src/share/classes/sun/security/util/Resources.java
sun/security/util/Resources in jdk7,
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/share/classes/sun/security/util/Resources.java
sun/security/util/Resources in jdk8,
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/security/util/Resources.java
Thank you
-Hamlin
--Max
Thank you
-Hamlin
Thanks
Max
On Jul 12, 2017, at 10:28 AM, Hamlin Li wrote:
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8184165
webrev: http://cr.openjdk.java.net/~mli/8184165/webrev.00/
Thank you
-Hamlin
Re: (10) RFR of JDK-8184165: sun.security.provider.PolicyFile$PolicyEntry.toString() throws MissingResourceException
> On Jul 12, 2017, at 11:03 AM, Hamlin Li wrote: > > Hi Max, > > On 2017/7/12 10:50, Weijun Wang wrote: >> Change looks fine. >> >> Please remember to add a noreg-trivial label. > Added the label, and will push the change. >> Also, can you do some more investigation when this starts to happen? The bug >> says affected versions are 9 and 10 but PolicyFile.java has been there long >> long ago. Was there a regression? > The same code is there since jdk6 (http://hg.openjdk.java.net/jdk6/jdk6/jdk) > , I did not check jdk5... > I don't think it's a regression, it should be just a missing resource, as the > failure only occurs when accessing very details of > sun.security.provider.PolicyFile by reflection, I guess people seldom do that. Is it easy to verify? I asked if it’s a regression because I remember some time last year there is some rearrangement of codes in this area. --Max > > Thank you > -Hamlin >> >> Thanks >> Max >> >>> On Jul 12, 2017, at 10:28 AM, Hamlin Li wrote: >>> >>> Would you please review the below patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8184165 >>> >>> webrev: http://cr.openjdk.java.net/~mli/8184165/webrev.00/ >>> >>> >>> Thank you >>> >>> -Hamlin >>> >
Re: (10) RFR of JDK-8184165: sun.security.provider.PolicyFile$PolicyEntry.toString() throws MissingResourceException
Hi Max, On 2017/7/12 10:50, Weijun Wang wrote: Change looks fine. Please remember to add a noreg-trivial label. Added the label, and will push the change. Also, can you do some more investigation when this starts to happen? The bug says affected versions are 9 and 10 but PolicyFile.java has been there long long ago. Was there a regression? The same code is there since jdk6 (http://hg.openjdk.java.net/jdk6/jdk6/jdk) , I did not check jdk5... I don't think it's a regression, it should be just a missing resource, as the failure only occurs when accessing very details of sun.security.provider.PolicyFile by reflection, I guess people seldom do that. Thank you -Hamlin Thanks Max On Jul 12, 2017, at 10:28 AM, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8184165 webrev: http://cr.openjdk.java.net/~mli/8184165/webrev.00/ Thank you -Hamlin
Re: (10) RFR of JDK-8184165: sun.security.provider.PolicyFile$PolicyEntry.toString() throws MissingResourceException
Change looks fine. Please remember to add a noreg-trivial label. Also, can you do some more investigation when this starts to happen? The bug says affected versions are 9 and 10 but PolicyFile.java has been there long long ago. Was there a regression? Thanks Max > On Jul 12, 2017, at 10:28 AM, Hamlin Li wrote: > > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8184165 > > webrev: http://cr.openjdk.java.net/~mli/8184165/webrev.00/ > > > Thank you > > -Hamlin >
(10) RFR of JDK-8184165: sun.security.provider.PolicyFile$PolicyEntry.toString() throws MissingResourceException
Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8184165 webrev: http://cr.openjdk.java.net/~mli/8184165/webrev.00/ Thank you -Hamlin
Re: RFR: 8184208: update class="striped" tables for accessibility
On 07/11/2017 04:02 PM, Brian Burkhalter wrote: On Jul 11, 2017, at 2:39 PM, Jonathan Gibbons mailto:jonathan.gibb...@oracle.com>> wrote: Please review this auto-generated update to improve the accessibility of many of the tables in the API docs for the java.base module. Looks all right to me. All the modifiied tables have been visually checked with an accessibility checker. There does not however appear to be a visual difference between the JDK 9 javadoc and the javadoc generated in a JDK 10 clone with this patch applied. Brian Brian, Yes, the differences will show up when using a screen reader or some form of accessibility checker. There should not be any noticeable difference for most users. -- Jon
Re: RFR: 8184208: update class="striped" tables for accessibility
On Jul 11, 2017, at 2:39 PM, Jonathan Gibbons wrote: > Please review this auto-generated update to improve the accessibility of many > of the tables > in the API docs for the java.base module. Looks all right to me. > All the modifiied tables have been visually checked with an accessibility > checker. There does not however appear to be a visual difference between the JDK 9 javadoc and the javadoc generated in a JDK 10 clone with this patch applied. Brian
RFR: 8184208: update class="striped" tables for accessibility
Please review this auto-generated update to improve the accessibility of many of the tables in the API docs for the java.base module. The changes are just to the HTML markup for selected tables; there is no change to the wording of any documentation. This update was generated by a utility program that looks for tables using the CSS style class "striped", and updates those tables as follows: * header cells () in the now declare scope="col" * the first data cell () in each row in the are changed to and declare scope="row". Although these cells are changed from to , the CSS still uses font-weight-normal for these cells. The changes are in line with HTML 5 and WCAG 2.0. This update does not include the following tables, which will be done separately (manually) * tables with CSS class "borderless" (18), "plain" (37), or no class (6) * tables in java.time.chrono (5): although these table use "striped", the first column does not contain unique values, and is therefore unsuited for the automated update All the modifiied tables have been visually checked with an accessibility checker. JBS: https://bugs.openjdk.java.net/browse/JDK-8184208 Webrev: http://cr.openjdk.java.net/~jjg/8184208/webrev.00/ API: http://cr.openjdk.java.net/~jjg/8184208/api.00/ -- Jon
RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider
Hi Sean, thanks for coming back on this. > > I'd like to ping you again upon that question. In the meanwhile I have > produced a standalone test case and could verify that changing to x509Cert > vs. the original cert for obtaining the SigAlgName would be a fix. I can share > the test with you, however, you'll need the security provider 'IAIK' which is > not OpenSource but can be obtained for free for educational/research > purposes here [1]. > > > > Shall I open a Bug for that and propose a fix? Or is using the x509Cert at > > this > place the wrong thing to do here for reasons? I'd appreciate some feedback. > > Technically, I don't think this is a bug. IAIK is using a non-standard > algorithm for the signature algorithm of the certificate. The Standard > Algorithm Names specification [1] says that "SHA1withRSA" is the correct > name. > > The JDK algorithm constraints implementation should not have to > accommodate non-compliant certificates. > > Tony and I don't quite recall why this change was made as part of > JDK-8174849, but in general the conversion to > sun.security.x509.X509CertImpl is done so that we can access parts of > the certificate in a more performance friendly manner or if they are not > accessible via the standard APIs. This is not one of those cases. > However, I can't think of any specific reason right now we could not use > X509CertImpl instead but would like to think about it some more. > > Have you asked IAIK about their non-compliance? > > [1] > http://download.java.net/java/jdk9/docs/specs/security/standard- > names.html#signature-algorithms Well, probably you are right that it is not a bug - at least when you look at the documentation of Java9 (the link that you have cited). However, if we look at the documentation of X509Certificate, it's not that clear, resp. it wasn't for pre JDK9 releases. JDK9 mentions in [1] an algorithm name example of "SHA256withRSA". However, the documentation for 8 [2] and probably all older JDKs talks about an example of "SHA-1/DSA". So this older type of algorithm names must have existed at some time - and it used to work with JDKs <= 8. However, the security standard names documentation already existed for JDK8 and probably earlier. As for the reason why IAIK has not changed that (yet), maybe Dieter on cc can comment. He mentioned to me that some discussion about that had been done within IAIK but the change was never really dared. So, I guess I would be fine if this could at least be changed for JDKs <= 8 for compatibility reasons. I can understand if for JDK >= 9 we say this is a new release and the standard algorithm names shall be enforced. Wouldn't that be a good compromise? In any case, from what you are saying, I take that I can safely patch our JDK distribution with this change without doing a bad thing to security in general, wouldn't you agree? Thanks & best regards Christoph [1] http://download.java.net/java/jdk9/docs/api/java/security/cert/X509Certificate.html#getSigAlgName-- [2] https://docs.oracle.com/javase/8/docs/api/javax/security/cert/X509Certificate.html#getSigAlgName--
Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider
Hi Christoph, On 7/11/17 5:43 AM, Langer, Christoph wrote: Hi, I'd like to ping you again upon that question. In the meanwhile I have produced a standalone test case and could verify that changing to x509Cert vs. the original cert for obtaining the SigAlgName would be a fix. I can share the test with you, however, you'll need the security provider 'IAIK' which is not OpenSource but can be obtained for free for educational/research purposes here [1]. Shall I open a Bug for that and propose a fix? Or is using the x509Cert at this place the wrong thing to do here for reasons? I'd appreciate some feedback. Technically, I don't think this is a bug. IAIK is using a non-standard algorithm for the signature algorithm of the certificate. The Standard Algorithm Names specification [1] says that "SHA1withRSA" is the correct name. The JDK algorithm constraints implementation should not have to accommodate non-compliant certificates. Tony and I don't quite recall why this change was made as part of JDK-8174849, but in general the conversion to sun.security.x509.X509CertImpl is done so that we can access parts of the certificate in a more performance friendly manner or if they are not accessible via the standard APIs. This is not one of those cases. However, I can't think of any specific reason right now we could not use X509CertImpl instead but would like to think about it some more. Have you asked IAIK about their non-compliance? Thanks, Sean [1] http://download.java.net/java/jdk9/docs/specs/security/standard-names.html#signature-algorithms Thanks & Best regards Christoph [1] http://jcewww.iaik.tu-graz.ac.at/sic/Products/Core_Crypto_Toolkits/JCA_JCE -Original Message- From: Langer, Christoph Sent: Sonntag, 9. Juli 2017 07:57 To: 'Anthony Scarpino' ; 'Sean Mullan' Cc: OpenJDK Security ; 'Dieter Bratko' Subject: RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider Hi Tony et. al., I'm wondering why in the commit for 8174849 (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da) this line sneaked in: --- a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChe cker.java Wed Feb 15 12:11:03 2017 -0800 +++ b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmCh ecker.java Wed Feb 15 12:55:20 2017 -0800 @@ -276,7 +276,7 @@ AlgorithmParameters currSigAlgParams = algorithmId.getParameters(); PublicKey currPubKey = cert.getPublicKey(); -String currSigAlg = x509Cert.getSigAlgName(); +String currSigAlg = ((X509Certificate)cert).getSigAlgName(); // Check the signature algorithm and parameters against constraints. if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg, The proposed webrev only contains the change to java.security and there is no other hint on that anywhere public. I'm asking because I'm seeing an issue with a 3rd party JCE provider at the moment. There is an "SHA1withRSA" certificate involved but the provider in use at my customer returns the String "SHA1/RSA" as SigAlgName. Don't know how much this conforms with the spec, but it is as it is. So the permits check will fail with that String. I believe, if the SigAlgName would be taken from the converted x509Cert as before, we'd get SHA1withRSA and would be fine, though I didn't test that yet. So, what speaks against that line being reverted? Thanks & Best regards Christoph -Original Message- From: security-dev [mailto:security-dev-boun...@openjdk.java.net] On Behalf Of Anthony Scarpino Sent: Montag, 13. Februar 2017 22:48 To: OpenJDK Security Subject: [RFR] 8174849: Change SHA1 certpath restrictions Hi, I need a quick review on a simple certpath config change. http://cr.openjdk.java.net/~ascarpino/8174849/webrev/ thanks Tony
RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd party JCE provider
Hi, I'd like to ping you again upon that question. In the meanwhile I have produced a standalone test case and could verify that changing to x509Cert vs. the original cert for obtaining the SigAlgName would be a fix. I can share the test with you, however, you'll need the security provider 'IAIK' which is not OpenSource but can be obtained for free for educational/research purposes here [1]. Shall I open a Bug for that and propose a fix? Or is using the x509Cert at this place the wrong thing to do here for reasons? I'd appreciate some feedback. Thanks & Best regards Christoph [1] http://jcewww.iaik.tu-graz.ac.at/sic/Products/Core_Crypto_Toolkits/JCA_JCE > -Original Message- > From: Langer, Christoph > Sent: Sonntag, 9. Juli 2017 07:57 > To: 'Anthony Scarpino' ; 'Sean Mullan' > > Cc: OpenJDK Security ; 'Dieter Bratko' > > Subject: RE: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd > party JCE provider > > Hi Tony et. al., > > I'm wondering why in the commit for 8174849 > (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d911fe42d2da) this line > sneaked in: > > --- > a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChe > cker.java Wed Feb 15 12:11:03 2017 -0800 > +++ > b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmCh > ecker.javaWed Feb 15 12:55:20 2017 -0800 > @@ -276,7 +276,7 @@ > AlgorithmParameters currSigAlgParams = algorithmId.getParameters(); > PublicKey currPubKey = cert.getPublicKey(); > -String currSigAlg = x509Cert.getSigAlgName(); > +String currSigAlg = ((X509Certificate)cert).getSigAlgName(); > > // Check the signature algorithm and parameters against constraints. > if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg, > > The proposed webrev only contains the change to java.security and there is > no other hint on that anywhere public. > > I'm asking because I'm seeing an issue with a 3rd party JCE provider at the > moment. There is an "SHA1withRSA" certificate involved but the provider in > use at my customer returns the String "SHA1/RSA" as SigAlgName. Don't > know how much this conforms with the spec, but it is as it is. So the permits > check will fail with that String. I believe, if the SigAlgName would be taken > from the converted x509Cert as before, we'd get SHA1withRSA and would be > fine, though I didn't test that yet. So, what speaks against that line being > reverted? > > Thanks & Best regards > Christoph > > > -Original Message- > > From: security-dev [mailto:security-dev-boun...@openjdk.java.net] On > > Behalf Of Anthony Scarpino > > Sent: Montag, 13. Februar 2017 22:48 > > To: OpenJDK Security > > Subject: [RFR] 8174849: Change SHA1 certpath restrictions > > > > Hi, > > > > I need a quick review on a simple certpath config change. > > > > http://cr.openjdk.java.net/~ascarpino/8174849/webrev/ > > > > thanks > > > > Tony
