From amy.lu at oracle.com  Tue Jul  4 07:54:06 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 4 Jul 2017 15:54:06 +0800
Subject: JDK 10 RFR of JDK-8183531: Wrong @modules in
 test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java
Message-ID: <40338400-2014-a307-7877-15410db5df41@oracle.com>

Please review the patch to fix the typo in @modules for test
javax/net/ssl/ciphersuites/ECCurvesconstraints.java

bug: https://bugs.openjdk.java.net/browse/JDK-8183531
webrev: http://cr.openjdk.java.net/~amlu/8183531/webrev.00/

Thanks,
Amy

--- old/test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java	2017-07-04 15:47:20.000000000 +0800
+++ new/test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java	2017-07-04 15:47:20.000000000 +0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -32,7 +32,7 @@
   * @test
   * @bug 8148516
   * @summary Improve the default strength of EC in JDK
- * @modules jdk.crypyo.ec
+ * @modules jdk.crypto.ec
   * @run main/othervm ECCurvesconstraints PKIX
   * @run main/othervm ECCurvesconstraints SunX509
   */

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170704/80e5967b/attachment.htm>

From michael.rasmussen at zeroturnaround.com  Tue Jul  4 11:57:01 2017
From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen)
Date: Tue, 4 Jul 2017 14:57:01 +0300
Subject: AccessController.doPrivileged and default methods
Message-ID: <CAPMkJWakwgvNevB=jfA9PLhB1_F_+oyawM-6fYSr57pHzzBmLQ@mail.gmail.com>

Hi

I was playing around with having an easy way to have doPrivileged call
void methods via lambdas/method references, and noticed that if you
use AccessController.doPrivileged(PrivilegedAction), and the run
method is implemented as a default method, then you get the following
exception: java.lang.InternalError: No run method

I failed finding anywhere in the documentation stating this should not
be supported, or a bug report about it, so writing/asking here.

See example code below

Kind regards
Michael Rasmussen


//----

package com.test;

import java.security.AccessController;
import java.security.PrivilegedAction;

public class Test {
  interface VoidPrivilegedAction extends PrivilegedAction<Void> {
    void perform();

    @Override
    default Void run() {
      perform();
      return null;
    }
  }

  static void doPrivileged(VoidPrivilegedAction act) {
    AccessController.doPrivileged(act);
  }

  public static void main(String[] args) throws Exception {
    doPrivileged(() -> System.out.println(System.getProperty("java.home")));
  }
}

//----

Exception in thread "main" java.lang.InternalError: No run method
at java.security.AccessController.doPrivileged(Native Method)
at com.test.Test.doPrivileged(Test.java:18)
at com.test.Test.main(Test.java:22)


From xuelei.fan at oracle.com  Tue Jul  4 14:13:55 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 4 Jul 2017 07:13:55 -0700
Subject: JDK 10 RFR of JDK-8183531: Wrong @modules in
 test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java
In-Reply-To: <40338400-2014-a307-7877-15410db5df41@oracle.com>
References: <40338400-2014-a307-7877-15410db5df41@oracle.com>
Message-ID: <ce880a08-a617-3c8e-5a99-175ea745e36a@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 7/4/2017 12:54 AM, Amy Lu wrote:
> Please review the patch to fix the typo in @modules for test
> javax/net/ssl/ciphersuites/ECCurvesconstraints.java
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8183531
> webrev: http://cr.openjdk.java.net/~amlu/8183531/webrev.00/
> 
> Thanks,
> Amy
> 
> --- old/test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java	2017-07-04 15:47:20.000000000 +0800
> +++ new/test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java	2017-07-04 15:47:20.000000000 +0800
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
> @@ -32,7 +32,7 @@
>    * @test
>    * @bug 8148516
>    * @summary Improve the default strength of EC in JDK
> - * @modules jdk.crypyo.ec
> + * @modules jdk.crypto.ec
>    * @run main/othervm ECCurvesconstraints PKIX
>    * @run main/othervm ECCurvesconstraints SunX509
>    */
> 


From bradford.wetmore at oracle.com  Tue Jul  4 14:58:15 2017
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Tue, 4 Jul 2017 07:58:15 -0700
Subject: JDK 10 RFR of JDK-8183531: Wrong @modules in
 test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java
In-Reply-To: <ce880a08-a617-3c8e-5a99-175ea745e36a@oracle.com>
References: <40338400-2014-a307-7877-15410db5df41@oracle.com>
 <ce880a08-a617-3c8e-5a99-175ea745e36a@oracle.com>
Message-ID: <bc5ca914-e20c-abe1-729c-0410480ee9e2@oracle.com>

+1.

Brad


On 7/4/2017 7:13 AM, Xuelei Fan wrote:
> Looks fine to me.
> 
> Thanks,
> Xuelei
> 
> On 7/4/2017 12:54 AM, Amy Lu wrote:
>> Please review the patch to fix the typo in @modules for test
>> javax/net/ssl/ciphersuites/ECCurvesconstraints.java
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8183531
>> webrev: http://cr.openjdk.java.net/~amlu/8183531/webrev.00/
>>
>> Thanks,
>> Amy
>>
>> --- old/test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java    
>> 2017-07-04 15:47:20.000000000 +0800
>> +++ new/test/javax/net/ssl/ciphersuites/ECCurvesconstraints.java    
>> 2017-07-04 15:47:20.000000000 +0800
>> @@ -1,5 +1,5 @@
>>   /*
>> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights 
>> reserved.
>> + * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights 
>> reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or modify it
>> @@ -32,7 +32,7 @@
>>    * @test
>>    * @bug 8148516
>>    * @summary Improve the default strength of EC in JDK
>> - * @modules jdk.crypyo.ec
>> + * @modules jdk.crypto.ec
>>    * @run main/othervm ECCurvesconstraints PKIX
>>    * @run main/othervm ECCurvesconstraints SunX509
>>    */
>>


From adam.petcher at oracle.com  Wed Jul  5 20:01:48 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 5 Jul 2017 16:01:48 -0400
Subject: AccessController.doPrivileged and default methods
In-Reply-To: <CAPMkJWakwgvNevB=jfA9PLhB1_F_+oyawM-6fYSr57pHzzBmLQ@mail.gmail.com>
References: <CAPMkJWakwgvNevB=jfA9PLhB1_F_+oyawM-6fYSr57pHzzBmLQ@mail.gmail.com>
Message-ID: <09f06df1-8547-04a7-36b6-361f9bea1cfd@oracle.com>


Very interesting. The exception originates in the VM, so I added the 
hotspot-dev list to the discussion. It looks like the VM either can't 
find the method, or it decides that it's not the right kind of method.

On 7/4/2017 7:57 AM, Michael Rasmussen wrote:
> Hi
>
> I was playing around with having an easy way to have doPrivileged call
> void methods via lambdas/method references, and noticed that if you
> use AccessController.doPrivileged(PrivilegedAction), and the run
> method is implemented as a default method, then you get the following
> exception: java.lang.InternalError: No run method
>
> I failed finding anywhere in the documentation stating this should not
> be supported, or a bug report about it, so writing/asking here.
>
> See example code below
>
> Kind regards
> Michael Rasmussen
>
>
> //----
>
> package com.test;
>
> import java.security.AccessController;
> import java.security.PrivilegedAction;
>
> public class Test {
>    interface VoidPrivilegedAction extends PrivilegedAction<Void> {
>      void perform();
>
>      @Override
>      default Void run() {
>        perform();
>        return null;
>      }
>    }
>
>    static void doPrivileged(VoidPrivilegedAction act) {
>      AccessController.doPrivileged(act);
>    }
>
>    public static void main(String[] args) throws Exception {
>      doPrivileged(() -> System.out.println(System.getProperty("java.home")));
>    }
> }
>
> //----
>
> Exception in thread "main" java.lang.InternalError: No run method
> at java.security.AccessController.doPrivileged(Native Method)
> at com.test.Test.doPrivileged(Test.java:18)
> at com.test.Test.main(Test.java:22)



From sean.mullan at oracle.com  Thu Jul  6 14:33:09 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 6 Jul 2017 10:33:09 -0400
Subject: AccessController.doPrivileged and default methods
In-Reply-To: <09f06df1-8547-04a7-36b6-361f9bea1cfd@oracle.com>
References: <CAPMkJWakwgvNevB=jfA9PLhB1_F_+oyawM-6fYSr57pHzzBmLQ@mail.gmail.com>
 <09f06df1-8547-04a7-36b6-361f9bea1cfd@oracle.com>
Message-ID: <b9a58c56-1954-e8e9-dea8-c91299174e30@oracle.com>

On 7/5/17 4:01 PM, Adam Petcher wrote:
> 
> Very interesting. The exception originates in the VM, so I added the 
> hotspot-dev list to the discussion. It looks like the VM either can't 
> find the method, or it decides that it's not the right kind of method.

Right. The check that is causing this error is in jvm.cpp [1]:

1271  if (m.is_null() || !m->is_method() || !m()->is_public() || 
m()->is_static()) {
1272    THROW_MSG_0(vmSymbols::java_lang_InternalError(), "No run method");
1273  }

I'll file a bug unless someone has a good explanation for this behavior.

Thanks,
Sean

[1] 
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/1ca8f038fceb/src/share/vm/prims/jvm.cpp#l1271


> On 7/4/2017 7:57 AM, Michael Rasmussen wrote:
>> Hi
>>
>> I was playing around with having an easy way to have doPrivileged call
>> void methods via lambdas/method references, and noticed that if you
>> use AccessController.doPrivileged(PrivilegedAction), and the run
>> method is implemented as a default method, then you get the following
>> exception: java.lang.InternalError: No run method
>>
>> I failed finding anywhere in the documentation stating this should not
>> be supported, or a bug report about it, so writing/asking here.
>>
>> See example code below
>>
>> Kind regards
>> Michael Rasmussen
>>
>>
>> //----
>>
>> package com.test;
>>
>> import java.security.AccessController;
>> import java.security.PrivilegedAction;
>>
>> public class Test {
>>    interface VoidPrivilegedAction extends PrivilegedAction<Void> {
>>      void perform();
>>
>>      @Override
>>      default Void run() {
>>        perform();
>>        return null;
>>      }
>>    }
>>
>>    static void doPrivileged(VoidPrivilegedAction act) {
>>      AccessController.doPrivileged(act);
>>    }
>>
>>    public static void main(String[] args) throws Exception {
>>      doPrivileged(() -> 
>> System.out.println(System.getProperty("java.home")));
>>    }
>> }
>>
>> //----
>>
>> Exception in thread "main" java.lang.InternalError: No run method
>> at java.security.AccessController.doPrivileged(Native Method)
>> at com.test.Test.doPrivileged(Test.java:18)
>> at com.test.Test.main(Test.java:22)
> 


From huaming.li at oracle.com  Fri Jul  7 03:25:42 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 7 Jul 2017 11:25:42 +0800
Subject: 10 RFR of JDK-8183990: compilation error for
 test/com/sun/crypto/provider/Cipher/DES/PerformanceTest.java
Message-ID: <6d4c8bdc-91f6-7e9d-a7ef-f4219572d3eb@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8183990

webrev: http://cr.openjdk.java.net/~mli/8183990/webrev.00/


Thank you

-Hamlin



From weijun.wang at oracle.com  Fri Jul  7 05:15:25 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 7 Jul 2017 13:15:25 +0800
Subject: 10 RFR of JDK-8183990: compilation error for
 test/com/sun/crypto/provider/Cipher/DES/PerformanceTest.java
In-Reply-To: <6d4c8bdc-91f6-7e9d-a7ef-f4219572d3eb@oracle.com>
References: <6d4c8bdc-91f6-7e9d-a7ef-f4219572d3eb@oracle.com>
Message-ID: <75E1ED60-999C-4B01-949D-5972E1BB045B@oracle.com>

If the compiler is just complaining about characters in a comment, why not simply remove the comment? Do you think the current test is wrong and the 2nd half of the string must be added back?

Also, the string is still too long. I?d rather break it into multiple lines to fit a normal screen width.

Thanks
Max


> On Jul 7, 2017, at 11:25 AM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> Would you please review the below patch?
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8183990
> 
> webrev: http://cr.openjdk.java.net/~mli/8183990/webrev.00/
> 
> 
> Thank you
> 
> -Hamlin
> 



From huaming.li at oracle.com  Fri Jul  7 05:30:00 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 7 Jul 2017 13:30:00 +0800
Subject: 10 RFR of JDK-8183990: compilation error for
 test/com/sun/crypto/provider/Cipher/DES/PerformanceTest.java
In-Reply-To: <75E1ED60-999C-4B01-949D-5972E1BB045B@oracle.com>
References: <6d4c8bdc-91f6-7e9d-a7ef-f4219572d3eb@oracle.com>
 <75E1ED60-999C-4B01-949D-5972E1BB045B@oracle.com>
Message-ID: <018f78d6-0fa5-b6b2-d04c-14032134e841@oracle.com>

Hi Max,

As you suggested, remove comments and wrap long lines, updated webrev in 
place: http://cr.openjdk.java.net/~mli/8183990/webrev.00/

Thank you

-Hamlin


On 2017/7/7 13:15, Weijun Wang wrote:
> If the compiler is just complaining about characters in a comment, why not simply remove the comment? Do you think the current test is wrong and the 2nd half of the string must be added back?
>
> Also, the string is still too long. I?d rather break it into multiple lines to fit a normal screen width.
>
> Thanks
> Max
>
>
>> On Jul 7, 2017, at 11:25 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8183990
>>
>> webrev: http://cr.openjdk.java.net/~mli/8183990/webrev.00/
>>
>>
>> Thank you
>>
>> -Hamlin
>>



From weijun.wang at oracle.com  Fri Jul  7 05:33:53 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 7 Jul 2017 13:33:53 +0800
Subject: 10 RFR of JDK-8183990: compilation error for
 test/com/sun/crypto/provider/Cipher/DES/PerformanceTest.java
In-Reply-To: <018f78d6-0fa5-b6b2-d04c-14032134e841@oracle.com>
References: <6d4c8bdc-91f6-7e9d-a7ef-f4219572d3eb@oracle.com>
 <75E1ED60-999C-4B01-949D-5972E1BB045B@oracle.com>
 <018f78d6-0fa5-b6b2-d04c-14032134e841@oracle.com>
Message-ID: <5A2E443E-82E2-412E-8131-20D01F38C470@oracle.com>

This looks fine.

Thanks
Max

> On Jul 7, 2017, at 1:30 PM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> Hi Max,
> 
> As you suggested, remove comments and wrap long lines, updated webrev in place: http://cr.openjdk.java.net/~mli/8183990/webrev.00/
> 
> Thank you
> 
> -Hamlin
> 
> 
> On 2017/7/7 13:15, Weijun Wang wrote:
>> If the compiler is just complaining about characters in a comment, why not simply remove the comment? Do you think the current test is wrong and the 2nd half of the string must be added back?
>> 
>> Also, the string is still too long. I?d rather break it into multiple lines to fit a normal screen width.
>> 
>> Thanks
>> Max
>> 
>> 
>>> On Jul 7, 2017, at 11:25 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>> 
>>> Would you please review the below patch?
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8183990
>>> 
>>> webrev: http://cr.openjdk.java.net/~mli/8183990/webrev.00/
>>> 
>>> 
>>> Thank you
>>> 
>>> -Hamlin
>>> 
> 



From weijun.wang at oracle.com  Fri Jul  7 07:58:44 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 7 Jul 2017 15:58:44 +0800
Subject: [10] RFR 8183509: keytool should not allow multiple commands
References: <FE5A7077-2005-4332-A139-58991490365F@oracle.com>
Message-ID: <11FC9EDE-BEF0-454A-98A9-DC1221044E4A@oracle.com>

Please take a look at

 http://cr.openjdk.java.net/~weijun/8183509/webrev.00/ <http://cr.openjdk.java.net/~weijun/8183509/webrev.00/>

Multiple commands on the same keytool command line is now an error. Specifying a single-valued option multiple times will trigger a warning.

Thanks
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170707/ccd51d7a/attachment.htm>

From sean.mullan at oracle.com  Fri Jul  7 12:00:36 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 7 Jul 2017 08:00:36 -0400
Subject: [10] RFR 8183509: keytool should not allow multiple commands
In-Reply-To: <11FC9EDE-BEF0-454A-98A9-DC1221044E4A@oracle.com>
References: <FE5A7077-2005-4332-A139-58991490365F@oracle.com>
 <11FC9EDE-BEF0-454A-98A9-DC1221044E4A@oracle.com>
Message-ID: <3804b793-d727-586e-e785-b01d715f468a@oracle.com>

I would use "specified" instead of "provided" since that word is used 
more commonly in the keytool warnings.

Thanks,
Sean

On 7/7/17 3:58 AM, Weijun Wang wrote:
> Please take a look at
> 
> http://cr.openjdk.java.net/~weijun/8183509/webrev.00/
> 
> Multiple commands on the same keytool command line is now an error. 
> Specifying a single-valued option multiple times will trigger a warning.
> 
> Thanks
> Max


From weijun.wang at oracle.com  Fri Jul  7 14:55:04 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 7 Jul 2017 22:55:04 +0800
Subject: [10] RFR 8183509: keytool should not allow multiple commands
In-Reply-To: <3804b793-d727-586e-e785-b01d715f468a@oracle.com>
References: <FE5A7077-2005-4332-A139-58991490365F@oracle.com>
 <11FC9EDE-BEF0-454A-98A9-DC1221044E4A@oracle.com>
 <3804b793-d727-586e-e785-b01d715f468a@oracle.com>
Message-ID: <2B36E037-5520-4854-8DFB-BEE027EACBE3@oracle.com>

Updated at

   http://cr.openjdk.java.net/~weijun/8183509/webrev.01/

Changes:

   http://cr.openjdk.java.net/~weijun/8183509/webrev.01/interdiff.patch.html

Thanks
Max

> On Jul 7, 2017, at 8:00 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> I would use "specified" instead of "provided" since that word is used more commonly in the keytool warnings.
> 
> Thanks,
> Sean
> 
> On 7/7/17 3:58 AM, Weijun Wang wrote:
>> Please take a look at
>> http://cr.openjdk.java.net/~weijun/8183509/webrev.00/
>> Multiple commands on the same keytool command line is now an error. Specifying a single-valued option multiple times will trigger a warning.
>> Thanks
>> Max



From vincent.x.ryan at oracle.com  Fri Jul  7 17:05:35 2017
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 7 Jul 2017 18:05:35 +0100
Subject: [10] RFR 8183509: keytool should not allow multiple commands
In-Reply-To: <2B36E037-5520-4854-8DFB-BEE027EACBE3@oracle.com>
References: <FE5A7077-2005-4332-A139-58991490365F@oracle.com>
 <11FC9EDE-BEF0-454A-98A9-DC1221044E4A@oracle.com>
 <3804b793-d727-586e-e785-b01d715f468a@oracle.com>
 <2B36E037-5520-4854-8DFB-BEE027EACBE3@oracle.com>
Message-ID: <E6093C64-D456-4409-BC06-D6D6B24D99D5@oracle.com>

Looks fine to me.

> On 7 Jul 2017, at 15:55, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Updated at
> 
>   http://cr.openjdk.java.net/~weijun/8183509/webrev.01/
> 
> Changes:
> 
>   http://cr.openjdk.java.net/~weijun/8183509/webrev.01/interdiff.patch.html
> 
> Thanks
> Max
> 
>> On Jul 7, 2017, at 8:00 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>> 
>> I would use "specified" instead of "provided" since that word is used more commonly in the keytool warnings.
>> 
>> Thanks,
>> Sean
>> 
>> On 7/7/17 3:58 AM, Weijun Wang wrote:
>>> Please take a look at
>>> http://cr.openjdk.java.net/~weijun/8183509/webrev.00/
>>> Multiple commands on the same keytool command line is now an error. Specifying a single-valued option multiple times will trigger a warning.
>>> Thanks
>>> Max
> 



From adam.petcher at oracle.com  Fri Jul  7 18:59:46 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Fri, 7 Jul 2017 14:59:46 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
Message-ID: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>

This is a bug fix related to invalid curves in the SunEC provider. 
During ECKeyPairGenerator.initialize(), the provider only checks whether 
the curve is known, but it doesn't check whether the curve is actually 
supported by the native code. So the call to generateKeyPair() can fail 
in the native code and throw a ProviderException. This change adds a new 
native method to check whether the curve is supported. This method is 
called by initialize(), which will set the state to uninitialized and 
throw the expected exception when the curve is not supported.

JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/



From sean.coffey at oracle.com  Fri Jul  7 20:12:53 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 7 Jul 2017 21:12:53 +0100
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
Message-ID: <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>

Adam,

would it be useful to get the curve name in the new exception ? I think 
it would help with future debugging. Line 96 already gets the curve name 
if we're dealing with ECGenParameterSpec instance. I think the same 
approach could be applied to your new code.

Regards,
Sean.


On 07/07/2017 19:59, Adam Petcher wrote:
> This is a bug fix related to invalid curves in the SunEC provider. 
> During ECKeyPairGenerator.initialize(), the provider only checks 
> whether the curve is known, but it doesn't check whether the curve is 
> actually supported by the native code. So the call to 
> generateKeyPair() can fail in the native code and throw a 
> ProviderException. This change adds a new native method to check 
> whether the curve is supported. This method is called by initialize(), 
> which will set the state to uninitialized and throw the expected 
> exception when the curve is not supported.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>



From sean.mullan at oracle.com  Fri Jul  7 20:21:05 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 7 Jul 2017 16:21:05 -0400
Subject: AccessController.doPrivileged and default methods
In-Reply-To: <b9a58c56-1954-e8e9-dea8-c91299174e30@oracle.com>
References: <CAPMkJWakwgvNevB=jfA9PLhB1_F_+oyawM-6fYSr57pHzzBmLQ@mail.gmail.com>
 <09f06df1-8547-04a7-36b6-361f9bea1cfd@oracle.com>
 <b9a58c56-1954-e8e9-dea8-c91299174e30@oracle.com>
Message-ID: <eb1f77be-00ef-ee19-d5a7-e0a25b485d8e@oracle.com>

On 7/6/17 10:33 AM, Sean Mullan wrote:
> On 7/5/17 4:01 PM, Adam Petcher wrote:
>>
>> Very interesting. The exception originates in the VM, so I added the 
>> hotspot-dev list to the discussion. It looks like the VM either can't 
>> find the method, or it decides that it's not the right kind of method.
> 
> Right. The check that is causing this error is in jvm.cpp [1]:
> 
> 1271  if (m.is_null() || !m->is_method() || !m()->is_public() || 
> m()->is_static()) {
> 1272    THROW_MSG_0(vmSymbols::java_lang_InternalError(), "No run method");
> 1273  }
> 
> I'll file a bug unless someone has a good explanation for this behavior.

Bug now filed: https://bugs.openjdk.java.net/browse/JDK-8183962

--Sean

> 
> Thanks,
> Sean
> 
> [1] 
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/1ca8f038fceb/src/share/vm/prims/jvm.cpp#l1271 
> 
> 
> 
>> On 7/4/2017 7:57 AM, Michael Rasmussen wrote:
>>> Hi
>>>
>>> I was playing around with having an easy way to have doPrivileged call
>>> void methods via lambdas/method references, and noticed that if you
>>> use AccessController.doPrivileged(PrivilegedAction), and the run
>>> method is implemented as a default method, then you get the following
>>> exception: java.lang.InternalError: No run method
>>>
>>> I failed finding anywhere in the documentation stating this should not
>>> be supported, or a bug report about it, so writing/asking here.
>>>
>>> See example code below
>>>
>>> Kind regards
>>> Michael Rasmussen
>>>
>>>
>>> //----
>>>
>>> package com.test;
>>>
>>> import java.security.AccessController;
>>> import java.security.PrivilegedAction;
>>>
>>> public class Test {
>>>    interface VoidPrivilegedAction extends PrivilegedAction<Void> {
>>>      void perform();
>>>
>>>      @Override
>>>      default Void run() {
>>>        perform();
>>>        return null;
>>>      }
>>>    }
>>>
>>>    static void doPrivileged(VoidPrivilegedAction act) {
>>>      AccessController.doPrivileged(act);
>>>    }
>>>
>>>    public static void main(String[] args) throws Exception {
>>>      doPrivileged(() -> 
>>> System.out.println(System.getProperty("java.home")));
>>>    }
>>> }
>>>
>>> //----
>>>
>>> Exception in thread "main" java.lang.InternalError: No run method
>>> at java.security.AccessController.doPrivileged(Native Method)
>>> at com.test.Test.doPrivileged(Test.java:18)
>>> at com.test.Test.main(Test.java:22)
>>


From sean.mullan at oracle.com  Fri Jul  7 20:24:30 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 7 Jul 2017 16:24:30 -0400
Subject: [10] RFR 8183509: keytool should not allow multiple commands
In-Reply-To: <2B36E037-5520-4854-8DFB-BEE027EACBE3@oracle.com>
References: <FE5A7077-2005-4332-A139-58991490365F@oracle.com>
 <11FC9EDE-BEF0-454A-98A9-DC1221044E4A@oracle.com>
 <3804b793-d727-586e-e785-b01d715f468a@oracle.com>
 <2B36E037-5520-4854-8DFB-BEE027EACBE3@oracle.com>
Message-ID: <225bfd5f-3b2e-af64-245b-23e969c449b9@oracle.com>

Looks good.

--Sean

On 7/7/17 10:55 AM, Weijun Wang wrote:
> Updated at
> 
>     http://cr.openjdk.java.net/~weijun/8183509/webrev.01/
> 
> Changes:
> 
>     http://cr.openjdk.java.net/~weijun/8183509/webrev.01/interdiff.patch.html
> 
> Thanks
> Max
> 
>> On Jul 7, 2017, at 8:00 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> I would use "specified" instead of "provided" since that word is used more commonly in the keytool warnings.
>>
>> Thanks,
>> Sean
>>
>> On 7/7/17 3:58 AM, Weijun Wang wrote:
>>> Please take a look at
>>> http://cr.openjdk.java.net/~weijun/8183509/webrev.00/
>>> Multiple commands on the same keytool command line is now an error. Specifying a single-valued option multiple times will trigger a warning.
>>> Thanks
>>> Max
> 


From christoph.langer at sap.com  Sun Jul  9 05:57:20 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 9 Jul 2017 05:57:20 +0000
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
Message-ID: <fa029b456fe842d29f13240091119208@sap.com>

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/AlgorithmChecker.java	Wed Feb 15 12:11:03 2017 -0800
+++ b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.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-bounces at openjdk.java.net] On
> Behalf Of Anthony Scarpino
> Sent: Montag, 13. Februar 2017 22:48
> To: OpenJDK Security <security-dev at openjdk.java.net>
> 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

From adam.petcher at oracle.com  Mon Jul 10 15:13:27 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Mon, 10 Jul 2017 11:13:27 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
Message-ID: <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>

New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/

Yes, this is a good idea. I made this work by printing out the value 
from AlgorithmParameters.toString(), so hopefully that means you should 
always get a useful string. At the moment (with SunEC 
AlgorithmParameters), the string prints the friendly name followed by 
the OID:

Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)

On 7/7/2017 4:12 PM, Se?n Coffey wrote:
> Adam,
>
> would it be useful to get the curve name in the new exception ? I 
> think it would help with future debugging. Line 96 already gets the 
> curve name if we're dealing with ECGenParameterSpec instance. I think 
> the same approach could be applied to your new code.
>
> Regards,
> Sean.
>
>
> On 07/07/2017 19:59, Adam Petcher wrote:
>> This is a bug fix related to invalid curves in the SunEC provider. 
>> During ECKeyPairGenerator.initialize(), the provider only checks 
>> whether the curve is known, but it doesn't check whether the curve is 
>> actually supported by the native code. So the call to 
>> generateKeyPair() can fail in the native code and throw a 
>> ProviderException. This change adds a new native method to check 
>> whether the curve is supported. This method is called by 
>> initialize(), which will set the state to uninitialized and throw the 
>> expected exception when the curve is not supported.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>
>



From sean.coffey at oracle.com  Mon Jul 10 16:03:07 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 10 Jul 2017 17:03:07 +0100
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
Message-ID: <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>

Thanks for the update! Looks fine to me.

Regards,
Sean.

On 10/07/17 16:13, Adam Petcher wrote:
> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>
> Yes, this is a good idea. I made this work by printing out the value 
> from AlgorithmParameters.toString(), so hopefully that means you 
> should always get a useful string. At the moment (with SunEC 
> AlgorithmParameters), the string prints the friendly name followed by 
> the OID:
>
> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>
> On 7/7/2017 4:12 PM, Se?n Coffey wrote:
>> Adam,
>>
>> would it be useful to get the curve name in the new exception ? I 
>> think it would help with future debugging. Line 96 already gets the 
>> curve name if we're dealing with ECGenParameterSpec instance. I think 
>> the same approach could be applied to your new code.
>>
>> Regards,
>> Sean.
>>
>>
>> On 07/07/2017 19:59, Adam Petcher wrote:
>>> This is a bug fix related to invalid curves in the SunEC provider. 
>>> During ECKeyPairGenerator.initialize(), the provider only checks 
>>> whether the curve is known, but it doesn't check whether the curve 
>>> is actually supported by the native code. So the call to 
>>> generateKeyPair() can fail in the native code and throw a 
>>> ProviderException. This change adds a new native method to check 
>>> whether the curve is supported. This method is called by 
>>> initialize(), which will set the state to uninitialized and throw 
>>> the expected exception when the curve is not supported.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>
>>
>



From mstjohns at comcast.net  Mon Jul 10 16:17:30 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 10 Jul 2017 12:17:30 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
Message-ID: <0dee29fd-c1f6-8f0a-959c-574385a86239@comcast.net>

Actually - wouldn't it make a lot more sense to generalize the provider 
so it can take ANY set of curve data?  Locking this to only what has an 
OID to parameters mapping doesn't seem to be actually meeting the 
contract for an EC key generator.

I understand a number of tools (e.g. PKIX related/keytool) can't be used 
without the OID, but this isn't at that level.

The webrev feels more like a bandaid than a solution.

Mike


On 7/10/2017 12:03 PM, Se?n Coffey wrote:
> Thanks for the update! Looks fine to me.
>
> Regards,
> Sean.
>
> On 10/07/17 16:13, Adam Petcher wrote:
>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>>
>> Yes, this is a good idea. I made this work by printing out the value 
>> from AlgorithmParameters.toString(), so hopefully that means you 
>> should always get a useful string. At the moment (with SunEC 
>> AlgorithmParameters), the string prints the friendly name followed by 
>> the OID:
>>
>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>>
>> On 7/7/2017 4:12 PM, Se?n Coffey wrote:
>>> Adam,
>>>
>>> would it be useful to get the curve name in the new exception ? I 
>>> think it would help with future debugging. Line 96 already gets the 
>>> curve name if we're dealing with ECGenParameterSpec instance. I 
>>> think the same approach could be applied to your new code.
>>>
>>> Regards,
>>> Sean.
>>>
>>>
>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>> This is a bug fix related to invalid curves in the SunEC provider. 
>>>> During ECKeyPairGenerator.initialize(), the provider only checks 
>>>> whether the curve is known, but it doesn't check whether the curve 
>>>> is actually supported by the native code. So the call to 
>>>> generateKeyPair() can fail in the native code and throw a 
>>>> ProviderException. This change adds a new native method to check 
>>>> whether the curve is supported. This method is called by 
>>>> initialize(), which will set the state to uninitialized and throw 
>>>> the expected exception when the curve is not supported.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>>
>>>
>>
>



From adam.petcher at oracle.com  Mon Jul 10 16:59:09 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Mon, 10 Jul 2017 12:59:09 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <0dee29fd-c1f6-8f0a-959c-574385a86239@comcast.net>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
 <0dee29fd-c1f6-8f0a-959c-574385a86239@comcast.net>
Message-ID: <776984c9-6a04-841c-be14-35c684768d27@oracle.com>

This fix addresses an issue in which the provider behaves incorrectly 
when initialized with parameters for a curve that is not supported by 
the provider. If I am interpreting your suggestion correctly, it sounds 
like you are requesting a change to the set of curves that is supported 
by the provider. While this change may be a good idea, it is not within 
the scope of this ticket.

If you want SunEC to support arbitrary curve parameters, you will need 
to create a separate ticket for that. I suspect this change would 
require a fair amount of work (if it is even possible), and it may not 
be worth the effort.


On 7/10/2017 12:17 PM, Michael StJohns wrote:
> Actually - wouldn't it make a lot more sense to generalize the 
> provider so it can take ANY set of curve data? Locking this to only 
> what has an OID to parameters mapping doesn't seem to be actually 
> meeting the contract for an EC key generator.
>
> I understand a number of tools (e.g. PKIX related/keytool) can't be 
> used without the OID, but this isn't at that level.
>
> The webrev feels more like a bandaid than a solution.
>
> Mike
>
>
> On 7/10/2017 12:03 PM, Se?n Coffey wrote:
>> Thanks for the update! Looks fine to me.
>>
>> Regards,
>> Sean.
>>
>> On 10/07/17 16:13, Adam Petcher wrote:
>>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>>>
>>> Yes, this is a good idea. I made this work by printing out the value 
>>> from AlgorithmParameters.toString(), so hopefully that means you 
>>> should always get a useful string. At the moment (with SunEC 
>>> AlgorithmParameters), the string prints the friendly name followed 
>>> by the OID:
>>>
>>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>>>
>>> On 7/7/2017 4:12 PM, Se?n Coffey wrote:
>>>> Adam,
>>>>
>>>> would it be useful to get the curve name in the new exception ? I 
>>>> think it would help with future debugging. Line 96 already gets the 
>>>> curve name if we're dealing with ECGenParameterSpec instance. I 
>>>> think the same approach could be applied to your new code.
>>>>
>>>> Regards,
>>>> Sean.
>>>>
>>>>
>>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>>> This is a bug fix related to invalid curves in the SunEC provider. 
>>>>> During ECKeyPairGenerator.initialize(), the provider only checks 
>>>>> whether the curve is known, but it doesn't check whether the curve 
>>>>> is actually supported by the native code. So the call to 
>>>>> generateKeyPair() can fail in the native code and throw a 
>>>>> ProviderException. This change adds a new native method to check 
>>>>> whether the curve is supported. This method is called by 
>>>>> initialize(), which will set the state to uninitialized and throw 
>>>>> the expected exception when the curve is not supported.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>>>
>>>>
>>>
>>
>



From mstjohns at comcast.net  Mon Jul 10 17:55:53 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 10 Jul 2017 13:55:53 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <776984c9-6a04-841c-be14-35c684768d27@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
 <0dee29fd-c1f6-8f0a-959c-574385a86239@comcast.net>
 <776984c9-6a04-841c-be14-35c684768d27@oracle.com>
Message-ID: <3d5b4994-04a9-39e8-d2ef-69c3b4f3d722@comcast.net>

On 7/10/2017 12:59 PM, Adam Petcher wrote:
> This fix addresses an issue in which the provider behaves incorrectly 
> when initialized with parameters for a curve that is not supported by 
> the provider. If I am interpreting your suggestion correctly, it 
> sounds like you are requesting a change to the set of curves that is 
> supported by the provider. While this change may be a good idea, it is 
> not within the scope of this ticket.
>
> If you want SunEC to support arbitrary curve parameters, you will need 
> to create a separate ticket for that. I suspect this change would 
> require a fair amount of work (if it is even possible), and it may not 
> be worth the effort.

EC is designed around a general set of math.  The math depends on the 
actual curve data (e.g. an EllipticCurve, a basepoint ECPoint g and an 
order and cofactor  - all the components of ECParameterSpec).   
ECGenParameterSpec is a simple wrapper around a string that's meant to 
provide a easy way for a human to specify a preexisting set of curve 
data.  When you get down into the provider its the math and the bits in 
the ECParameterSpec that matter, not the string or oid in the 
ECGenParameterSpec.

In any event, if you already have the curve data, then the fix is to 
replace the groupings of "if (EC_DecodeParams(...) {}" with a routine to 
fill the ECParams structure from the encodedParams you're passing in. 
(at lines 118, 233,346, 429 in ECC_JNI.cpp).

That would look like a different version of EC_FillParams  (in 
impl/ecdecode.c) - which actually decoded the algorithm parameter data 
rather than just looking for an OID choice and filling in from there.

*sigh* It looks like ECParameters.java is also incomplete.

What I'm mostly trying to get at here is to decouple  or remove the list 
of curves in ecdecode.c in favor of the list in the java stuff 
(CurveDB.java) (or elsewhere).   The C code should mostly only have to 
deal with the math and not the housekeeping.

Mike






>
>
> On 7/10/2017 12:17 PM, Michael StJohns wrote:
>> Actually - wouldn't it make a lot more sense to generalize the 
>> provider so it can take ANY set of curve data? Locking this to only 
>> what has an OID to parameters mapping doesn't seem to be actually 
>> meeting the contract for an EC key generator.
>>
>> I understand a number of tools (e.g. PKIX related/keytool) can't be 
>> used without the OID, but this isn't at that level.
>>
>> The webrev feels more like a bandaid than a solution.
>>
>> Mike
>>
>>
>> On 7/10/2017 12:03 PM, Se?n Coffey wrote:
>>> Thanks for the update! Looks fine to me.
>>>
>>> Regards,
>>> Sean.
>>>
>>> On 10/07/17 16:13, Adam Petcher wrote:
>>>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>>>>
>>>> Yes, this is a good idea. I made this work by printing out the 
>>>> value from AlgorithmParameters.toString(), so hopefully that means 
>>>> you should always get a useful string. At the moment (with SunEC 
>>>> AlgorithmParameters), the string prints the friendly name followed 
>>>> by the OID:
>>>>
>>>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>>>>
>>>> On 7/7/2017 4:12 PM, Se?n Coffey wrote:
>>>>> Adam,
>>>>>
>>>>> would it be useful to get the curve name in the new exception ? I 
>>>>> think it would help with future debugging. Line 96 already gets 
>>>>> the curve name if we're dealing with ECGenParameterSpec instance. 
>>>>> I think the same approach could be applied to your new code.
>>>>>
>>>>> Regards,
>>>>> Sean.
>>>>>
>>>>>
>>>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>>>> This is a bug fix related to invalid curves in the SunEC 
>>>>>> provider. During ECKeyPairGenerator.initialize(), the provider 
>>>>>> only checks whether the curve is known, but it doesn't check 
>>>>>> whether the curve is actually supported by the native code. So 
>>>>>> the call to generateKeyPair() can fail in the native code and 
>>>>>> throw a ProviderException. This change adds a new native method 
>>>>>> to check whether the curve is supported. This method is called by 
>>>>>> initialize(), which will set the state to uninitialized and throw 
>>>>>> the expected exception when the curve is not supported.
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>>>>
>>>>>
>>>>
>>>
>>
>



From adam.petcher at oracle.com  Mon Jul 10 18:28:24 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Mon, 10 Jul 2017 14:28:24 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <3d5b4994-04a9-39e8-d2ef-69c3b4f3d722@comcast.net>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
 <0dee29fd-c1f6-8f0a-959c-574385a86239@comcast.net>
 <776984c9-6a04-841c-be14-35c684768d27@oracle.com>
 <3d5b4994-04a9-39e8-d2ef-69c3b4f3d722@comcast.net>
Message-ID: <bd604a60-d9b4-0bc4-ea62-eeefd18e0423@oracle.com>

On 7/10/2017 1:55 PM, Michael StJohns wrote:

>
> What I'm mostly trying to get at here is to decouple  or remove the 
> list of curves in ecdecode.c in favor of the list in the java stuff 
> (CurveDB.java) (or elsewhere).   The C code should mostly only have to 
> deal with the math and not the housekeeping.
>

I agree that this would be a nice improvement, but I still think it is 
outside of scope of this fix. What you propose is a significant 
reorganization of the ECC code, and I don't think we should do that as 
part of a bug fix. It should be considered as a standalone refactoring 
effort, or maybe done as part of the next enhancement that adds support 
for new curves.

> Mike
>
>



From mstjohns at comcast.net  Mon Jul 10 18:51:40 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 10 Jul 2017 14:51:40 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <bd604a60-d9b4-0bc4-ea62-eeefd18e0423@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
 <0dee29fd-c1f6-8f0a-959c-574385a86239@comcast.net>
 <776984c9-6a04-841c-be14-35c684768d27@oracle.com>
 <3d5b4994-04a9-39e8-d2ef-69c3b4f3d722@comcast.net>
 <bd604a60-d9b4-0bc4-ea62-eeefd18e0423@oracle.com>
Message-ID: <158a31fe-e4b9-2a09-49c7-7801cda9ac6f@comcast.net>

On 7/10/2017 2:28 PM, Adam Petcher wrote:
> On 7/10/2017 1:55 PM, Michael StJohns wrote:
>
>>
>> What I'm mostly trying to get at here is to decouple  or remove the 
>> list of curves in ecdecode.c in favor of the list in the java stuff 
>> (CurveDB.java) (or elsewhere).   The C code should mostly only have 
>> to deal with the math and not the housekeeping.
>>
>
> I agree that this would be a nice improvement, but I still think it is 
> outside of scope of this fix. What you propose is a significant 
> reorganization of the ECC code, and I don't think we should do that as 
> part of a bug fix. It should be considered as a standalone refactoring 
> effort, or maybe done as part of the next enhancement that adds 
> support for new curves.

I'm not actually thinking this is an improvement rather than fixing an 
incomplete or badly structured implementation, but I take your point.  I 
also don't think it's much of a reorganization - again - rather removing 
an interdependency that shouldn't be there rather than papering over it 
with an explanatory error.  (Hmm.. have you checked to make sure that 
the list of curves in ecdecode is a subset of the curves in CurveDB - if 
not you may still have another problem).

I'd submit changes myself, but I don't currently have a good build 
environment to test against.

WRT to new curves - the next effort will probably involve changes to the 
public API to deal with the Curve25519 et al implementations. I'm not 
sure any of the old curve stuff will get any attention at that point.

Thanks-  Mike


>
>> Mike
>>
>>
>



From adam.petcher at oracle.com  Mon Jul 10 20:01:24 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Mon, 10 Jul 2017 16:01:24 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <158a31fe-e4b9-2a09-49c7-7801cda9ac6f@comcast.net>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
 <0dee29fd-c1f6-8f0a-959c-574385a86239@comcast.net>
 <776984c9-6a04-841c-be14-35c684768d27@oracle.com>
 <3d5b4994-04a9-39e8-d2ef-69c3b4f3d722@comcast.net>
 <bd604a60-d9b4-0bc4-ea62-eeefd18e0423@oracle.com>
 <158a31fe-e4b9-2a09-49c7-7801cda9ac6f@comcast.net>
Message-ID: <157419e0-310a-571a-dbf3-21b889d6e3a2@oracle.com>


I created JDK-8184122[1] to track this SunEC refactoring effort.

[1] https://bugs.openjdk.java.net/browse/JDK-8184122

On 7/10/2017 2:51 PM, Michael StJohns wrote:

>  (Hmm.. have you checked to make sure that the list of curves in 
> ecdecode is a subset of the curves in CurveDB - if not you may still 
> have another problem).

What problem do you expect this will cause? If there is a curve that is 
in ecdecode, but not in CurveDB, then that means it is not supported. 
Any attempt to use it should result in the expected exception before 
execution reaches the native code. So the code for this curve in 
ecdecode is effectively dead, and there may be some technical debt here, 
but are there other problems that I am not thinking of?


>
> Thanks-  Mike
>
>



From christoph.langer at sap.com  Tue Jul 11 09:43:08 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 11 Jul 2017 09:43:08 +0000
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <fa029b456fe842d29f13240091119208@sap.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
Message-ID: <18eade66502943fb95d8f88bc2b5cfb8@sap.com>

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' <anthony.scarpino at oracle.com>; 'Sean Mullan'
> <sean.mullan at oracle.com>
> Cc: OpenJDK Security <security-dev at openjdk.java.net>; 'Dieter Bratko'
> <dieter.bratko at iaik.tugraz.at>
> 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-bounces at openjdk.java.net] On
> > Behalf Of Anthony Scarpino
> > Sent: Montag, 13. Februar 2017 22:48
> > To: OpenJDK Security <security-dev at openjdk.java.net>
> > 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

From sean.mullan at oracle.com  Tue Jul 11 17:21:09 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 11 Jul 2017 13:21:09 -0400
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
Message-ID: <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>

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' <anthony.scarpino at oracle.com>; 'Sean Mullan'
>> <sean.mullan at oracle.com>
>> Cc: OpenJDK Security <security-dev at openjdk.java.net>; 'Dieter Bratko'
>> <dieter.bratko at iaik.tugraz.at>
>> 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-bounces at openjdk.java.net] On
>>> Behalf Of Anthony Scarpino
>>> Sent: Montag, 13. Februar 2017 22:48
>>> To: OpenJDK Security <security-dev at openjdk.java.net>
>>> 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


From christoph.langer at sap.com  Tue Jul 11 19:10:10 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 11 Jul 2017 19:10:10 +0000
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
Message-ID: <c257526cb6ba4fd3a7a636322dae06be@sap.com>

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--


From jonathan.gibbons at oracle.com  Tue Jul 11 21:39:08 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 11 Jul 2017 14:39:08 -0700
Subject: RFR: 8184208: update class="striped" tables for accessibility
Message-ID: <5965457C.7030607@oracle.com>

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 (<th>) in the <thead> now declare scope="col"
* the first data cell (<td>) in each row in the <tbody> are changed to <th>
     and declare scope="row".
     Although these cells are changed from <td> to <th>, 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







From brian.burkhalter at oracle.com  Tue Jul 11 23:02:32 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 11 Jul 2017 16:02:32 -0700
Subject: RFR: 8184208: update class="striped" tables for accessibility
In-Reply-To: <5965457C.7030607@oracle.com>
References: <5965457C.7030607@oracle.com>
Message-ID: <D63F6B0D-E058-49B6-8D32-DD7E0AB16A03@oracle.com>

On Jul 11, 2017, at 2:39 PM, Jonathan Gibbons <jonathan.gibbons at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170711/db174581/attachment.htm>

From jonathan.gibbons at oracle.com  Tue Jul 11 23:18:11 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 11 Jul 2017 16:18:11 -0700
Subject: RFR: 8184208: update class="striped" tables for accessibility
In-Reply-To: <D63F6B0D-E058-49B6-8D32-DD7E0AB16A03@oracle.com>
References: <5965457C.7030607@oracle.com>
 <D63F6B0D-E058-49B6-8D32-DD7E0AB16A03@oracle.com>
Message-ID: <59655CB3.5020706@oracle.com>



On 07/11/2017 04:02 PM, Brian Burkhalter wrote:
> On Jul 11, 2017, at 2:39 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170711/1a0bf303/attachment.htm>

From huaming.li at oracle.com  Wed Jul 12 02:28:26 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 12 Jul 2017 10:28:26 +0800
Subject: (10) RFR of JDK-8184165:
 sun.security.provider.PolicyFile$PolicyEntry.toString() throws
 MissingResourceException
Message-ID: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>

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



From weijun.wang at oracle.com  Wed Jul 12 02:50:40 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 12 Jul 2017 10:50:40 +0800
Subject: (10) RFR of JDK-8184165:
 sun.security.provider.PolicyFile$PolicyEntry.toString() throws
 MissingResourceException
In-Reply-To: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>
References: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>
Message-ID: <98A8F329-5A82-4828-B95F-882BB81604AD@oracle.com>

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 <huaming.li at oracle.com> 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
> 



From huaming.li at oracle.com  Wed Jul 12 03:03:11 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 12 Jul 2017 11:03:11 +0800
Subject: (10) RFR of JDK-8184165:
 sun.security.provider.PolicyFile$PolicyEntry.toString() throws
 MissingResourceException
In-Reply-To: <98A8F329-5A82-4828-B95F-882BB81604AD@oracle.com>
References: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>
 <98A8F329-5A82-4828-B95F-882BB81604AD@oracle.com>
Message-ID: <226e6c42-e876-e1f8-9a73-a3b2191fab30@oracle.com>

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 <huaming.li at oracle.com> 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
>>



From weijun.wang at oracle.com  Wed Jul 12 03:06:16 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 12 Jul 2017 11:06:16 +0800
Subject: (10) RFR of JDK-8184165:
 sun.security.provider.PolicyFile$PolicyEntry.toString() throws
 MissingResourceException
In-Reply-To: <226e6c42-e876-e1f8-9a73-a3b2191fab30@oracle.com>
References: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>
 <98A8F329-5A82-4828-B95F-882BB81604AD@oracle.com>
 <226e6c42-e876-e1f8-9a73-a3b2191fab30@oracle.com>
Message-ID: <ACCF355D-06B7-43EE-AFF4-05B75EA9E5A6@oracle.com>


> On Jul 12, 2017, at 11:03 AM, Hamlin Li <huaming.li at oracle.com> 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 <huaming.li at oracle.com> 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
>>> 
> 



From huaming.li at oracle.com  Wed Jul 12 03:36:32 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 12 Jul 2017 11:36:32 +0800
Subject: (10) RFR of JDK-8184165:
 sun.security.provider.PolicyFile$PolicyEntry.toString() throws
 MissingResourceException
In-Reply-To: <ACCF355D-06B7-43EE-AFF4-05B75EA9E5A6@oracle.com>
References: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>
 <98A8F329-5A82-4828-B95F-882BB81604AD@oracle.com>
 <226e6c42-e876-e1f8-9a73-a3b2191fab30@oracle.com>
 <ACCF355D-06B7-43EE-AFF4-05B75EA9E5A6@oracle.com>
Message-ID: <9a844f0c-6f43-a174-03c0-78ad37480476@oracle.com>



On 2017/7/12 11:06, Weijun Wang wrote:
>> On Jul 12, 2017, at 11:03 AM, Hamlin Li <huaming.li at oracle.com> 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 <huaming.li at oracle.com> 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
>>>>



From huaming.li at oracle.com  Wed Jul 12 06:07:50 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 12 Jul 2017 14:07:50 +0800
Subject: (10) RFR of JDK-8184165:
 sun.security.provider.PolicyFile$PolicyEntry.toString() throws
 MissingResourceException
In-Reply-To: <9a844f0c-6f43-a174-03c0-78ad37480476@oracle.com>
References: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>
 <98A8F329-5A82-4828-B95F-882BB81604AD@oracle.com>
 <226e6c42-e876-e1f8-9a73-a3b2191fab30@oracle.com>
 <ACCF355D-06B7-43EE-AFF4-05B75EA9E5A6@oracle.com>
 <9a844f0c-6f43-a174-03c0-78ad37480476@oracle.com>
Message-ID: <d31cebac-1aab-855e-aa3b-4fc169d663dc@oracle.com>

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("xxxx") 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 <huaming.li at oracle.com> 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 <huaming.li at oracle.com> 
>>>>> 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
>>>>>
>



From huaming.li at oracle.com  Wed Jul 12 06:13:41 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 12 Jul 2017 14:13:41 +0800
Subject: (10) RFR of JDK-8184234:
 sun.security.provider.AuthPolicyFile$PolicyEntry.toString() throws
 MissingResourceException
Message-ID: <d3d8166f-f750-a63c-d786-41a5b45da490@oracle.com>

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



From weijun.wang at oracle.com  Wed Jul 12 07:59:10 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 12 Jul 2017 15:59:10 +0800
Subject: (10) RFR of JDK-8184165:
 sun.security.provider.PolicyFile$PolicyEntry.toString() throws
 MissingResourceException
In-Reply-To: <d31cebac-1aab-855e-aa3b-4fc169d663dc@oracle.com>
References: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>
 <98A8F329-5A82-4828-B95F-882BB81604AD@oracle.com>
 <226e6c42-e876-e1f8-9a73-a3b2191fab30@oracle.com>
 <ACCF355D-06B7-43EE-AFF4-05B75EA9E5A6@oracle.com>
 <9a844f0c-6f43-a174-03c0-78ad37480476@oracle.com>
 <d31cebac-1aab-855e-aa3b-4fc169d663dc@oracle.com>
Message-ID: <3D78ACBE-824F-450E-8F16-4007E654B6E0@oracle.com>

Great work! Thanks for going deep on this issue.

Is it possible to change your manual check into an automatic test? I know sources might not be available when running a test, but if something like ${test.src}/../../../src/java.base/share/classes/sun/security/util/ exists it can be a good hint that source codes are available.

Feel free to ignore my suggestion if this is useless. I don?t actually know if the src directory is there in mach5 and JPRT tests.

--Max

> On Jul 12, 2017, at 2:07 PM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> 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("xxxx") 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 <huaming.li at oracle.com> 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 <huaming.li at oracle.com> 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
>>>>>> 
>> 
> 



From weijun.wang at oracle.com  Wed Jul 12 08:00:24 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 12 Jul 2017 16:00:24 +0800
Subject: (10) RFR of JDK-8184234:
 sun.security.provider.AuthPolicyFile$PolicyEntry.toString() throws
 MissingResourceException
In-Reply-To: <d3d8166f-f750-a63c-d786-41a5b45da490@oracle.com>
References: <d3d8166f-f750-a63c-d786-41a5b45da490@oracle.com>
Message-ID: <52A5CC61-BA41-488D-B097-57DCED8211FB@oracle.com>

Change looks fine.

Thanks
Max

> On Jul 12, 2017, at 2:13 PM, Hamlin Li <huaming.li at oracle.com> wrote:
> 
> 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
> 



From huaming.li at oracle.com  Wed Jul 12 08:25:32 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 12 Jul 2017 16:25:32 +0800
Subject: (10) RFR of JDK-8184165:
 sun.security.provider.PolicyFile$PolicyEntry.toString() throws
 MissingResourceException
In-Reply-To: <3D78ACBE-824F-450E-8F16-4007E654B6E0@oracle.com>
References: <69776d6d-f446-3810-c681-92fb7f1bf8fe@oracle.com>
 <98A8F329-5A82-4828-B95F-882BB81604AD@oracle.com>
 <226e6c42-e876-e1f8-9a73-a3b2191fab30@oracle.com>
 <ACCF355D-06B7-43EE-AFF4-05B75EA9E5A6@oracle.com>
 <9a844f0c-6f43-a174-03c0-78ad37480476@oracle.com>
 <d31cebac-1aab-855e-aa3b-4fc169d663dc@oracle.com>
 <3D78ACBE-824F-450E-8F16-4007E654B6E0@oracle.com>
Message-ID: <622c8422-ef97-e03a-f497-f4db6edcdec1@oracle.com>

I'm afraid it's not worth to build such a automatic tool.

Different resource clients uses different resource classes which have 
different resource items, so such a tool must understand which resource 
client is using which resource class, which is not easy or even 
possible. Or we can hard code this relationship in the tool, but this 
will make the tool prone to error in case any code changes.

So I suggest to check it manually every time we change any code in this 
area, of course manual check can be partially automated by some script 
but I don't think it's worth to develop a dedicated tool to do it as you 
still need manual check any way.

Thank you

-Hamlin


On 2017/7/12 15:59, Weijun Wang wrote:
> Great work! Thanks for going deep on this issue.
>
> Is it possible to change your manual check into an automatic test? I know sources might not be available when running a test, but if something like ${test.src}/../../../src/java.base/share/classes/sun/security/util/ exists it can be a good hint that source codes are available.
>
> Feel free to ignore my suggestion if this is useless. I don?t actually know if the src directory is there in mach5 and JPRT tests.
>
> --Max
>
>> On Jul 12, 2017, at 2:07 PM, Hamlin Li <huaming.li at oracle.com> wrote:
>>
>> 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("xxxx") 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 <huaming.li at oracle.com> 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 <huaming.li at oracle.com> 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
>>>>>>>



From dieter.bratko at iaik.tugraz.at  Wed Jul 12 10:30:08 2017
From: dieter.bratko at iaik.tugraz.at (Dieter Bratko)
Date: Wed, 12 Jul 2017 10:30:08 +0000
Subject: AW: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
Message-ID: <5b3eecc480c34ef8ba79746c477a077a@iaik.tugraz.at>

Hello Sean, Christoph,

To explain the reason for our non-compliance to the JCA "<hash>withRSA" signature standard name notation I have to get back to the very beginning. Namely to JDK 1.1.8 which used the "<hash>/RSA" notation as standard names for RSA-PKCSv1.5 signature algorithms (see attachment; I have found a JCK1.1.8 CryptoSpec in our archives : -).
IAIK followed this recommendation and later - as SUN has changed to the <hash>withRSA notation we changed it too -- but then had to turn back since too many users already relied on the "/" slash in the signature algorithm name -- I think for parsing the hash algorithm from it. The problem was not the Signature engine (where getAlgorithm() returns what has been specified when calling Signature.getInstance()), but the names used for ASN.1 AlgorithmIdentifiers (as used by X.509 certificates). So we had to stay with the original JCA standard name notation for our AlgorithmID implementation (but added the possibility allowing users to change the name settings). 
However, we again will check if we can change to the <hash>withRSA notation. Nevertheless, since the CertPath AlgorithmChecker already converts the X509CertImpl it might be more safe to call getSigAlgName() on it -- for Algorithms it knows of (and therefore also knows which names it expects). 

Best Regards,
Dieter

-----Original Message-----
Von: Sean Mullan [mailto:sean.mullan at oracle.com] 
Gesendet: Dienstag, 11. Juli 2017 19:21
An: Langer, Christoph <christoph.langer at sap.com>; Anthony Scarpino <anthony.scarpino at oracle.com>
Cc: OpenJDK Security <security-dev at openjdk.java.net>; Dieter Bratko <dieter.bratko at iaik.tugraz.at>
Betreff: 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' <anthony.scarpino at oracle.com>; 'Sean Mullan'
>> <sean.mullan at oracle.com>
>> Cc: OpenJDK Security <security-dev at openjdk.java.net>; 'Dieter Bratko'
>> <dieter.bratko at iaik.tugraz.at>
>> 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-bounces at openjdk.java.net] On 
>>> Behalf Of Anthony Scarpino
>>> Sent: Montag, 13. Februar 2017 22:48
>>> To: OpenJDK Security <security-dev at openjdk.java.net>
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170712/898e50c2/CryptoSpec.html>

From vincent.x.ryan at oracle.com  Wed Jul 12 14:42:46 2017
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 12 Jul 2017 15:42:46 +0100
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
Message-ID: <2B2884C3-0491-476F-A125-7E4BC2189EA2@oracle.com>

Looks fine to me too.

We should investigate how best to support similar behaviour for the SunPKCS11 provider.
To track this issue I?ve filed a related bug 8184290 <https://bugs.openjdk.java.net/browse/JDK-8184290>: SunPKCS11 throws ProviderException for unsupported curves



> On 10 Jul 2017, at 17:03, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Thanks for the update! Looks fine to me.
> 
> Regards,
> Sean.
> 
> On 10/07/17 16:13, Adam Petcher wrote:
>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/
>> 
>> Yes, this is a good idea. I made this work by printing out the value from AlgorithmParameters.toString(), so hopefully that means you should always get a useful string. At the moment (with SunEC AlgorithmParameters), the string prints the friendly name followed by the OID:
>> 
>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>> 
>> On 7/7/2017 4:12 PM, Se?n Coffey wrote:
>>> Adam,
>>> 
>>> would it be useful to get the curve name in the new exception ? I think it would help with future debugging. Line 96 already gets the curve name if we're dealing with ECGenParameterSpec instance. I think the same approach could be applied to your new code.
>>> 
>>> Regards,
>>> Sean.
>>> 
>>> 
>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>> This is a bug fix related to invalid curves in the SunEC provider. During ECKeyPairGenerator.initialize(), the provider only checks whether the curve is known, but it doesn't check whether the curve is actually supported by the native code. So the call to generateKeyPair() can fail in the native code and throw a ProviderException. This change adds a new native method to check whether the curve is supported. This method is called by initialize(), which will set the state to uninitialized and throw the expected exception when the curve is not supported.
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170712/684f36c0/attachment.htm>

From sean.mullan at oracle.com  Wed Jul 12 14:45:16 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 12 Jul 2017 10:45:16 -0400
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <c257526cb6ba4fd3a7a636322dae06be@sap.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
 <c257526cb6ba4fd3a7a636322dae06be@sap.com>
Message-ID: <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>

On 7/11/17 3:10 PM, Langer, Christoph wrote:
> 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.

Right, as Dieter pointed out in his reply, this seems to go way back to 
the early days of Java when the standard algorithm names were still 
evolving.

> 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?

Yes. In fact I think the most robust solution (even for 9 and later) is 
to look at the encoded AlgorithmId in the X.509 certificate to determine 
what signature algorithm is being used, and this would eliminate the 
compatibility risk with third party providers using non-standard Java 
names. This is exactly what X509CertImpl.getSigAlgName() is doing.
> 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?

Yes, I agree.

Also, note that you can probably also workaround this issue by adding a 
specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms 
security property.

--Sean

> 
> 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--


From adam.petcher at oracle.com  Wed Jul 12 14:51:05 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 12 Jul 2017 10:51:05 -0400
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <2B2884C3-0491-476F-A125-7E4BC2189EA2@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
 <2B2884C3-0491-476F-A125-7E4BC2189EA2@oracle.com>
Message-ID: <21e3e41e-b4b6-7381-d40a-3cdae63f598d@oracle.com>

I made a minor tweak to the test. I realized that the test will still 
pass if the curve becomes supported in the future. I want the test to 
fail in this case because it would no longer be testing an unsupported 
curve.

latest webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.02/


On 7/12/2017 10:42 AM, Vincent Ryan wrote:
> Looks fine to me too.
>
> We should investigate how best to support similar behaviour for the 
> SunPKCS11 provider.
> To track this issue I?ve filed a related bug 8184290 
> <https://bugs.openjdk.java.net/browse/JDK-8184290>: SunPKCS11 throws 
> ProviderException for unsupported curves
>
>
>
>> On 10 Jul 2017, at 17:03, Se?n Coffey <sean.coffey at oracle.com 
>> <mailto:sean.coffey at oracle.com>> wrote:
>>
>> Thanks for the update! Looks fine to me.
>>
>> Regards,
>> Sean.
>>
>> On 10/07/17 16:13, Adam Petcher wrote:
>>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Eapetcher/8182999/webrev.01/>
>>>
>>> Yes, this is a good idea. I made this work by printing out the value 
>>> from AlgorithmParameters.toString(), so hopefully that means you 
>>> should always get a useful string. At the moment (with SunEC 
>>> AlgorithmParameters), the string prints the friendly name followed 
>>> by the OID:
>>>
>>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>>>
>>> On 7/7/2017 4:12 PM, Se?n Coffey wrote:
>>>> Adam,
>>>>
>>>> would it be useful to get the curve name in the new exception ? I 
>>>> think it would help with future debugging. Line 96 already gets the 
>>>> curve name if we're dealing with ECGenParameterSpec instance. I 
>>>> think the same approach could be applied to your new code.
>>>>
>>>> Regards,
>>>> Sean.
>>>>
>>>>
>>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>>> This is a bug fix related to invalid curves in the SunEC provider. 
>>>>> During ECKeyPairGenerator.initialize(), the provider only checks 
>>>>> whether the curve is known, but it doesn't check whether the curve 
>>>>> is actually supported by the native code. So the call to 
>>>>> generateKeyPair() can fail in the native code and throw a 
>>>>> ProviderException. This change adds a new native method to check 
>>>>> whether the curve is supported. This method is called by 
>>>>> initialize(), which will set the state to uninitialized and throw 
>>>>> the expected exception when the curve is not supported.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999
>>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/ 
>>>>> <http://cr.openjdk.java.net/%7Eapetcher/8182999/webrev.00/>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170712/83247ef6/attachment.htm>

From vincent.x.ryan at oracle.com  Wed Jul 12 14:52:16 2017
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 12 Jul 2017 15:52:16 +0100
Subject: RFR 8182999: SunEC throws ProviderException on invalid curves
In-Reply-To: <21e3e41e-b4b6-7381-d40a-3cdae63f598d@oracle.com>
References: <07e2cc50-14c2-969d-72e5-8304a6bf95d9@oracle.com>
 <14859789-787d-49d4-ef5f-dffe372ad2f9@oracle.com>
 <5b80afba-85c2-57cc-2ef0-0709e14534ee@oracle.com>
 <f59e90c5-8c8d-fca7-532b-2f50958eeab1@oracle.com>
 <2B2884C3-0491-476F-A125-7E4BC2189EA2@oracle.com>
 <21e3e41e-b4b6-7381-d40a-3cdae63f598d@oracle.com>
Message-ID: <071E2226-8356-454F-984D-6CA37C2366CC@oracle.com>

+1

> On 12 Jul 2017, at 15:51, Adam Petcher <adam.petcher at oracle.com> wrote:
> 
> I made a minor tweak to the test. I realized that the test will still pass if the curve becomes supported in the future. I want the test to fail in this case because it would no longer be testing an unsupported curve.
> 
> latest webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.02/ <http://cr.openjdk.java.net/~apetcher/8182999/webrev.02/>
> On 7/12/2017 10:42 AM, Vincent Ryan wrote:
>> Looks fine to me too.
>> 
>> We should investigate how best to support similar behaviour for the SunPKCS11 provider.
>> To track this issue I?ve filed a related bug 8184290 <https://bugs.openjdk.java.net/browse/JDK-8184290>: SunPKCS11 throws ProviderException for unsupported curves
>> 
>> 
>> 
>>> On 10 Jul 2017, at 17:03, Se?n Coffey <sean.coffey at oracle.com <mailto:sean.coffey at oracle.com>> wrote:
>>> 
>>> Thanks for the update! Looks fine to me.
>>> 
>>> Regards,
>>> Sean.
>>> 
>>> On 10/07/17 16:13, Adam Petcher wrote:
>>>> New webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.01/ <http://cr.openjdk.java.net/%7Eapetcher/8182999/webrev.01/>
>>>> 
>>>> Yes, this is a good idea. I made this work by printing out the value from AlgorithmParameters.toString(), so hopefully that means you should always get a useful string. At the moment (with SunEC AlgorithmParameters), the string prints the friendly name followed by the OID:
>>>> 
>>>> Unsupported curve: brainpoolP256r1 (1.3.36.3.3.2.8.1.1.7)
>>>> 
>>>> On 7/7/2017 4:12 PM, Se?n Coffey wrote:
>>>>> Adam,
>>>>> 
>>>>> would it be useful to get the curve name in the new exception ? I think it would help with future debugging. Line 96 already gets the curve name if we're dealing with ECGenParameterSpec instance. I think the same approach could be applied to your new code.
>>>>> 
>>>>> Regards,
>>>>> Sean.
>>>>> 
>>>>> 
>>>>> On 07/07/2017 19:59, Adam Petcher wrote:
>>>>>> This is a bug fix related to invalid curves in the SunEC provider. During ECKeyPairGenerator.initialize(), the provider only checks whether the curve is known, but it doesn't check whether the curve is actually supported by the native code. So the call to generateKeyPair() can fail in the native code and throw a ProviderException. This change adds a new native method to check whether the curve is supported. This method is called by initialize(), which will set the state to uninitialized and throw the expected exception when the curve is not supported.
>>>>>> 
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8182999 <https://bugs.openjdk.java.net/browse/JDK-8182999>
>>>>>> Webrev: http://cr.openjdk.java.net/~apetcher/8182999/webrev.00/ <http://cr.openjdk.java.net/%7Eapetcher/8182999/webrev.00/>
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170712/62e398e1/attachment.htm>

From lance.andersen at oracle.com  Wed Jul 12 17:41:59 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 12 Jul 2017 13:41:59 -0400
Subject: RFR: 8184208: update class="striped" tables for accessibility
In-Reply-To: <5965457C.7030607@oracle.com>
References: <5965457C.7030607@oracle.com>
Message-ID: <7B440653-F8F4-4710-9DDB-0009A70BFF0A@oracle.com>

Looks good Jon.

> On Jul 11, 2017, at 5:39 PM, Jonathan Gibbons <jonathan.gibbons at 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.
> 
> 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 (<th>) in the <thead> now declare scope="col"
> * the first data cell (<td>) in each row in the <tbody> are changed to <th>
>    and declare scope="row".
>    Although these cells are changed from <td> to <th>, 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
> 
> 
> 
> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170712/16348219/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170712/16348219/oracle_sig_logo.gif>

From adam.petcher at oracle.com  Wed Jul 12 18:38:25 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 12 Jul 2017 14:38:25 -0400
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
Message-ID: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>

This is a bug fix for a corner case in which a DER value has length 
equal to Integer.MAX_VALUE. The code uses IOUtils.readFully() to read 
the value, which interprets length=Integer.MAX_VALUE to mean "read to 
the end." The result is that no exception will be thrown when fewer then 
Integer.MAX_VALUE bytes are read from the stream. The fix adds a check 
after the readFully() to ensure that the expected number of bytes were 
read.

Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8183591



From ecki at zusammenkunft.net  Wed Jul 12 22:27:12 2017
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 12 Jul 2017 22:27:12 +0000
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
In-Reply-To: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>
References: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>
Message-ID: <HE1PR08MB279581BC833E9F8D6097E782FFAF0@HE1PR08MB2795.eurprd08.prod.outlook.com>

BTW: Can in.available() be < length as well? In that case then exception before your changed line would be misleading.

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: security-dev <security-dev-bounces at openjdk.java.net> on behalf of Adam Petcher <adam.petcher at oracle.com>
Sent: Wednesday, July 12, 2017 8:38:25 PM
To: security-dev at openjdk.java.net
Subject: RFR 8183591: Incorrect behavior when reading DER value with Integer.MAX_VALUE length

This is a bug fix for a corner case in which a DER value has length
equal to Integer.MAX_VALUE. The code uses IOUtils.readFully() to read
the value, which interprets length=Integer.MAX_VALUE to mean "read to
the end." The result is that no exception will be thrown when fewer then
Integer.MAX_VALUE bytes are read from the stream. The fix adds a check
after the readFully() to ensure that the expected number of bytes were
read.

Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8183591

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170712/4362a024/attachment.htm>

From christoph.langer at sap.com  Thu Jul 13 06:59:18 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 13 Jul 2017 06:59:18 +0000
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
 <c257526cb6ba4fd3a7a636322dae06be@sap.com>
 <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>
Message-ID: <7cad75fda90345248769ae600c9c88d4@sap.com>

Hi Sean,

> > 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?
> 
> Yes. In fact I think the most robust solution (even for 9 and later) is
> to look at the encoded AlgorithmId in the X.509 certificate to determine
> what signature algorithm is being used, and this would eliminate the
> compatibility risk with third party providers using non-standard Java
> names. This is exactly what X509CertImpl.getSigAlgName() is doing.

OK, I will file a bug and post a change for review.

I then suggest to also revert JDK10 and 9 to use X509CertImpl.getSigAlgName() for the time being until some better check to go for the encoded AlgorithmId. Would you be fine with that?


> Also, note that you can probably also workaround this issue by adding a
> specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms
> security property.

Hm, I thought with that property you would only define a negative list of algorithms that are not supported (out of the known ones). But is it possible to specify an unknown algorithm name to whitelist?

Thanks
Christoph


From adam.petcher at oracle.com  Thu Jul 13 14:25:31 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Thu, 13 Jul 2017 10:25:31 -0400
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
In-Reply-To: <HE1PR08MB279581BC833E9F8D6097E782FFAF0@HE1PR08MB2795.eurprd08.prod.outlook.com>
References: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>
 <HE1PR08MB279581BC833E9F8D6097E782FFAF0@HE1PR08MB2795.eurprd08.prod.outlook.com>
Message-ID: <f3eab5f3-9d48-e58d-264d-c184c1407650@oracle.com>

On 7/12/2017 6:27 PM, Bernd Eckenfels wrote:

> BTW: Can in.available() be < length as well? In that case then 
> exception before your changed line would be misleading.
>

Yes. I changed the text of that exception to make it a bit more general, 
and made the text of the new exception match.

New webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.01/

> Gruss
> Bernd
>
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *From:* security-dev <security-dev-bounces at openjdk.java.net> on behalf 
> of Adam Petcher <adam.petcher at oracle.com>
> *Sent:* Wednesday, July 12, 2017 8:38:25 PM
> *To:* security-dev at openjdk.java.net
> *Subject:* RFR 8183591: Incorrect behavior when reading DER value with 
> Integer.MAX_VALUE length
> This is a bug fix for a corner case in which a DER value has length
> equal to Integer.MAX_VALUE. The code uses IOUtils.readFully() to read
> the value, which interprets length=Integer.MAX_VALUE to mean "read to
> the end." The result is that no exception will be thrown when fewer then
> Integer.MAX_VALUE bytes are read from the stream. The fix adds a check
> after the readFully() to ensure that the expected number of bytes were
> read.
>
> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/ 
> <http://cr.openjdk.java.net/%7Eapetcher/8183591/webrev.00/>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8183591
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170713/57b3ffc8/attachment.htm>

From anthony.scarpino at oracle.com  Thu Jul 13 18:26:40 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 13 Jul 2017 11:26:40 -0700
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <7cad75fda90345248769ae600c9c88d4@sap.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
 <c257526cb6ba4fd3a7a636322dae06be@sap.com>
 <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>
 <7cad75fda90345248769ae600c9c88d4@sap.com>
Message-ID: <717fcb60-9b1e-d62f-08e0-c6e22980c792@oracle.com>

On 07/12/2017 11:59 PM, Langer, Christoph wrote:
> Hi Sean,
> 
>>> 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?
>>
>> Yes. In fact I think the most robust solution (even for 9 and later) is
>> to look at the encoded AlgorithmId in the X.509 certificate to determine
>> what signature algorithm is being used, and this would eliminate the
>> compatibility risk with third party providers using non-standard Java
>> names. This is exactly what X509CertImpl.getSigAlgName() is doing.
> 
> OK, I will file a bug and post a change for review.
> 
> I then suggest to also revert JDK10 and 9 to use
> X509CertImpl.getSigAlgName() forthe time being until some better
> check to go for the encoded AlgorithmId. Would you be fine with
> that
Looking back at the original code, before any of these changes were put 
in, it was always "((X509Certificate)cert).getSigAlgName();". I would 
guess I changed this in February to go back to the original method called.

> 
> 
>> Also, note that you can probably also workaround this issue by adding a
>> specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms
>> security property.
> 
> Hm, I thought with that property you would only define a negative 
> list of algorithms that are not supported (out of the known ones).
> But is it possible to specify an unknown algorithm name to whitelist?

It is a negative list and it has to match the algorithm name.  There is 
no unknown/catch-all.

> 
> Thanks
> Christoph
> 



From anthony.scarpino at oracle.com  Fri Jul 14 03:36:03 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 13 Jul 2017 20:36:03 -0700
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <717fcb60-9b1e-d62f-08e0-c6e22980c792@oracle.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
 <c257526cb6ba4fd3a7a636322dae06be@sap.com>
 <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>
 <7cad75fda90345248769ae600c9c88d4@sap.com>
 <717fcb60-9b1e-d62f-08e0-c6e22980c792@oracle.com>
Message-ID: <62952377-2003-f4da-e4e8-f8c283d96079@oracle.com>

On 07/13/2017 11:26 AM, Anthony Scarpino wrote:
> On 07/12/2017 11:59 PM, Langer, Christoph wrote:
>> I then suggest to also revert JDK10 and 9 to use
>> X509CertImpl.getSigAlgName() forthe time being until some better
>> check to go for the encoded AlgorithmId. Would you be fine with
>> that
> Looking back at the original code, before any of these changes were put 
> in, it was always "((X509Certificate)cert).getSigAlgName();". I would 
> guess I changed this in February to go back to the original method called.

Ignore my comments above, I didn't go far enough back in the changeset 
diffs to see it had used X509CertImpl originally.

Tony


From anthony.scarpino at oracle.com  Fri Jul 14 04:25:27 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 13 Jul 2017 21:25:27 -0700
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
 <c257526cb6ba4fd3a7a636322dae06be@sap.com>
 <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>
Message-ID: <0f8409a6-6ae1-94da-0ca1-520d71a9d9e4@oracle.com>

On 07/12/2017 07:45 AM, Sean Mullan wrote:
> On 7/11/17 3:10 PM, Langer, Christoph wrote:

>> 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?
> 
> Yes, I agree.
> 
> Also, note that you can probably also workaround this issue by adding a 
> specific "SHA1/RSA" constraint to the jdk.certpath.disabledAlgorithms 
> security property.
> 
> --Sean

The problem cannot be resolved by jdk.certpath.disabledAlgorithms. 
Without using X509CertImpl, the non-standard "SHA1/RSA" is not converted 
to "SHA1withRSA" The failing call is in the 
SSLAlgorithConstraints.permit() checks by matching the algorithm name 
with a list of standard supported algorithm names, and therefore fails.

Tony



From sha.jiang at oracle.com  Fri Jul 14 07:11:05 2017
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Fri, 14 Jul 2017 15:11:05 +0800
Subject: RFR JDK-8179614: Test for jarsigner on verifying jars that are
 signed and timestamped by other JDK releases
In-Reply-To: <4dae591e-12c5-c5de-fb6b-793d1b8b3d96@oracle.com>
References: <e1952678-3f0f-e5ef-359a-fce253e6704c@oracle.com>
 <5b75241c-1148-fe4f-bd6e-328f5737fed4@oracle.com>
 <b70f0c2c-7f05-ea15-42ea-54fac3b08667@oracle.com>
 <7bf702ef-5ba4-e2b4-5b88-1c6ab222534f@oracle.com>
 <ac9b244e-94bc-4cd4-b813-9de05643a7c0@oracle.com>
 <0fbe602f-6ba7-a05c-f163-9e15aeddeab4@oracle.com>
 <14c8a086-7e48-312b-3c15-917dcdc7061c@oracle.com>
 <0f0ce594-6ec3-0315-6627-a7cbe7cde294@oracle.com>
 <02569226-c63e-52ce-0519-e88cabde8358@oracle.com>
 <85acb154-534d-daa7-d200-c3bea4607de9@oracle.com>
 <be76d0eb-40ae-4523-63ff-4d678dac9f6d@oracle.com>
 <4dae591e-12c5-c5de-fb6b-793d1b8b3d96@oracle.com>
Message-ID: <6666238f-825c-629f-dcc6-4f27a4df6c98@oracle.com>

Hi,
Please review the latest webrev at: 
http://cr.openjdk.java.net/~jjiang/8179614/webrev.09/
This test has been updated significantly. It removes useless case 
combinations, and generates reports in HTML. For more details, please 
look through the test summary.

Best regards,
John Jiang

On 13/06/2017 23:47, sha.jiang at oracle.com wrote:
> Sean and Max,
> Please review this updated webrev: 
> http://cr.openjdk.java.net/~jjiang/8179614/webrev.03/
>
> The main changes are:
> 1. It provides two new properties, tsaList and tsaListFile, for 
> specifying a list of TSA services.
> And a new report column [TSA] is introduced. This column just display 
> the TSA indices and all of TSA services are displayed at the top of 
> the report.
> 2. If property strict is true, the cases on failed signing are not 
> ignored. They still be listed in the test report, and the status of 
> verifying are NONE.
>
> Best regards,
> John Jiang
>
> On 13/06/2017 06:51, sha.jiang at oracle.com wrote:
>> Hi Max,
>>
>> On 12/06/2017 17:29, Weijun Wang wrote:
>>> Great. Only 2 questions:
>>>
>>>  459     // Return key sizes according to the specified key algorithm.
>>>  460     private static int[] keySizes(String digestAlgorithm, 
>>> String keyAlgorithm) {
>>>  461         if (digestAlgorithm == DEFAULT) {
>>>  462             return new int[] { 0 };
>>>  463         }
>>>  464
>>>  465         if (keyAlgorithm == RSA || keyAlgorithm == DSA) {
>>>  466             return new int[] { 1024, 2048 };
>>>  467         } else if (keyAlgorithm == EC) {
>>>  468             return new int[] { 384, 571 };
>>>  469         }
>>>  470
>>>  471         return null;
>>>  472     }
>>>
>>> Why is keysize dependent on digestalg? I mean, is it possible to 
>>> always return {1024,2048,0} and {384,571,0}?
>> Get it, thanks!
>>>
>>>  379     // If signing fails, the following verifying has to
>>>  380     // be ignored.
>>>  381     if (signingStatus == STATUS.ERROR) {
>>>  382         continue;
>>>  383     }
>>>
>>> Now that you've already checked sigalg support earlier in what cases 
>>> it could go wrong here?
>> Jar signing still could fail. For example, TSA service is unavailable.
>>
>> Best regards,
>> John Jiang
>>>
>>> Thanks
>>> Max
>>>
>>> On 06/12/2017 03:20 PM, sha.jiang at oracle.com wrote:
>>>> Hi Max,
>>>> Would you like to review the updated webrev: 
>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.02/
>>>> It can create certificate without -sigalg and -keysize, and jar 
>>>> signing also can use this certificate.
>>>>
>>>> Best regards,
>>>> John Jiang
>>>>
>>>> On 09/06/2017 22:04, Weijun Wang wrote:
>>>>>
>>>>> On 06/09/2017 09:25 PM, sha.jiang at oracle.com wrote:
>>>>>> Hi Max,
>>>>>>
>>>>>> On 09/06/2017 20:05, Weijun Wang wrote:
>>>>>>> The test can be more friendly with default values.
>>>>>>>
>>>>>>> For example, in createCertificates(), you can generate certs 
>>>>>>> that use default sigalg and keysize (i.e. without specifying 
>>>>>>> -siglag and -keysize), and give them aliases with "default" or 
>>>>>>> "null" inside.
>>>>>>>
>>>>>>> And in jar signing when signing with one -sigalg you can also 
>>>>>>> choose cert generated with different or default sigalgs.
>>>>>> I supposed this test just focus on signed jar verifying, but not 
>>>>>> certificate creating and jar signing. So, I'm not sure such cases 
>>>>>> are necessary.
>>>>>
>>>>> Well sometimes a test can do many things. If you only care about 
>>>>> jar verification, why bother creating certs with different digest 
>>>>> algorithms?
>>>>>
>>>>> On the other hand, if you do care about more, then in
>>>>>
>>>>>  338     // If the digest algorithm is not specified, then it
>>>>>  339     // uses certificate with SHA256 digest and 1024 key
>>>>>  340     // size.
>>>>>  341     if (digestAlgorithm == DEFAULT) {
>>>>>  342         certDigest = SHA256;
>>>>>  343         certKeySize = 1024;
>>>>>  344     }
>>>>>
>>>>> it seems a little awkward to hardcode the algorithm and keysize. 
>>>>> If signing is using a default algorithm, it seems natural to use 
>>>>> the cert that was generated with a default algorithm. In fact, 
>>>>> this test case is quite useful that it ensures our different tools 
>>>>> are using the same (or at least interoperable) default algorithms.
>>>>>
>>>>> --Max
>>>>>
>>>>>>>
>>>>>>> BTW, I remember certain pairs of -keysize and -sigalg do not 
>>>>>>> work together. For example, 1024 bit of DSA key cannot be used 
>>>>>>> with SHA512withDSA signature algorithm. Have you noticed it?
>>>>>> It looks SHA512withDSA is not supported yet.
>>>>>> I was using JDK10 build 10. When the test tried to create 
>>>>>> certificate with -keyalg DSA -sigalg SHA512withDSA -keysize 1024, 
>>>>>> the below error raised:
>>>>>> keytool error: java.security.NoSuchAlgorithmException: 
>>>>>> unrecognized algorithm name: SHA512withDSA
>>>>>>
>>>>>> If used -keyalg DSA -sigalg SHA1withDSA -keysize 2048, the error 
>>>>>> was:
>>>>>> keytool error: java.security.InvalidKeyException: The security 
>>>>>> strength of SHA-1 digest algorithm is not sufficient for this key 
>>>>>> size
>>>>>>
>>>>>> Again, this test focus on signed jar verifying. If some problems 
>>>>>> are raised on certificate creating or jar signing, the associated 
>>>>>> verifying cases will be ignored.
>>>>>>
>>>>>> Best regards,
>>>>>> John Jiang
>>>>>>>
>>>>>>> Thanks
>>>>>>> Max
>>>>>>>
>>>>>>>
>>>>>>> On 06/09/2017 04:44 PM, sha.jiang at oracle.com wrote:
>>>>>>>> Hi Sean and Max,
>>>>>>>> Thanks for your comments.
>>>>>>>> Please review the updated webrev: 
>>>>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.01/
>>>>>>>>
>>>>>>>> The test has been modified significantly. The main points are:
>>>>>>>> 1. Adds cases on EC. Now the test supports key algorithms RSA, 
>>>>>>>> DSA and EC.
>>>>>>>> 2. Adds cases on SHA-512. Now the test supports digest 
>>>>>>>> algorithms SHA-1, SHA-256 and SHA-512.
>>>>>>>> 3. Adds cases on key size. Exactly, [384, 571] for EC, [1024, 
>>>>>>>> 2048] for RSA and DSA.
>>>>>>>> 4. Adds cases on default signature algorithm. Now the test 
>>>>>>>> report can display the default algorithmat column [Signature 
>>>>>>>> Algorithm].
>>>>>>>> 5. Adds property -Djava.security.egd=file:/dev/./urandom for 
>>>>>>>> keytool and jarsigner commands.
>>>>>>>> 6. Create a separated application, JdkUtils.java, to determine 
>>>>>>>> the JDK build version (java.runtime.version) and check if a 
>>>>>>>> signature algorithm is supported by a JDK.
>>>>>>>> 7. Introduces a new property, named javaSecurityFile, for 
>>>>>>>> allowing users to specify alternative java security properties 
>>>>>>>> file.
>>>>>>>> 8. Renames report column [Cert Type] to [Certificate]. This 
>>>>>>>> column displays the certificate identifiers, which is a 
>>>>>>>> combination of key algorithm, digest algorithm, key size and 
>>>>>>>> expired mark (if any).
>>>>>>>> 9. The test summary also be updated accordingly.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> John Jiang
>>>>>>>>
>>>>>>>>
>>>>>>>> On 07/06/2017 23:11, Sean Mullan wrote:
>>>>>>>>> On 6/6/17 9:14 PM, sha.jiang at oracle.com wrote:
>>>>>>>>>> Hi Sean,
>>>>>>>>>>
>>>>>>>>>> On 07/06/2017 04:27, Sean Mullan wrote:
>>>>>>>>>>> Hi John,
>>>>>>>>>>>
>>>>>>>>>>> This looks like a very useful test. I have not gone through 
>>>>>>>>>>> all of the code, but here are a few comments for now until I 
>>>>>>>>>>> have more time:
>>>>>>>>>>>
>>>>>>>>>>> - add tests for EC keys
>>>>>>>>>>> - add tests for SHA-512 variants of the signature algorithms
>>>>>>>>>>> - add tests for larger key sizes (ex: 2048 for DSA/RSA)
>>>>>>>>>>> - you can use the diamond operator <> in various places
>>>>>>>>>>> - might be more compact if jdkList() used Files.lines() to 
>>>>>>>>>>> parse the file into a stream then an array
>>>>>>>>>> I did consider about the above two points. Because the test 
>>>>>>>>>> will be backported to JDK 6, so I only used the features 
>>>>>>>>>> those supported by JDK 6.
>>>>>>>>>> I supposed that would make the backport easier. Does it make 
>>>>>>>>>> sense?
>>>>>>>>>
>>>>>>>>> Yes, that makes sense.
>>>>>>>>>
>>>>>>>>> --Sean
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> John Jiang
>>>>>>>>>>> - did you consider using the jarsigner API 
>>>>>>>>>>> (jdk.security.jarsigner) instead of the command-line? I 
>>>>>>>>>>> think this would be better (if possible) and it would give 
>>>>>>>>>>> us some more tests of that API.
>>>>>>>>>>>
>>>>>>>>>>> --Sean
>>>>>>>>>>>
>>>>>>>>>>> On 6/5/17 6:31 AM, sha.jiang at oracle.com wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> Please review this manual test for checking if a jar, which 
>>>>>>>>>>>> is signed and timestamped by a JDK build, could be verified 
>>>>>>>>>>>> by other JDK builds.
>>>>>>>>>>>> It also can be used to check if the default timestamp 
>>>>>>>>>>>> digest algorithm on signing is SHA-256.
>>>>>>>>>>>> For more details, please look through the test summary.
>>>>>>>>>>>>
>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8179614
>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8179614/webrev.00/
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> John Jiang
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170714/6eab10f6/attachment.htm>

From sean.coffey at oracle.com  Fri Jul 14 10:17:17 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 14 Jul 2017 11:17:17 +0100
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <0f8409a6-6ae1-94da-0ca1-520d71a9d9e4@oracle.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
 <c257526cb6ba4fd3a7a636322dae06be@sap.com>
 <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>
 <0f8409a6-6ae1-94da-0ca1-520d71a9d9e4@oracle.com>
Message-ID: <f3b30092-d658-1f80-538b-8ad90e15bfbf@oracle.com>

Tony,

I think we should log a JDK 8u bug for this issue if one doesn't already 
exist. If the buggy SigAlgName was allowed in 8u updates already, then 
it should be continued to be allowed for compatibility reasons IMO. 
There might be time to revert that change in 8u152.

For 9, then maybe we can document the minor behavioural change that' 
been introduced.

Regards,
Sean.

On 14/07/17 05:25, Anthony Scarpino wrote:
> On 07/12/2017 07:45 AM, Sean Mullan wrote:
>> On 7/11/17 3:10 PM, Langer, Christoph wrote:
>
>>> 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?
>>
>> Yes, I agree.
>>
>> Also, note that you can probably also workaround this issue by adding 
>> a specific "SHA1/RSA" constraint to the 
>> jdk.certpath.disabledAlgorithms security property.
>>
>> --Sean
>
> The problem cannot be resolved by jdk.certpath.disabledAlgorithms. 
> Without using X509CertImpl, the non-standard "SHA1/RSA" is not 
> converted to "SHA1withRSA" The failing call is in the 
> SSLAlgorithConstraints.permit() checks by matching the algorithm name 
> with a list of standard supported algorithm names, and therefore fails.
>
> Tony
>



From weijun.wang at oracle.com  Fri Jul 14 15:12:55 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 14 Jul 2017 23:12:55 +0800
Subject: JDK-8182879: Add warnings to keytool when using JKS and JCEKS
In-Reply-To: <d2f7d47b-a4a5-e4bb-0f50-5c73e758cdc4@oracle.com>
References: <a9ec3e7a-df0d-d9b0-16b1-1a11d1a3ef30@oracle.com>
 <0b386e4f-0a02-dd33-0f46-cd23a61a6052@oracle.com>
 <23bb9d6a-47d6-5b52-3543-e92ae2391bd3@oracle.com>
 <C92193BC-C0B6-40B1-BB1D-58B77BD2DF62@oracle.com>
 <315631d5-545b-b864-6b7e-0ba68ac7b63a@oracle.com>
 <69d8d0b6-6ce8-3a54-f935-2e303057213f@oracle.com>
 <FFAE9EA8-DD05-4105-96AA-65E20D532B7C@oracle.com>
 <1d01a327-b1cf-bd30-7cad-93237778ef8a@oracle.com>
 <d2f7d47b-a4a5-e4bb-0f50-5c73e758cdc4@oracle.com>
Message-ID: <1FAB385C-D9D8-4790-BFDA-FB10C1D6AAE9@oracle.com>


> On Jul 14, 2017, at 7:00 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> I think we should add a Release Note to 8182879 indicating that keytool now emits a warning for JKS/JCEKS keystores.
> 

https://bugs.openjdk.java.net/browse/JDK-8184671 filed. Please take a review.

"When keytool is operating on a JKS or JCEKS keystore, a warning will be shown that the keystore uses a proprietary format and migrating to PKCS12 is suggested. The keytool's -importkeystore command is also updated so that it can convert a keystore from one type to another if the source and destination point to the same file.?

Thanks
Max



From sean.mullan at oracle.com  Fri Jul 14 15:20:00 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 14 Jul 2017 11:20:00 -0400
Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps
 as unsigned
In-Reply-To: <10e34c58-0b55-0b75-8500-64ba2cc7386b@oracle.com>
References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com>
 <10e34c58-0b55-0b75-8500-64ba2cc7386b@oracle.com>
Message-ID: <652181dc-a523-3316-55f5-2ca995d7b967@oracle.com>

Finally getting back to reviewing this update. A few comments:

SignatureFileVerifier.java:

  729                     debug.println("getTimeStamp caught: "+e);

Can you add a more descriptive message here, like: "Exception processing 
timestamp, code will be treated as signed, but not timestamped: ".

Resources.java:

  209         {".CertPath.not.validated.", "[CertPath not validated: "},
  210         {".TSA.CertPath.not.validated.", "[TSA CertPath not 
validated: "},

I think it would be more clear to say "Invalid CertPath". "not 
validated" sounds like keytool didn't even try to validate the path.

Also, I think you should say "certificate chain" instead of "CertPath" 
because that is the term that is used in all the other certificate chain 
messages emitted by keytool.

  265         {"The.tsa.certificate.chain.is.not.validated.reason.1",
  266                 "The TSA certificate chain is not validated. 
Reason: %s"},

s/not validated/invalid/

  275 
{"This.jar.contains.entries.whose.tsa.certificate.chain.is.not.validated.reason.1",
  276                 "This jar contains entries whose TSA certificate 
chain is not validated. Reason: %s"},

s/not/validated/invalid/

  281         {"bad.timestamp.verifying",
  282                 "This jar contains signatures that include an 
invalid timestamp. Without a valid timestamp, users may not be able to 
validate this jar after any of the signer certificates expire (as early 
as %1$tY-%1$tm-%1$td)."},

Can you also include information how to debug this, i.e. "Rerun 
jarsigner with -J-Djava.security.debug=jar for more information."

--Sean

On 5/22/17 11:43 AM, Weijun Wang wrote:
> An updated webrev at
> 
>    http://cr.openjdk.java.net/~weijun/8166222/webrev.01/
> 
> Some more changes:
> 
> - TSA cert chain validation is performed in both verification and 
> signing. The exit code for validation failure when -strict is specified 
> is 64.
> 
> - printCert() and validateCertChain() know about they are dealing with 
> TSA cert chain and do not touch any flag except for 
> tsaChainNotValidated. Code being a little ugly.
> 
> - TSA certs lines added to -verbose -certs.
> 
> BTW, the code change also fixed 
> https://bugs.openjdk.java.net/browse/JDK-8180289.
> 
> Here is an example:
> 
> $ jarsigner -verify -strict ts2.jar -verbose -certs
> 
> s k      75 Mon May 22 22:49:06 CST 2017 META-INF/MANIFEST.MF
> 
>        [entry was signed on 5/22/17, 10:49 PM]
>        >>> Signer
>        X.509, CN=signer (signer)
>        [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM]
>        X.509, CN=CA (ca)
>        [certificate is valid from 4/12/17, 10:49 PM to 10/29/17, 10:49 PM]
>        >>> TSA
>        X.509, CN=ts
>        [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM]
>        [ExtendedKeyUsage extension does not support timestamping]
>        [TSA CertPath not validated: Extended key usage does not permit 
> use for TSA server]
> 
>          305 Mon May 22 22:49:08 CST 2017 META-INF/SIGNER.SF
>         3096 Mon May 22 22:51:06 CST 2017 META-INF/SIGNER.RSA
> smk       1 Mon May 22 22:48:56 CST 2017 A
> 
>        [entry was signed on 5/22/17, 10:49 PM]
>        >>> Signer
>        X.509, CN=signer (signer)
>        [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM]
>        X.509, CN=CA (ca)
>        [certificate is valid from 4/12/17, 10:49 PM to 10/29/17, 10:49 PM]
>        >>> TSA
>        X.509, CN=ts
>        [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM]
>        [TSA CertPath not validated: Extended key usage does not permit 
> use for TSA server]
> 
> 
>    s = signature was verified
>    m = entry is listed in manifest
>    k = at least one certificate was found in keystore
> 
> - Signed by "CN=signer"
>      Digest algorithm: SHA-256
>      Signature algorithm: SHA256withRSA, 2048-bit key
>    Timestamped by "CN=ts" on Mon May 22 14:49:08 UTC 2017
>      Timestamp digest algorithm: SHA-256
>      Timestamp signature algorithm: SHA1withRSA, 2048-bit key
> 
> jar verified, with signer errors.
> 
> Error:
> This jar contains entries whose TSA certificate chain is not validated. 
> Reason: Extended key usage does not permit use for TSA server
> 
> Thanks
> Max
> 
> 
> On 04/12/2017 11:52 PM, Weijun Wang wrote:
>> Please take a review at
>>
>>     http://cr.openjdk.java.net/~weijun/8166222/webrev.00/
>>
>> The major code change is inside SignatureFileVerifier.java. Now if the 
>> timestamp on a signed jar is invalid (For example, using a weak 
>> algorithm now disabled), the jar file will be treated as a signed jar 
>> without a timestamp. Before this change, it was treated unsigned.
>>
>> In jarsigner/Main.java, I also add a line to validate the TSA cert 
>> chain. If not validated, a warning will be shown which is similar to 
>> the one when signer cert chain is not validated. If -strict is on, 
>> exit code will change too.
>>
>> I also make a small change at
>>
>>     http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/
>>
>> The executeCommand() method shows more info (mainly stdout and stderr 
>> outputs) than executeProcess().
>>
>> Because of the behavior change and new warnings, this change will need 
>> a Compatibility and Specification Review (CSR). At the moment, please 
>> review the code change first.
>>
>> Thanks
>> Max


From weijun.wang at oracle.com  Fri Jul 14 15:22:49 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 14 Jul 2017 23:22:49 +0800
Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps
 as unsigned
In-Reply-To: <652181dc-a523-3316-55f5-2ca995d7b967@oracle.com>
References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com>
 <10e34c58-0b55-0b75-8500-64ba2cc7386b@oracle.com>
 <652181dc-a523-3316-55f5-2ca995d7b967@oracle.com>
Message-ID: <AAB2B02E-3E6C-45AD-9496-C7B06C07FA13@oracle.com>

All comments accepted. I?ll update my webrev next month. :-)

No comment on real code change?

--Max
 
> On Jul 14, 2017, at 11:20 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Finally getting back to reviewing this update. A few comments:
> 
> SignatureFileVerifier.java:
> 
> 729                     debug.println("getTimeStamp caught: "+e);
> 
> Can you add a more descriptive message here, like: "Exception processing timestamp, code will be treated as signed, but not timestamped: ".
> 
> Resources.java:
> 
> 209         {".CertPath.not.validated.", "[CertPath not validated: "},
> 210         {".TSA.CertPath.not.validated.", "[TSA CertPath not validated: "},
> 
> I think it would be more clear to say "Invalid CertPath". "not validated" sounds like keytool didn't even try to validate the path.
> 
> Also, I think you should say "certificate chain" instead of "CertPath" because that is the term that is used in all the other certificate chain messages emitted by keytool.
> 
> 265         {"The.tsa.certificate.chain.is.not.validated.reason.1",
> 266                 "The TSA certificate chain is not validated. Reason: %s"},
> 
> s/not validated/invalid/
> 
> 275 {"This.jar.contains.entries.whose.tsa.certificate.chain.is.not.validated.reason.1",
> 276                 "This jar contains entries whose TSA certificate chain is not validated. Reason: %s"},
> 
> s/not/validated/invalid/
> 
> 281         {"bad.timestamp.verifying",
> 282                 "This jar contains signatures that include an invalid timestamp. Without a valid timestamp, users may not be able to validate this jar after any of the signer certificates expire (as early as %1$tY-%1$tm-%1$td)."},
> 
> Can you also include information how to debug this, i.e. "Rerun jarsigner with -J-Djava.security.debug=jar for more information."
> 
> --Sean
> 
> On 5/22/17 11:43 AM, Weijun Wang wrote:
>> An updated webrev at
>>   http://cr.openjdk.java.net/~weijun/8166222/webrev.01/
>> Some more changes:
>> - TSA cert chain validation is performed in both verification and signing. The exit code for validation failure when -strict is specified is 64.
>> - printCert() and validateCertChain() know about they are dealing with TSA cert chain and do not touch any flag except for tsaChainNotValidated. Code being a little ugly.
>> - TSA certs lines added to -verbose -certs.
>> BTW, the code change also fixed https://bugs.openjdk.java.net/browse/JDK-8180289.
>> Here is an example:
>> $ jarsigner -verify -strict ts2.jar -verbose -certs
>> s k      75 Mon May 22 22:49:06 CST 2017 META-INF/MANIFEST.MF
>>       [entry was signed on 5/22/17, 10:49 PM]
>>       >>> Signer
>>       X.509, CN=signer (signer)
>>       [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM]
>>       X.509, CN=CA (ca)
>>       [certificate is valid from 4/12/17, 10:49 PM to 10/29/17, 10:49 PM]
>>       >>> TSA
>>       X.509, CN=ts
>>       [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM]
>>       [ExtendedKeyUsage extension does not support timestamping]
>>       [TSA CertPath not validated: Extended key usage does not permit use for TSA server]
>>         305 Mon May 22 22:49:08 CST 2017 META-INF/SIGNER.SF
>>        3096 Mon May 22 22:51:06 CST 2017 META-INF/SIGNER.RSA
>> smk       1 Mon May 22 22:48:56 CST 2017 A
>>       [entry was signed on 5/22/17, 10:49 PM]
>>       >>> Signer
>>       X.509, CN=signer (signer)
>>       [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM]
>>       X.509, CN=CA (ca)
>>       [certificate is valid from 4/12/17, 10:49 PM to 10/29/17, 10:49 PM]
>>       >>> TSA
>>       X.509, CN=ts
>>       [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM]
>>       [TSA CertPath not validated: Extended key usage does not permit use for TSA server]
>>   s = signature was verified
>>   m = entry is listed in manifest
>>   k = at least one certificate was found in keystore
>> - Signed by "CN=signer"
>>     Digest algorithm: SHA-256
>>     Signature algorithm: SHA256withRSA, 2048-bit key
>>   Timestamped by "CN=ts" on Mon May 22 14:49:08 UTC 2017
>>     Timestamp digest algorithm: SHA-256
>>     Timestamp signature algorithm: SHA1withRSA, 2048-bit key
>> jar verified, with signer errors.
>> Error:
>> This jar contains entries whose TSA certificate chain is not validated. Reason: Extended key usage does not permit use for TSA server
>> Thanks
>> Max
>> On 04/12/2017 11:52 PM, Weijun Wang wrote:
>>> Please take a review at
>>> 
>>>    http://cr.openjdk.java.net/~weijun/8166222/webrev.00/
>>> 
>>> The major code change is inside SignatureFileVerifier.java. Now if the timestamp on a signed jar is invalid (For example, using a weak algorithm now disabled), the jar file will be treated as a signed jar without a timestamp. Before this change, it was treated unsigned.
>>> 
>>> In jarsigner/Main.java, I also add a line to validate the TSA cert chain. If not validated, a warning will be shown which is similar to the one when signer cert chain is not validated. If -strict is on, exit code will change too.
>>> 
>>> I also make a small change at
>>> 
>>>    http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/
>>> 
>>> The executeCommand() method shows more info (mainly stdout and stderr outputs) than executeProcess().
>>> 
>>> Because of the behavior change and new warnings, this change will need a Compatibility and Specification Review (CSR). At the moment, please review the code change first.
>>> 
>>> Thanks
>>> Max



From sean.mullan at oracle.com  Fri Jul 14 15:25:03 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 14 Jul 2017 11:25:03 -0400
Subject: JDK-8182879: Add warnings to keytool when using JKS and JCEKS
In-Reply-To: <1FAB385C-D9D8-4790-BFDA-FB10C1D6AAE9@oracle.com>
References: <a9ec3e7a-df0d-d9b0-16b1-1a11d1a3ef30@oracle.com>
 <0b386e4f-0a02-dd33-0f46-cd23a61a6052@oracle.com>
 <23bb9d6a-47d6-5b52-3543-e92ae2391bd3@oracle.com>
 <C92193BC-C0B6-40B1-BB1D-58B77BD2DF62@oracle.com>
 <315631d5-545b-b864-6b7e-0ba68ac7b63a@oracle.com>
 <69d8d0b6-6ce8-3a54-f935-2e303057213f@oracle.com>
 <FFAE9EA8-DD05-4105-96AA-65E20D532B7C@oracle.com>
 <1d01a327-b1cf-bd30-7cad-93237778ef8a@oracle.com>
 <d2f7d47b-a4a5-e4bb-0f50-5c73e758cdc4@oracle.com>
 <1FAB385C-D9D8-4790-BFDA-FB10C1D6AAE9@oracle.com>
Message-ID: <473b0e27-01de-f9ab-413f-c75c4cdaf0b7@oracle.com>

On 7/14/17 11:12 AM, Weijun Wang wrote:
> 
>> On Jul 14, 2017, at 7:00 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> I think we should add a Release Note to 8182879 indicating that keytool now emits a warning for JKS/JCEKS keystores.
>>
> 
> https://bugs.openjdk.java.net/browse/JDK-8184671 filed. Please take a review.
> 
> "When keytool is operating on a JKS or JCEKS keystore

It doesn't show the warning if it only contains trusted certificate 
entries, right?

I wonder if you should be more specific, ex - "on a JKS or JCEKS 
keystore containing private or secret key entries". But that might 
reveal too much.

Maybe just change "will" to "may" below.

--Sean

, a warning will be shown that the keystore uses a proprietary format 
and migrating to PKCS12 is suggested. The keytool's -importkeystore 
command is also updated so that it can convert a keystore from one type 
to another if the source and destination point to the same file.?
> 
> Thanks
> Max
> 


From christoph.langer at sap.com  Fri Jul 14 15:37:00 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 14 Jul 2017 15:37:00 +0000
Subject: RFR 10 (XS): 8184673: Fix compatibility issue in AlgorithmChecker for
 3rd party JCE providers
Message-ID: <831770dccbc54a57a442413d77369688@sap.com>

Hi,

after the discussion in thread http://mail.openjdk.java.net/pipermail/security-dev/2017-July/016068.html, please review my proposed change:

Bug: https://bugs.openjdk.java.net/browse/JDK-8184673
Change:

diff -r 76fca9438ee9 -r 9c2438e0a823 src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java
--- a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java  Thu Jul 13 13:42:39 2017 +0200
+++ b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java  Fri Jul 14 17:35:36 2017 +0200
@@ -270,7 +270,7 @@

         AlgorithmParameters currSigAlgParams = algorithmId.getParameters();
         PublicKey currPubKey = cert.getPublicKey();
-        String currSigAlg = ((X509Certificate)cert).getSigAlgName();
+        currSigAlg = x509Cert.getSigAlgName();

         // Check the signature algorithm and parameters against constraints.
         if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg,


Thanks and best regards
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170714/c48b2eb4/attachment.htm>

From christoph.langer at sap.com  Fri Jul 14 15:44:03 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 14 Jul 2017 15:44:03 +0000
Subject: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
 party JCE provider
In-Reply-To: <f3b30092-d658-1f80-538b-8ad90e15bfbf@oracle.com>
References: <fa029b456fe842d29f13240091119208@sap.com>
 <18eade66502943fb95d8f88bc2b5cfb8@sap.com>
 <98649d03-a401-576c-970f-b780c9a692b9@oracle.com>
 <c257526cb6ba4fd3a7a636322dae06be@sap.com>
 <b0d9fa0e-e812-2c1e-ea59-09f9f8e082ff@oracle.com>
 <0f8409a6-6ae1-94da-0ca1-520d71a9d9e4@oracle.com>
 <f3b30092-d658-1f80-538b-8ad90e15bfbf@oracle.com>
Message-ID: <6079b4d6f6284650a73651faa3280d6b@sap.com>

Hi Sean(s), Tony,

I have created the bug https://bugs.openjdk.java.net/browse/JDK-8184673 and posted a change to revert the sigAlgName check. You had indicated that it should be ok to do this for JDK9 and 10 as well, so no behavioral change has to be documented.

If you give the ok, I would push it to JDK10 and I can also do the downport to jdk8u as well as jdk9u once it has opened. All the other backports you'll have to do yourself, e.g. for the Oracle JDKs and/or <8 and the upcoming update releases.

Thanks & Best regards
Christoph


> -----Original Message-----
> From: Se?n Coffey [mailto:sean.coffey at oracle.com]
> Sent: Freitag, 14. Juli 2017 12:17
> To: Anthony Scarpino <anthony.scarpino at oracle.com>; Sean Mullan
> <sean.mullan at oracle.com>; Langer, Christoph <christoph.langer at sap.com>
> Cc: OpenJDK Security <security-dev at openjdk.java.net>
> Subject: Re: [RFR] 8174849: Change SHA1 certpath restrictions - issue with 3rd
> party JCE provider
> 
> Tony,
> 
> I think we should log a JDK 8u bug for this issue if one doesn't already
> exist. If the buggy SigAlgName was allowed in 8u updates already, then
> it should be continued to be allowed for compatibility reasons IMO.
> There might be time to revert that change in 8u152.
> 
> For 9, then maybe we can document the minor behavioural change that'
> been introduced.
> 
> Regards,
> Sean.
> 
> On 14/07/17 05:25, Anthony Scarpino wrote:
> > On 07/12/2017 07:45 AM, Sean Mullan wrote:
> >> On 7/11/17 3:10 PM, Langer, Christoph wrote:
> >
> >>> 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?
> >>
> >> Yes, I agree.
> >>
> >> Also, note that you can probably also workaround this issue by adding
> >> a specific "SHA1/RSA" constraint to the
> >> jdk.certpath.disabledAlgorithms security property.
> >>
> >> --Sean
> >
> > The problem cannot be resolved by jdk.certpath.disabledAlgorithms.
> > Without using X509CertImpl, the non-standard "SHA1/RSA" is not
> > converted to "SHA1withRSA" The failing call is in the
> > SSLAlgorithConstraints.permit() checks by matching the algorithm name
> > with a list of standard supported algorithm names, and therefore fails.
> >
> > Tony
> >


From anthony.scarpino at oracle.com  Fri Jul 14 16:56:28 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 14 Jul 2017 09:56:28 -0700
Subject: RFR 10 (XS): 8184673: Fix compatibility issue in AlgorithmChecker
 for 3rd party JCE providers
In-Reply-To: <831770dccbc54a57a442413d77369688@sap.com>
References: <831770dccbc54a57a442413d77369688@sap.com>
Message-ID: <947c9d65-3baa-bbdc-b189-3a81ea611625@oracle.com>

On 07/14/2017 08:37 AM, Langer, Christoph wrote:
> Hi,
> 
> after the discussion in thread 
> http://mail.openjdk.java.net/pipermail/security-dev/2017-July/016068.html, 
> please review my proposed change:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8184673
> 
> Change:
> 
> *diff -r 76fca9438ee9 -r 9c2438e0a823 
> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java*
> 
> ---  a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java  
> Thu Jul 13 13:42:39 2017 +0200
> +++  b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java  
> Fri Jul 14 17:35:36 2017 +0200
> 
> @@ -270,7 +270,7 @@
> 
>           AlgorithmParameters currSigAlgParams = 
> algorithmId.getParameters();
> 
>          PublicKey currPubKey = cert.getPublicKey();
> -        String currSigAlg = ((X509Certificate)cert).getSigAlgName(); 
> +        currSigAlg = x509Cert.getSigAlgName();

I think you need to prepend with "String " to your change.

> 
>           // Check the signature algorithm and parameters against constraints.
> 
>           if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg,

Otherwise it looks fine.

Tony



From sean.mullan at oracle.com  Fri Jul 14 18:05:55 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 14 Jul 2017 14:05:55 -0400
Subject: RFR 10 (XS): 8184673: Fix compatibility issue in AlgorithmChecker
 for 3rd party JCE providers
In-Reply-To: <947c9d65-3baa-bbdc-b189-3a81ea611625@oracle.com>
References: <831770dccbc54a57a442413d77369688@sap.com>
 <947c9d65-3baa-bbdc-b189-3a81ea611625@oracle.com>
Message-ID: <ee6aef75-4b6d-2f02-5362-b1bd3d9ccddf@oracle.com>

It would be nice to write a regression test for this, but I suspect it 
is quite a bit of work or not practical. Please consider it, or add an 
appropriate noreg label to the bug.

--Sean

On 7/14/17 12:56 PM, Anthony Scarpino wrote:
> On 07/14/2017 08:37 AM, Langer, Christoph wrote:
>> Hi,
>>
>> after the discussion in thread 
>> http://mail.openjdk.java.net/pipermail/security-dev/2017-July/016068.html, 
>> please review my proposed change:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184673
>>
>> Change:
>>
>> *diff -r 76fca9438ee9 -r 9c2438e0a823 
>> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java* 
>>
>>
>> ---  
>> a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java 
>> Thu Jul 13 13:42:39 2017 +0200
>> +++  
>> b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java 
>> Fri Jul 14 17:35:36 2017 +0200
>>
>> @@ -270,7 +270,7 @@
>>
>>           AlgorithmParameters currSigAlgParams = 
>> algorithmId.getParameters();
>>
>>          PublicKey currPubKey = cert.getPublicKey();
>> -        String currSigAlg = ((X509Certificate)cert).getSigAlgName(); 
>> +        currSigAlg = x509Cert.getSigAlgName();
> 
> I think you need to prepend with "String " to your change.
> 
>>
>>           // Check the signature algorithm and parameters against 
>> constraints.
>>
>>           if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg,
> 
> Otherwise it looks fine.
> 
> Tony
> 


From anthony.scarpino at oracle.com  Fri Jul 14 18:49:41 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 14 Jul 2017 11:49:41 -0700
Subject: RFR 10 (XS): 8184673: Fix compatibility issue in AlgorithmChecker
 for 3rd party JCE providers
In-Reply-To: <ee6aef75-4b6d-2f02-5362-b1bd3d9ccddf@oracle.com>
References: <831770dccbc54a57a442413d77369688@sap.com>
 <947c9d65-3baa-bbdc-b189-3a81ea611625@oracle.com>
 <ee6aef75-4b6d-2f02-5362-b1bd3d9ccddf@oracle.com>
Message-ID: <35e90a13-82bc-878f-8833-0c93b293c7b9@oracle.com>

I'm working on a test so we avoid this in the future.

Tony

On 07/14/2017 11:05 AM, Sean Mullan wrote:
> It would be nice to write a regression test for this, but I suspect it 
> is quite a bit of work or not practical. Please consider it, or add an 
> appropriate noreg label to the bug.
> 
> --Sean
> 
> On 7/14/17 12:56 PM, Anthony Scarpino wrote:
>> On 07/14/2017 08:37 AM, Langer, Christoph wrote:
>>> Hi,
>>>
>>> after the discussion in thread 
>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-July/016068.html, 
>>> please review my proposed change:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8184673
>>>
>>> Change:
>>>
>>> *diff -r 76fca9438ee9 -r 9c2438e0a823 
>>> src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java* 
>>>
>>>
>>> --- 
>>> a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java 
>>> Thu Jul 13 13:42:39 2017 +0200
>>> +++ 
>>> b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java 
>>> Fri Jul 14 17:35:36 2017 +0200
>>>
>>> @@ -270,7 +270,7 @@
>>>
>>>           AlgorithmParameters currSigAlgParams = 
>>> algorithmId.getParameters();
>>>
>>>          PublicKey currPubKey = cert.getPublicKey();
>>> -        String currSigAlg = ((X509Certificate)cert).getSigAlgName(); 
>>> +        currSigAlg = x509Cert.getSigAlgName();
>>
>> I think you need to prepend with "String " to your change.
>>
>>>
>>>           // Check the signature algorithm and parameters against 
>>> constraints.
>>>
>>>           if (!constraints.permits(SIGNATURE_PRIMITIVE_SET, currSigAlg,
>>
>> Otherwise it looks fine.
>>
>> Tony
>>



From christoph.langer at sap.com  Fri Jul 14 18:56:35 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 14 Jul 2017 18:56:35 +0000
Subject: RFR 10 (XS): 8184673: Fix compatibility issue in AlgorithmChecker
 for 3rd party JCE providers
In-Reply-To: <947c9d65-3baa-bbdc-b189-3a81ea611625@oracle.com>
References: <831770dccbc54a57a442413d77369688@sap.com>
 <947c9d65-3baa-bbdc-b189-3a81ea611625@oracle.com>
Message-ID: <8a606e472be44062ad6c2a6d73c6d3f0@sap.com>

Hi Tony

> > ---
> a/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChe
> cker.java
> > Thu Jul 13 13:42:39 2017 +0200
> > +++
> b/src/java.base/share/classes/sun/security/provider/certpath/AlgorithmCh
> ecker.java
> > Fri Jul 14 17:35:36 2017 +0200
> >
> > @@ -270,7 +270,7 @@
> >
> >           AlgorithmParameters currSigAlgParams =
> > algorithmId.getParameters();
> >
> >          PublicKey currPubKey = cert.getPublicKey();
> > -        String currSigAlg = ((X509Certificate)cert).getSigAlgName();
> > +        currSigAlg = x509Cert.getSigAlgName();
> 
> I think you need to prepend with "String " to your change.

Yes, you are right. I had some debug code before which I just removed. I did not build the new version - which I would do before submit.


> Otherwise it looks fine.

Thanks
Christoph


From christoph.langer at sap.com  Fri Jul 14 19:01:08 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 14 Jul 2017 19:01:08 +0000
Subject: RFR 10 (XS): 8184673: Fix compatibility issue in AlgorithmChecker
 for 3rd party JCE providers
In-Reply-To: <35e90a13-82bc-878f-8833-0c93b293c7b9@oracle.com>
References: <831770dccbc54a57a442413d77369688@sap.com>
 <947c9d65-3baa-bbdc-b189-3a81ea611625@oracle.com>
 <ee6aef75-4b6d-2f02-5362-b1bd3d9ccddf@oracle.com>
 <35e90a13-82bc-878f-8833-0c93b293c7b9@oracle.com>
Message-ID: <9ace3be6c114493482064cebf93e9a52@sap.com>

Hi,

> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com]

> I'm working on a test so we avoid this in the future.

OK, so, shall I submit the fix and you do the test in a separate issue? Or shall I wait and let you do it altogether?

With my limited expertise in the security area, I would not have a better idea for a test than to ask iaik if we could use their binary. Or can you write a dummy provider or modify the sun provider in a certain way?

Thanks
Christoph



From sibabrata.sahoo at oracle.com  Sat Jul 15 10:30:25 2017
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Sat, 15 Jul 2017 03:30:25 -0700 (PDT)
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should
 clean up better
Message-ID: <89402164-f4b1-4e36-b894-2ad997efd409@default>

Hi,

 

Please review the patch for the following,

 

JBS: https://bugs.openjdk.java.net/browse/JDK-8183310

Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/

 

Change description:

The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file "java/security/modules/ModularTest.java".

 

SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files "TestClient.java" and "TestProvider.java" renamed and changed a little during clean up.

JaasModularClientTest.java - Verify JAAS login module in all possible modular combination.

JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed "TEST.properties" file.

 

Thanks,

Siba

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170715/9802d3ef/attachment.htm>

From valerie.peng at oracle.com  Sat Jul 15 21:07:53 2017
From: valerie.peng at oracle.com (Valerie Peng)
Date: Sat, 15 Jul 2017 14:07:53 -0700
Subject: RFR[10] JDK-8177017: com/oracle/security/ucrypto/TestAES.java
 fails intermittently
In-Reply-To: <28fb221d-3d1c-8e4b-415e-dfacba28dc98@oracle.com>
References: <28fb221d-3d1c-8e4b-415e-dfacba28dc98@oracle.com>
Message-ID: <ea064b02-10e2-0c71-47a9-a79e219aa069@oracle.com>

Hi John,

Sorry for the delay in reviewing this and thanks for the patience.

The changes look fine in general, however I feel that it may be 
worthwhile to put the Solaris version+distro checking/detection code 
into the general test base class, i.e. UcryptoTest, as a utility method. 
This way, other tests can also leverage the code to skip certain cases 
if needed.

Thanks,
Valerie

On 6/21/2017 7:40 PM, sha.jiang at oracle.com wrote:
> Hi,
> According to JDK-8173708, the cases on CFB128 in test 
> com/oracle/security/ucrypto/TestAES.java should be skipped on Solaris 
> 11.2 and previous versions due to a Solaris bug.
> Please review the patch at: 
> http://cr.openjdk.java.net/~jjiang/8177017/webrev.00/
>
> Best regards,
> John Jiang
>



From anthony.scarpino at oracle.com  Sun Jul 16 16:52:14 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Sun, 16 Jul 2017 09:52:14 -0700
Subject: RFR 10 (XS): 8184673: Fix compatibility issue in AlgorithmChecker
 for 3rd party JCE providers
In-Reply-To: <9ace3be6c114493482064cebf93e9a52@sap.com>
References: <831770dccbc54a57a442413d77369688@sap.com>
 <947c9d65-3baa-bbdc-b189-3a81ea611625@oracle.com>
 <ee6aef75-4b6d-2f02-5362-b1bd3d9ccddf@oracle.com>
 <35e90a13-82bc-878f-8833-0c93b293c7b9@oracle.com>
 <9ace3be6c114493482064cebf93e9a52@sap.com>
Message-ID: <4B2D25F5-532B-4A1E-A807-59FEDCBDCAAA@oracle.com>


> On Jul 14, 2017, at 12:01 PM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi,
> 
>> From: Anthony Scarpino [mailto:anthony.scarpino at oracle.com]
> 
>> I'm working on a test so we avoid this in the future.
> 
> OK, so, shall I submit the fix and you do the test in a separate issue? Or shall I wait and let you do it altogether?
> 
> With my limited expertise in the security area, I would not have a better idea for a test than to ask iaik if we could use their binary. Or can you write a dummy provider or modify the sun provider in a certain way?
> 
> Thanks
> Christoph
> 

The test will have to go back at a later time as a separate issue.

Tony



From sha.jiang at oracle.com  Mon Jul 17 12:25:27 2017
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 17 Jul 2017 20:25:27 +0800
Subject: RFR[10] JDK-8177017: com/oracle/security/ucrypto/TestAES.java
 fails intermittently
In-Reply-To: <ea064b02-10e2-0c71-47a9-a79e219aa069@oracle.com>
References: <28fb221d-3d1c-8e4b-415e-dfacba28dc98@oracle.com>
 <ea064b02-10e2-0c71-47a9-a79e219aa069@oracle.com>
Message-ID: <64040eb9-92da-4e7d-9c00-899a0542a412@oracle.com>

Hi Valerie,
Thanks for your comments!

Please review the updated webrev: 
http://cr.openjdk.java.net/~jjiang/8177017/webrev.01/
UcryptoTest has been extended by a set of tests. And the tests don't use 
ProcessTools, exactly, they don't declare /test/lib as library. If put 
distro() codes to the parent class, then all of such tests have to be 
modified. So, I just put the distro() method to  
/test/lib/jdk/test/lib/Utils.java.

Best regards,
John Jiang

On 16/07/2017 05:07, Valerie Peng wrote:
> Hi John,
>
> Sorry for the delay in reviewing this and thanks for the patience.
>
> The changes look fine in general, however I feel that it may be 
> worthwhile to put the Solaris version+distro checking/detection code 
> into the general test base class, i.e. UcryptoTest, as a utility 
> method. This way, other tests can also leverage the code to skip 
> certain cases if needed.
>
> Thanks,
> Valerie
>
> On 6/21/2017 7:40 PM, sha.jiang at oracle.com wrote:
>> Hi,
>> According to JDK-8173708, the cases on CFB128 in test 
>> com/oracle/security/ucrypto/TestAES.java should be skipped on Solaris 
>> 11.2 and previous versions due to a Solaris bug.
>> Please review the patch at: 
>> http://cr.openjdk.java.net/~jjiang/8177017/webrev.00/
>>
>> Best regards,
>> John Jiang
>>
>
>



From valerie.peng at oracle.com  Mon Jul 17 23:13:16 2017
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 17 Jul 2017 16:13:16 -0700
Subject: RFR[10] JDK-8177017: com/oracle/security/ucrypto/TestAES.java
 fails intermittently
In-Reply-To: <64040eb9-92da-4e7d-9c00-899a0542a412@oracle.com>
References: <28fb221d-3d1c-8e4b-415e-dfacba28dc98@oracle.com>
 <ea064b02-10e2-0c71-47a9-a79e219aa069@oracle.com>
 <64040eb9-92da-4e7d-9c00-899a0542a412@oracle.com>
Message-ID: <448c2c8b-8236-eb49-c87f-173ac6f2df16@oracle.com>


Updated changes look good.
Thanks,
Valerie

On 7/17/2017 5:25 AM, sha.jiang at oracle.com wrote:
> Hi Valerie,
> Thanks for your comments!
>
> Please review the updated webrev: 
> http://cr.openjdk.java.net/~jjiang/8177017/webrev.01/
> UcryptoTest has been extended by a set of tests. And the tests don't 
> use ProcessTools, exactly, they don't declare /test/lib as library. If 
> put distro() codes to the parent class, then all of such tests have to 
> be modified. So, I just put the distro() method to  
> /test/lib/jdk/test/lib/Utils.java.
>
> Best regards,
> John Jiang
>
> On 16/07/2017 05:07, Valerie Peng wrote:
>> Hi John,
>>
>> Sorry for the delay in reviewing this and thanks for the patience.
>>
>> The changes look fine in general, however I feel that it may be 
>> worthwhile to put the Solaris version+distro checking/detection code 
>> into the general test base class, i.e. UcryptoTest, as a utility 
>> method. This way, other tests can also leverage the code to skip 
>> certain cases if needed.
>>
>> Thanks,
>> Valerie
>>
>> On 6/21/2017 7:40 PM, sha.jiang at oracle.com wrote:
>>> Hi,
>>> According to JDK-8173708, the cases on CFB128 in test 
>>> com/oracle/security/ucrypto/TestAES.java should be skipped on 
>>> Solaris 11.2 and previous versions due to a Solaris bug.
>>> Please review the patch at: 
>>> http://cr.openjdk.java.net/~jjiang/8177017/webrev.00/
>>>
>>> Best regards,
>>> John Jiang
>>>
>>
>>
>



From mbalao at redhat.com  Tue Jul 18 17:12:49 2017
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 18 Jul 2017 14:12:49 -0300
Subject: Code review request: JDK-8046295 - Support Trusted CA Indication
 extension
In-Reply-To: <da2d4af3-147c-762a-31cc-ef6dfc606c63@oracle.com>
References: <CAKZz+geZcVrWGsXyqW2GWCrk3xW-5m9G=mjXPSq0pJFMLFUAwA@mail.gmail.com>
 <e0cbfcff-ff4e-3981-0aec-9cd4757c5833@oracle.com>
 <CAKZz+gdCt9BuiDcA5PETo_aOTM7M21MxDK=sVjLrJYYqOboegQ@mail.gmail.com>
 <eb89960d-5609-7ae5-5c9c-488d6810bdb7@oracle.com>
 <619b0a8b-5be7-1d29-6d8b-acf3cdc34a8c@oracle.com>
 <CAKZz+ge2LR5hQtBh4-bOqPWUTm6frBymj0qdiqr=4b0Zo+sKLg@mail.gmail.com>
 <66aaaaad-175b-89f9-ba18-254b7881b0d1@oracle.com>
 <CAKZz+gdCbub=5sDi=6s_e5uCxB=ESOCLDrN2MD1EX7f7YtnRJw@mail.gmail.com>
 <4d15dae7-e1a1-93ab-6b15-e95044c8f2f2@oracle.com>
 <CAKZz+gccLqEKd4f0tG51WVJVbWG_cGwZLCEUvMotK=zVvSqaSA@mail.gmail.com>
 <da2d4af3-147c-762a-31cc-ef6dfc606c63@oracle.com>
Message-ID: <CAKZz+gfmiwB7Nxb1Pd5t8FnShJHQF1s+wfL__547AP06hhuJ5g@mail.gmail.com>

Hi,

Given that 1) Trusted CA Indication TLS Extension does not appear to be
widely implemented today and 2) it will be replaced by Certificate
Authorities TLS extension in TLS 1.3, it looks more beneficial to me
supporting only the latter -and avoid paying the cost for a larger
code-base-.

Here it is my proposal for Certificate Authorities TLS extension:

 *
http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_07_18/8046295.webrev.03/
(browse online)
 *
http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_07_18/8046295.webrev.03.zip
(download)

Implementation based on TLS 1.3 - draft 20 [1]. Patch based on JDK-10 (rev
76ff72bb6a4a).

Pending / blocked (in descending priority order):

High

 * The extension applies only to TLSv1.3+
  * Blocked because TLSv1.3 is still not supported in JSSE.
  * Impact: the extension cannot be used in TLS 1.2 (high impact on the
client-side).
  * Action: replace "useTLS12PlusSpec" with "useTLS13PlusSpec" in the patch
when available.

Medium

 * Server can send the CertificateAuthorities extension to the client in a
CertificateRequest message (feature)
  * Blocked by: Server is still not able to send EncryptedExtensions
message in CertificateRequest
  * Impact: feature not supported on the server side. The extension can
still work in production environments. (medium).
  * Action: implement EncryptedExtensions message in CertificateRequest and
then implement this feature.

Low

 * Update documentation to refer the final TLS 1.3 RFC (draft 20 is
currently referred)
  * Blocked by: publication of the final TLS 1.3 RFC
  * Impact: documentation is not accurate. (low)
  * Action: replace "
https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4" with the
final link in the patch.

 * Update bug id in "CertificateAuthoritiesClientTest.java" and
"CertificateAuthoritiesServerTest.java"
  * Blocked by: there is no bug id for Certificate Authorities TLS extension
  * Impact: internal tests (very low).
  * Action: replace "@bug 8046295" with the new bug id in the patch. Open a
new bug id for Certificate Authorities TLS extension.

Look forward to your comments.

Kind regards,
Martin.-

--
[1] - https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4

On Tue, Jun 20, 2017 at 9:33 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:

> Hi Martin,
>
> The TLS 1.3 spec is replacing the Trusted CA Indication (trusted_ca_keys)
> extension with a new Certificate Authorities (certificate_authorities)
> extension.  See more details about the specification in the TLS 1.3 draft:
>     https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4
>
> Both serves a similar purpose, but the trusted_ca_keys extension will not
> be used in TLS 1.3 any more.  The "trusted_ca_keys" extension will only be
> used for legacy protocol versions (TLS 1.2/1.1/1.0).
>
> There are two options to me:
> 1. Supports the certificate_authorities, but not trusted_ca_keys extension.
> It is acceptable to me as trusted_ca_keys is for legacy use only and the
> certificate_authorities extension is the future.  Plus, the
> certificate_authorities extension can also be used for TLS 1.2 and previous
> versions.
>
> 2. Supports both the certificate_authorities and trusted_ca_keys
> extensions.
> As far as I know, I did not see much benefit of this option unless the
> trusted_ca_keys extension is widely used in practice.
>
> If I did not miss something, the APIs you designed can still be used for
> the certificate_authorities extension, with a little bit update.
>
> What do you think?
>
> Thanks & Regards,
> Xuelei
>
>
> On 6/15/2017 12:05 PM, Martin Balao wrote:
>
>> Hi Xuelei,
>>
>> The new webrev.02 is ready:
>>
>>   * http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste
>> d_ca/2017_06_15/8046295.webrev.02/ (browse online)
>>   * http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste
>> d_ca/2017_06_15/8046295.webrev.02.zip (zip, download)
>>
>> The following changes have been implemented since the previous webrev.01:
>>
>>   * s/getUseTrustedCAIndication() methods in SSLEngine/SSLSocket and in
>> SSLEngineImpl/SSLSocketImpl removed. s/getSSLParameters is now the only way
>> to set or get the use of the Trusted CA Indication extension. An exception
>> is no longer thrown if trying to disable the extension for a server, but
>> the change takes no effect as the extension is mandatory for servers.
>> X509KeyManagerImpl modified to use SSLParameters to get information
>> regarding if Trusted CA Indication is enabled and should guide the
>> certificate choice.
>>
>>   * TrustedAuthorityIndicator.IdentifierType has been moved from enum to
>> String, to follow JSSE conventions. I understand how important is to be
>> consistent. However, I still believe that an enum is a better fit for this
>> value and does not prevent from future extension. We are choosing from a
>> closed set (strictly defined by the RFC) and that's what enum allows to
>> express. From the client point of view/API, it's very handy that the type
>> gives you information regarding the allowed choices for the parameter. You
>> don't necessarily have to look for implementation details or documentation
>> but you can just leverage on the strongly typed language. It's also likely
>> that enums are faster for comparisons than strings, but that's not the main
>> point here.
>>
>>   * Removed X509Certificate from TrustedAuthorityIndicator class (method
>> and property). It was there for informational purposes (when
>> TrustedAuthorityIndicator was built from a certificate by a client and the
>> whole extension indicators converted to String).
>>
>>   * "equals" and "hashCode" methods moved from TrustedAuthorityIndicator
>> to TrustedAuthorityIndicatorImpl class.
>>
>>   * "getLength" method removed from TrustedAuthorityIndicator class. It's
>> possible to get the encoded buffer and the length from there.
>>
>>   * "getData" method renamed to "getEncoded" in TrustedAuthorityIndicator
>> class.
>>
>>   * "trustedAuthorityEncodedData" renamed to "encodedData" in
>> TrustedAuthorityIndicator and TrustedAuthorityIndicatorImpl classes
>>
>>   * "identifier" and "encodedData" instance variables moved from
>> TrustedAuthorityIndicator to TrustedAuthorityIndicatorImpl class.
>>
>>   * "getEncoded" and "getIdentifier" are now abstract methods in
>> TrustedAuthorityIndicator, and their implementation is in
>> TrustedAuthorityIndicatorImpl class.
>>
>>   * "getIdentifier" method renamed to "getType" in
>> TrustedAuthorityIndicator and TrustedAuthorityIndicatorImpl classes
>> ("identifier" instance variable and parameter in
>> TrustedAuthorityIndicatorImpl class renamed to "type").
>>
>>   * Test cases (server and client) updated to reflect the new interface
>> (enabling the use of the extension through SSLParameters)
>>
>> However, some changes are still not implemented and I have some concerns:
>>
>> 1) I still believe that identifier type information has to be on
>> TrustedAuthorityIndicator class somehow, and implementations restricted on
>> what they can return as part of "getType" method. This is strictly
>> specified by the RFC TrustedAuthorityIndicator class represents, and I find
>> desirable that any implementation is enforced to be compliant to that. If
>> we remove all of that (including the enum), TrustedAuthorityIndicator looks
>> too generic and does not reflect (in my opinion) what it really is. It'd
>> also be chaotic if different implementations call pre-agreed type as
>> "preagreed", "pre-agreed", "PRE_AGREED", etc. I prefer stricter and more
>> explicit interfaces.
>>
>> 2) I agree that type mappings can be seen as part of an implementation,
>> but they were in TrustedAuthorityIndicator (as protected) because every
>> implementation is highly likely to need them and we can avoid the necessity
>> for repeated code/mappings. The same for "type" and "encodedData" variables
>> or even "hashCode" and "equals" methods. That's why I was thinking more of
>> an abstract class and not an interface, as it happens (in example) with
>> SNIServerName.
>>
>> 3) I think that "implies" method on TrustedAuthorityIndicator should be
>> also part of the class/interface, because that's the whole point of a
>> Trusted Authority Information: to allow queries for a given certificate.
>> This is, in fact, the only thing a server wants from one of these objects.
>> My concern is that if we remove this requirement for an implementation, the
>> interface looks more like a byte buffer holder.
>>
>> I'd appreciate if you can re-consider these items.
>>
>> Thanks,
>> Martin.-
>>
>> On Wed, Jun 14, 2017 at 7:17 PM, Xuelei Fan <xuelei.fan at oracle.com
>> <mailto:xuelei.fan at oracle.com>> wrote:
>>
>>     Hi Martin,
>>
>>     The big picture of the design looks pretty good to me, except a few
>>     comment about the JSSE conventions.  I appreciate it very much.  By
>>     the way, I need more time to look into the details of the
>>     specification and implementation.
>>
>>
>>     In order to keep the APIs simple and small, SSLParameters is
>>     preferred as the only configuration port for common cases.   I may
>>     suggest to remove the s/getUseTrustedCAIndication() methods in
>>     SSLEngine/SSLSocket.
>>
>>     The identify type is defined as an enum
>>     TrustedAuthorityIndicator.IdentifierType.  In the future, if more
>>     type is added, we need to update the specification by adding a new
>>     enum item.  Enum is preferred in JDK, but for good extensibility, in
>>     general JSSE does not use enum in public APIs for extensible
>>     properties.  I may suggest to use String (or integer/byte, I prefer
>>     to use String) as the type.  The standard trusted authority
>>     indicator algorithm (identifier) can be documented in the "Java
>>     Cryptography Architecture Standard Algorithm Name Documentation"[1].
>>
>>     In TrustedAuthorityIndicator class, some methods, like
>>     getIdentifierTypeFromCode(), getCodeFromIdentifierType(), implies(),
>>     getLength(), equals() and hashCode() look more like implementation
>>     logic.  I may suggest remove them from public APIs.
>>
>>     I did not see the benefit to have X509Certificate in the
>>     TrustedAuthorityIndicator class.  The class is mainly used for
>>     server side certificate selection.  X509Certificate could be unknown
>>     for a indicator.  I may suggestion remove the related methods and
>>     properties.
>>
>>     After that, as there is no requirement to instantiate
>>     TrustedAuthorityIndicator class in application code, looks like it
>>     may be enough to use an interface to represent a trusted authorities:
>>         public interface TrustedAuthorityIndicator {
>>              // identifier type, standard algorithm name
>>              String/int/Byte getType();
>>
>>              // identifier
>>              byte[] getEncoded();
>>         }
>>
>>     What do you think?
>>
>>
>>     Thanks & Regards,
>>     Xuelei
>>
>>     [1]
>>     https://docs.oracle.com/javase/8/docs/technotes/guides/
>> security/StandardNames.html
>>     <https://docs.oracle.com/javase/8/docs/technotes/guides/
>> security/StandardNames.html>
>>
>>
>>     On 6/13/2017 3:41 PM, Martin Balao wrote:
>>
>>         Hi Xuelei,
>>
>>         The new webrev.01 is ready:
>>
>>            *
>>         http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste
>> d_ca/2017_06_13/8046295.webrev.01/
>>         <http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trust
>> ed_ca/2017_06_13/8046295.webrev.01/>
>>         (browse online)
>>            *
>>         http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste
>> d_ca/2017_06_13/8046295.webrev.01.zip
>>         <http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trust
>> ed_ca/2017_06_13/8046295.webrev.01.zip>
>>         (zip, download)
>>
>>         The following changes have been implemented since the previous
>>         webrev.00:
>>
>>            * Pre-agreed support removed from server-side
>>             * Unnecessary overhead and minium benefits for JSSE.
>>
>>            * Enabling the use of Trusted CA Indication extension for
>>         clients through TrustManager objects was reverted. Trusted CA
>>         Indication extension can now be enabled through: 1) SSLEngine,
>>         2) SSLSocket, or 3) SSLParameters (which can be applied to both
>>         SSLEngine and SSLSocket objects). Trusted CA Indication
>>         extension is mandatory for servers.
>>
>>            * SunX509KeyManagerImpl old key manager ("SunX509" algorithm)
>>         is now out of scope. This key manager does not support other TLS
>>         extensions as Server Name Indication (SNI), which is far more
>>         relevant than Trusted CA Indication. The new X509KeyManagerImpl
>>         key manager ("PKIX" algorithm) is now in scope.
>>
>>            * Client requested indications are now an ExtendedSSLSession
>>         attribute. ServerHandshaker gets the information from the Client
>>         Hello message (now parsed by TrustedCAIndicationExtension class
>>         instead of TrustedAuthorityIndicator) and sets it in the
>>         ExtendedSSLSession (SSLSessionImpl object). The key manager
>>         (i.e.: X509KeyManagerImpl), when choosing a server alias, may
>>         now get the information from the ExtendedSSLSession object and
>>         guide the certificate selection based on it.
>>             * In order to allow multiple key managers to use Trusted
>>         Authority Indicators information and to allow multiple Trusted
>>         Authority Indicators implementations, TrustedAuthorityIndicator
>>         has now been split in an abstract class
>>         (TrustedAuthorityIndicator, located in javax.net.ssl) and an
>>         implementation class (TrustedAuthorityIndicatorImpl, located in
>>         sun.security.ssl). No coupling was added between javax.net.ssl
>>         and sun.security.ssl packages.
>>
>>            * Documentation extended and improved.
>>            * Test cases (server and client) updated to reflect the new
>>         interface and supported key manager.
>>
>>         Look forward to your new review!
>>
>>         Kind regards,
>>         Martin.-
>>
>>
>>
>>         On Fri, Jun 9, 2017 at 6:15 PM, Xuelei Fan
>>         <xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>
>>         <mailto:xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>>>
>>         wrote:
>>
>>              I'm OK to use SSLParameters.  Thank you very much for
>>         considering a
>>              new design.
>>
>>              Xuelei
>>
>>              On 6/9/2017 1:10 PM, Martin Balao wrote:
>>
>>                  Hi Xuelei,
>>
>>                  I didn't notice that some of the SSLSocket contructors
>>         did not
>>                  establish the connection, so SSLParameters can be
>>         effective for
>>                  Trusted CA Indication. This was an invalid argument on
>>         my side,
>>                  sorry.
>>
>>                  As for the configuration to enable the extension, it's
>>         probably
>>                  not necessary on the Server side because -as you
>>         mentioned- it
>>                  is mandatory and there is no harm in supporting it.
>>         However, it
>>                  has to be configurable on the Client side because -as we
>>                  previously discussed- the client may cause a handshake
>>         failure
>>                  if the server does not support the extension. I'd
>>         prefer the
>>                  Client configuring the SSLSocket through SSLParameters
>>         instead
>>                  of a system-wide property -which has even more impact
>>         than the
>>                  TrustManager approach-. Would this work for you?
>>
>>                    > In JSSE, the benefits pre_agreed option can get by
>>                  customizing the key/trust manager, so I did not see too
>>         much
>>                  benefits to support this option in JDK
>>
>>                  I understand your point and will remove support for
>>         "pre_agreed".
>>
>>
>>                  On Fri, Jun 9, 2017 at 1:37 AM, Xuelei Fan
>>                  <xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>
>>         <mailto:xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>>
>>                  <mailto:xuelei.fan at oracle.com
>>         <mailto:xuelei.fan at oracle.com> <mailto:xuelei.fan at oracle.com
>>         <mailto:xuelei.fan at oracle.com>>>>
>>                  wrote:
>>
>>
>>
>>                       On 6/8/2017 8:36 PM, Xuelei Fan wrote:
>>
>>                           The trusted authorities can be get from client
>>         trust
>>                  manager.         Server can choose the best matching of
>>         server
>>                  certificate of the
>>                           client requested trusted authorities.
>>
>>                       >
>>                       I missed the point that the key manager need to
>>         know the client
>>                       requested trusted authorities for the choosing.
>>      So may
>>                  need a new
>>                       SSLSession attribute (See similar method in
>>                  ExtendedSSLSession).
>>
>>                       Xuelei
>>
>>
>>
>>                  Yes, an attribute on SSLSession may do the job (both
>>         when Key
>>                  Manager receives a SSLSocket and a SSLEngine).
>>
>>                  Kind regards,
>>                  Martin.-
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170718/d87517c8/attachment.htm>

From adam.petcher at oracle.com  Tue Jul 18 17:55:05 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Tue, 18 Jul 2017 13:55:05 -0400
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
In-Reply-To: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>
References: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>
Message-ID: <56293781-cbd8-f861-3c81-414672debfc2@oracle.com>

Some additional investigation revealed that IOUtils.readFully() is only 
used by DER, JKS, and Kerberos. None of these need the "read to the end 
of the buffer" feature. This behavior of readFully() is confusing, so it 
is probably best to remove it.

Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.01/


On 7/12/2017 2:38 PM, Adam Petcher wrote:
> This is a bug fix for a corner case in which a DER value has length 
> equal to Integer.MAX_VALUE. The code uses IOUtils.readFully() to read 
> the value, which interprets length=Integer.MAX_VALUE to mean "read to 
> the end." The result is that no exception will be thrown when fewer 
> then Integer.MAX_VALUE bytes are read from the stream. The fix adds a 
> check after the readFully() to ensure that the expected number of 
> bytes were read.
>
> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8183591
>



From Alan.Bateman at oracle.com  Wed Jul 19 11:44:38 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 19 Jul 2017 12:44:38 +0100
Subject: 8184916: DisabledAlgorithmConstraints loading should be delayed until
 needed
Message-ID: <ec6230f6-dfce-35e7-9258-fb7f7243dae9@oracle.com>

I'm looking at the performance of an app that initializes a lot more 
security classes than I expected. One part to this is the initial 
opening of a JAR file which ends up loading a lot of machinery that 
should only be needed with signed JARs.

Any objection if I change SignatureFileVerifier to initialize 
DisabledAlgorithmConstraints lazily? The proposed patch for jdk10/jdk10 
is below.

Thanks,

-Alan


diff --git 
a/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java 
b/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
--- 
a/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
+++ 
b/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
@@ -59,9 +59,15 @@
      /* Are we debugging ? */
      private static final Debug debug = Debug.getInstance("jar");

-    private static final DisabledAlgorithmConstraints JAR_DISABLED_CHECK =
+    /**
+     * Holder class to delay initialization of DisabledAlgorithmConstraints
+     * until needed.
+     */
+    private static class ConfigurationHolder {
+        static final DisabledAlgorithmConstraints JAR_DISABLED_CHECK =
              new DisabledAlgorithmConstraints(
DisabledAlgorithmConstraints.PROPERTY_JAR_DISABLED_ALGS);
+    }

      private ArrayList<CodeSigner[]> signerCache;

@@ -371,7 +377,7 @@
          Boolean permitted = permittedAlgs.get(algorithm);
          if (permitted == null) {
              try {
-                JAR_DISABLED_CHECK.permits(algorithm,
+ ConfigurationHolder.JAR_DISABLED_CHECK.permits(algorithm,
                          new ConstraintsParameters(timestamp));
              } catch(GeneralSecurityException e) {
                  permittedAlgs.put(algorithm, Boolean.FALSE);



From ecki at zusammenkunft.net  Wed Jul 19 12:01:02 2017
From: ecki at zusammenkunft.net (Bernd)
Date: Wed, 19 Jul 2017 14:01:02 +0200
Subject: jar verification regression Oracle 8u141
Message-ID: <CABOR3+ymNVMXzKqwtbhbxv23VdhSnWa04DQyAaT3f2s_eYdZhg@mail.gmail.com>

Hello,

after upgrading Java Web Start to 8u141 an application fails to start with
a JAR verification error:

com.sun.deploy.net.JARSigningException: Signatur konnte nicht verifiziert
werden in Ressource:
http://localhost:10000/seeburger/app/commons-httpclient.jar
    at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown
Source)
    at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
    at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
    at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
    at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
    at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
    at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
    at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
    at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
    at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

java.lang.SecurityException: digest missing for
org/apache/commons/httpclient
    at
sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:202)
    at java.util.jar.JarVerifier.processEntry(JarVerifier.java:243)
    at java.util.jar.JarVerifier.update(JarVerifier.java:211)
    at java.util.jar.JarVerifier$VerifierStream.<init>(JarVerifier.java:457)
    at java.util.jar.JarFile.getInputStream(JarFile.java:464)
    at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown
Source)
    at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)


If I use jarsigner -verify (from 8u141) on that file it does not show a
problem. The file also worked with 8u131.

We signed that file ourself and I am not sure when the broken entry is
generated, it looks like:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Built-By: oleg
Maven-Version: 1.1
Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)

Name: org/apache/commons/httpclient/Header.class
SHA-256-Digest: 5HHGzly6O0szGtB9rGU+bY2PXW54N9EmRkoz9g5QFEQ=
...
Name: org/apache/commons/httpclient/methods/multipart/PartSource.class
SHA-256-Digest: mk7TML731ZpUoSypwlvr2qtT67lwUgxl7FwSZ+/6B6s=

Name: org/apache/commons/httpclient
Implementation-Title: org.apache.commons.httpclient
Implementation-Version: 3.1
X-Compile-Target-JDK: 1.2
Specification-Vendor: Apache Software Foundation
Specification-Title: Jakarta Commons HttpClient
Implementation-Vendor-Id: org.apache
Extension-name: org.apache.commons.httpclient
X-Compile-Source-JDK: 1.2
Specification-Version: 3.1
Implementation-Vendor: Apache Software Foundation

Name: org/apache/commons/httpclient/methods/multipart/FilePart.class
SHA-256-Digest: uCUbczb7+sVYzJ+pxl+I6Qk3SBS6xeztmAOJvuUzmsM=
...

This structure is created by JAR signer becaue the original apache artifact
manifest looks like this:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)
Built-By: oleg
Maven-Version: 1.1

Name: org/apache/commons/httpclient
Extension-name: org.apache.commons.httpclient
Specification-Title: Jakarta Commons HttpClient
Specification-Vendor: Apache Software Foundation
Specification-Version: 3.1
Implementation-Title: org.apache.commons.httpclient
Implementation-Vendor: Apache Software Foundation
Implementation-Version: 3.1
Implementation-Vendor-Id: org.apache
X-Compile-Source-JDK: 1.2
X-Compile-Target-JDK: 1.2

I think different jarsigner versions behave differently, some remove that
section.

jarsigner -verify should be as strict as JWS. JWS should probalbly ignroe
sections like that like before.

Gruss
Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170719/07d88529/attachment.htm>

From reto.merz at abacus.ch  Wed Jul 19 15:01:29 2017
From: reto.merz at abacus.ch (Reto Merz)
Date: Wed, 19 Jul 2017 17:01:29 +0200
Subject: jar verification regression Oracle 8u141
Message-ID: <2062adbd-3c50-413d-a1fe-7c9a421435fe@abacus.ch>

Our webstart app is also killed by this issue.
 
Tested with:
Java u141 b15 (FAIL)
Java u141 b32 (FAIL)
Java u131 b11 (OK)
 
Regards
Reto
 
 
Von: security-dev [mailto:security-dev-bounces at openjdk.java.net] Im Auftrag von Bernd
Gesendet: Mittwoch, 19. Juli 2017 14:01
An: security-dev at openjdk.java.net
Betreff: jar verification regression Oracle 8u141
 
Hello,
after upgrading Java Web Start to 8u141 an application fails to start with a JAR verification error:

com.sun.deploy.net.JARSigningException: Signatur konnte nicht verifiziert werden in Ressource: http://localhost:10000/seeburger/app/commons-httpclient.jar
    at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
    at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
    at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
    at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
    at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
    at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
    at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
    at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
    at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
    at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

java.lang.SecurityException: digest missing for org/apache/commons/httpclient
    at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:202)
    at java.util.jar.JarVerifier.processEntry(JarVerifier.java:243)
    at java.util.jar.JarVerifier.update(JarVerifier.java:211)
    at java.util.jar.JarVerifier$VerifierStream.<init>(JarVerifier.java:457)
    at java.util.jar.JarFile.getInputStream(JarFile.java:464)
    at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
    at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)

If I use jarsigner -verify (from 8u141) on that file it does not show a problem. The file also worked with 8u131.
We signed that file ourself and I am not sure when the broken entry is generated, it looks like:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Built-By: oleg
Maven-Version: 1.1
Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)

Name: org/apache/commons/httpclient/Header.class
SHA-256-Digest: 5HHGzly6O0szGtB9rGU+bY2PXW54N9EmRkoz9g5QFEQ=
...
Name: org/apache/commons/httpclient/methods/multipart/PartSource.class
SHA-256-Digest: mk7TML731ZpUoSypwlvr2qtT67lwUgxl7FwSZ+/6B6s=

Name: org/apache/commons/httpclient
Implementation-Title: org.apache.commons.httpclient
Implementation-Version: 3.1
X-Compile-Target-JDK: 1.2
Specification-Vendor: Apache Software Foundation
Specification-Title: Jakarta Commons HttpClient
Implementation-Vendor-Id: org.apache
Extension-name: org.apache.commons.httpclient
X-Compile-Source-JDK: 1.2
Specification-Version: 3.1
Implementation-Vendor: Apache Software Foundation

Name: org/apache/commons/httpclient/methods/multipart/FilePart.class
SHA-256-Digest: uCUbczb7+sVYzJ+pxl+I6Qk3SBS6xeztmAOJvuUzmsM=
...
This structure is created by JAR signer becaue the original apache artifact manifest looks like this:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_11-b03 (Sun Microsystems Inc.)
Built-By: oleg
Maven-Version: 1.1

Name: org/apache/commons/httpclient
Extension-name: org.apache.commons.httpclient
Specification-Title: Jakarta Commons HttpClient
Specification-Vendor: Apache Software Foundation
Specification-Version: 3.1
Implementation-Title: org.apache.commons.httpclient
Implementation-Vendor: Apache Software Foundation
Implementation-Version: 3.1
Implementation-Vendor-Id: org.apache
X-Compile-Source-JDK: 1.2
X-Compile-Target-JDK: 1.2
I think different jarsigner versions behave differently, some remove that section.
jarsigner -verify should be as strict as JWS. JWS should probalbly ignroe sections like that like before.
 
Gruss
Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170719/78bd3768/attachment.htm>

From ecki at zusammenkunft.net  Wed Jul 19 15:15:35 2017
From: ecki at zusammenkunft.net (Bernd)
Date: Wed, 19 Jul 2017 17:15:35 +0200
Subject: jar verification regression Oracle 8u141
In-Reply-To: <CABOR3+ymNVMXzKqwtbhbxv23VdhSnWa04DQyAaT3f2s_eYdZhg@mail.gmail.com>
References: <CABOR3+ymNVMXzKqwtbhbxv23VdhSnWa04DQyAaT3f2s_eYdZhg@mail.gmail.com>
Message-ID: <CABOR3+xbH8_JW4dw8zXkF6Dz=p1oY663Yt8wkb5991F_9OXbhQ@mail.gmail.com>

Hello,

one more thing:

2017-07-19 14:01 GMT+02:00 Bernd <ecki at zusammenkunft.net>:

> I think different jarsigner versions behave differently, some remove that
> section.
>

It is actually not "different jarsigner versions", but we have our own jar
signer implementation (used for self signed test certificates in the build
pipeline). This implementation removes the whole name: section. When using
jarsigner.exe on our sign server on the other hand, it produces the named
section with no digest, which causes JWS to break,

Gruss
Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170719/e221ed25/attachment.htm>

From sean.mullan at oracle.com  Wed Jul 19 15:17:41 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 19 Jul 2017 11:17:41 -0400
Subject: 8184916: DisabledAlgorithmConstraints loading should be delayed
 until needed
In-Reply-To: <ec6230f6-dfce-35e7-9258-fb7f7243dae9@oracle.com>
References: <ec6230f6-dfce-35e7-9258-fb7f7243dae9@oracle.com>
Message-ID: <9d4f47f7-1888-7a3a-c846-f70d9453004d@oracle.com>

No objection. Looks fine to me.

--Sean

On 7/19/17 7:44 AM, Alan Bateman wrote:
> I'm looking at the performance of an app that initializes a lot more 
> security classes than I expected. One part to this is the initial 
> opening of a JAR file which ends up loading a lot of machinery that 
> should only be needed with signed JARs.
> 
> Any objection if I change SignatureFileVerifier to initialize 
> DisabledAlgorithmConstraints lazily? The proposed patch for jdk10/jdk10 
> is below.
> 
> Thanks,
> 
> -Alan
> 
> 
> diff --git 
> a/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java 
> b/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
> --- 
> a/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
> +++ 
> b/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
> @@ -59,9 +59,15 @@
>       /* Are we debugging ? */
>       private static final Debug debug = Debug.getInstance("jar");
> 
> -    private static final DisabledAlgorithmConstraints JAR_DISABLED_CHECK =
> +    /**
> +     * Holder class to delay initialization of 
> DisabledAlgorithmConstraints
> +     * until needed.
> +     */
> +    private static class ConfigurationHolder {
> +        static final DisabledAlgorithmConstraints JAR_DISABLED_CHECK =
>               new DisabledAlgorithmConstraints(
> DisabledAlgorithmConstraints.PROPERTY_JAR_DISABLED_ALGS);
> +    }
> 
>       private ArrayList<CodeSigner[]> signerCache;
> 
> @@ -371,7 +377,7 @@
>           Boolean permitted = permittedAlgs.get(algorithm);
>           if (permitted == null) {
>               try {
> -                JAR_DISABLED_CHECK.permits(algorithm,
> + ConfigurationHolder.JAR_DISABLED_CHECK.permits(algorithm,
>                           new ConstraintsParameters(timestamp));
>               } catch(GeneralSecurityException e) {
>                   permittedAlgs.put(algorithm, Boolean.FALSE);
> 


From adam.petcher at oracle.com  Thu Jul 20 13:49:28 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Thu, 20 Jul 2017 09:49:28 -0400
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
In-Reply-To: <56293781-cbd8-f861-3c81-414672debfc2@oracle.com>
References: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>
 <56293781-cbd8-f861-3c81-414672debfc2@oracle.com>
Message-ID: <4d37a33c-bb8f-5c1f-ca13-c674080b1820@oracle.com>

Oops. Better to throw an IOException when a negative length is given to 
readFully.

Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.02/


On 7/18/2017 1:55 PM, Adam Petcher wrote:
> Some additional investigation revealed that IOUtils.readFully() is 
> only used by DER, JKS, and Kerberos. None of these need the "read to 
> the end of the buffer" feature. This behavior of readFully() is 
> confusing, so it is probably best to remove it.
>
> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.01/
>
>
> On 7/12/2017 2:38 PM, Adam Petcher wrote:
>> This is a bug fix for a corner case in which a DER value has length 
>> equal to Integer.MAX_VALUE. The code uses IOUtils.readFully() to read 
>> the value, which interprets length=Integer.MAX_VALUE to mean "read to 
>> the end." The result is that no exception will be thrown when fewer 
>> then Integer.MAX_VALUE bytes are read from the stream. The fix adds a 
>> check after the readFully() to ensure that the expected number of 
>> bytes were read.
>>
>> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183591
>>
>



From ecki at zusammenkunft.net  Thu Jul 20 17:32:19 2017
From: ecki at zusammenkunft.net (Bernd)
Date: Thu, 20 Jul 2017 19:32:19 +0200
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
Message-ID: <CABOR3+z6pY=FjBSi=3o58_kK+T002Ph7p5tTT=xsSt-7Ck0-jQ@mail.gmail.com>

Why not make a different utility method for this case.

 readRemaining() vs. readFully(int)

The name makes not much sense and the code does not get easier if both
cases are in one method for no good reason.

And I wonder if allocating a MAXINTEGER buffer from untrusted source is a
good idea.

Gruss
Bernd

2017-07-20 15:49 GMT+02:00 Adam Petcher <adam.petcher at oracle.com>:

> Oops. Better to throw an IOException when a negative length is given to
> readFully.
>
> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.02/
>
>
>
> On 7/18/2017 1:55 PM, Adam Petcher wrote:
>
>> Some additional investigation revealed that IOUtils.readFully() is only
>> used by DER, JKS, and Kerberos. None of these need the "read to the end of
>> the buffer" feature. This behavior of readFully() is confusing, so it is
>> probably best to remove it.
>>
>> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.01/
>>
>>
>> On 7/12/2017 2:38 PM, Adam Petcher wrote:
>>
>>> This is a bug fix for a corner case in which a DER value has length
>>> equal to Integer.MAX_VALUE. The code uses IOUtils.readFully() to read the
>>> value, which interprets length=Integer.MAX_VALUE to mean "read to the end."
>>> The result is that no exception will be thrown when fewer then
>>> Integer.MAX_VALUE bytes are read from the stream. The fix adds a check
>>> after the readFully() to ensure that the expected number of bytes were read.
>>>
>>> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183591
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170720/4ae38104/attachment.htm>

From adam.petcher at oracle.com  Thu Jul 20 18:29:54 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Thu, 20 Jul 2017 14:29:54 -0400
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
In-Reply-To: <CABOR3+z6pY=FjBSi=3o58_kK+T002Ph7p5tTT=xsSt-7Ck0-jQ@mail.gmail.com>
References: <CABOR3+z6pY=FjBSi=3o58_kK+T002Ph7p5tTT=xsSt-7Ck0-jQ@mail.gmail.com>
Message-ID: <5b33e560-cbb4-e263-c6c6-c275cac15dc1@oracle.com>

On 7/20/2017 1:32 PM, Bernd wrote:

> Why not make a different utility method for this case.
>
>  readRemaining() vs. readFully(int)
>
> The name makes not much sense and the code does not get easier if both 
> cases are in one method for no good reason.

I agree, but the method that takes a length argument is the only one 
that is needed at the moment. We can add another method later if it is 
needed. Are you saying there is something wrong with the readFully(int) 
method in my last webrev?

>
> And I wonder if allocating a MAXINTEGER buffer from untrusted source 
> is a good idea.

This method will only allocate a large buffer if the untrusted source 
actually sent a large amount of bytes.

>
> Gruss
> Bernd
>
> 2017-07-20 15:49 GMT+02:00 Adam Petcher <adam.petcher at oracle.com 
> <mailto:adam.petcher at oracle.com>>:
>
>     Oops. Better to throw an IOException when a negative length is
>     given to readFully.
>
>     Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.02/
>     <http://cr.openjdk.java.net/%7Eapetcher/8183591/webrev.02/>
>
>
>
>     On 7/18/2017 1:55 PM, Adam Petcher wrote:
>
>         Some additional investigation revealed that
>         IOUtils.readFully() is only used by DER, JKS, and Kerberos.
>         None of these need the "read to the end of the buffer"
>         feature. This behavior of readFully() is confusing, so it is
>         probably best to remove it.
>
>         Webrev:
>         http://cr.openjdk.java.net/~apetcher/8183591/webrev.01/
>         <http://cr.openjdk.java.net/%7Eapetcher/8183591/webrev.01/>
>
>
>         On 7/12/2017 2:38 PM, Adam Petcher wrote:
>
>             This is a bug fix for a corner case in which a DER value
>             has length equal to Integer.MAX_VALUE. The code uses
>             IOUtils.readFully() to read the value, which interprets
>             length=Integer.MAX_VALUE to mean "read to the end." The
>             result is that no exception will be thrown when fewer then
>             Integer.MAX_VALUE bytes are read from the stream. The fix
>             adds a check after the readFully() to ensure that the
>             expected number of bytes were read.
>
>             Webrev:
>             http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/
>             <http://cr.openjdk.java.net/%7Eapetcher/8183591/webrev.00/>
>             JBS: https://bugs.openjdk.java.net/browse/JDK-8183591
>             <https://bugs.openjdk.java.net/browse/JDK-8183591>
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170720/1bd3165f/attachment.htm>

From sean.mullan at oracle.com  Thu Jul 20 19:32:16 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 20 Jul 2017 15:32:16 -0400
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
In-Reply-To: <4d37a33c-bb8f-5c1f-ca13-c674080b1820@oracle.com>
References: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>
 <56293781-cbd8-f861-3c81-414672debfc2@oracle.com>
 <4d37a33c-bb8f-5c1f-ca13-c674080b1820@oracle.com>
Message-ID: <4a71e1cb-ae6f-c960-0959-7f6bf8f88dd9@oracle.com>

Looks good to me.

--Sean

On 7/20/17 9:49 AM, Adam Petcher wrote:
> Oops. Better to throw an IOException when a negative length is given to 
> readFully.
> 
> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.02/
> 
> 
> On 7/18/2017 1:55 PM, Adam Petcher wrote:
>> Some additional investigation revealed that IOUtils.readFully() is 
>> only used by DER, JKS, and Kerberos. None of these need the "read to 
>> the end of the buffer" feature. This behavior of readFully() is 
>> confusing, so it is probably best to remove it.
>>
>> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.01/
>>
>>
>> On 7/12/2017 2:38 PM, Adam Petcher wrote:
>>> This is a bug fix for a corner case in which a DER value has length 
>>> equal to Integer.MAX_VALUE. The code uses IOUtils.readFully() to read 
>>> the value, which interprets length=Integer.MAX_VALUE to mean "read to 
>>> the end." The result is that no exception will be thrown when fewer 
>>> then Integer.MAX_VALUE bytes are read from the stream. The fix adds a 
>>> check after the readFully() to ensure that the expected number of 
>>> bytes were read.
>>>
>>> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183591
>>>
>>
> 


From mbalao at redhat.com  Fri Jul 21 14:20:56 2017
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 21 Jul 2017 11:20:56 -0300
Subject: Code review request: JDK-8046295 - Support Trusted CA Indication
 extension
In-Reply-To: <CAKZz+gfmiwB7Nxb1Pd5t8FnShJHQF1s+wfL__547AP06hhuJ5g@mail.gmail.com>
References: <CAKZz+geZcVrWGsXyqW2GWCrk3xW-5m9G=mjXPSq0pJFMLFUAwA@mail.gmail.com>
 <e0cbfcff-ff4e-3981-0aec-9cd4757c5833@oracle.com>
 <CAKZz+gdCt9BuiDcA5PETo_aOTM7M21MxDK=sVjLrJYYqOboegQ@mail.gmail.com>
 <eb89960d-5609-7ae5-5c9c-488d6810bdb7@oracle.com>
 <619b0a8b-5be7-1d29-6d8b-acf3cdc34a8c@oracle.com>
 <CAKZz+ge2LR5hQtBh4-bOqPWUTm6frBymj0qdiqr=4b0Zo+sKLg@mail.gmail.com>
 <66aaaaad-175b-89f9-ba18-254b7881b0d1@oracle.com>
 <CAKZz+gdCbub=5sDi=6s_e5uCxB=ESOCLDrN2MD1EX7f7YtnRJw@mail.gmail.com>
 <4d15dae7-e1a1-93ab-6b15-e95044c8f2f2@oracle.com>
 <CAKZz+gccLqEKd4f0tG51WVJVbWG_cGwZLCEUvMotK=zVvSqaSA@mail.gmail.com>
 <da2d4af3-147c-762a-31cc-ef6dfc606c63@oracle.com>
 <CAKZz+gfmiwB7Nxb1Pd5t8FnShJHQF1s+wfL__547AP06hhuJ5g@mail.gmail.com>
Message-ID: <CAKZz+gdK2Trs04gm_k_PYY8rB8r_L=Fb+eTjg23_Yggna68SFQ@mail.gmail.com>

Webrev has been uploaded to cr.openjdk.java.net:

 *
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/
 *
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/8046295.webrev.03.zip

Kind regards,
Martin.-

On Tue, Jul 18, 2017 at 2:12 PM, Martin Balao <mbalao at redhat.com> wrote:

> Hi,
>
> Given that 1) Trusted CA Indication TLS Extension does not appear to be
> widely implemented today and 2) it will be replaced by Certificate
> Authorities TLS extension in TLS 1.3, it looks more beneficial to me
> supporting only the latter -and avoid paying the cost for a larger
> code-base-.
>
> Here it is my proposal for Certificate Authorities TLS extension:
>
>  * http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_
> trusted_ca/2017_07_18/8046295.webrev.03/ (browse online)
>  * http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_
> trusted_ca/2017_07_18/8046295.webrev.03.zip (download)
>
> Implementation based on TLS 1.3 - draft 20 [1]. Patch based on JDK-10 (rev
> 76ff72bb6a4a).
>
> Pending / blocked (in descending priority order):
>
> High
>
>  * The extension applies only to TLSv1.3+
>   * Blocked because TLSv1.3 is still not supported in JSSE.
>   * Impact: the extension cannot be used in TLS 1.2 (high impact on the
> client-side).
>   * Action: replace "useTLS12PlusSpec" with "useTLS13PlusSpec" in the
> patch when available.
>
> Medium
>
>  * Server can send the CertificateAuthorities extension to the client in a
> CertificateRequest message (feature)
>   * Blocked by: Server is still not able to send EncryptedExtensions
> message in CertificateRequest
>   * Impact: feature not supported on the server side. The extension can
> still work in production environments. (medium).
>   * Action: implement EncryptedExtensions message in CertificateRequest
> and then implement this feature.
>
> Low
>
>  * Update documentation to refer the final TLS 1.3 RFC (draft 20 is
> currently referred)
>   * Blocked by: publication of the final TLS 1.3 RFC
>   * Impact: documentation is not accurate. (low)
>   * Action: replace "https://tools.ietf.org/html/draft-ietf-tls-tls13-20#
> section-4.2.4" with the final link in the patch.
>
>  * Update bug id in "CertificateAuthoritiesClientTest.java" and "
> CertificateAuthoritiesServerTest.java"
>   * Blocked by: there is no bug id for Certificate Authorities TLS
> extension
>   * Impact: internal tests (very low).
>   * Action: replace "@bug 8046295" with the new bug id in the patch. Open
> a new bug id for Certificate Authorities TLS extension.
>
> Look forward to your comments.
>
> Kind regards,
> Martin.-
>
> --
> [1] - https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4
>
> On Tue, Jun 20, 2017 at 9:33 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>
>> Hi Martin,
>>
>> The TLS 1.3 spec is replacing the Trusted CA Indication (trusted_ca_keys)
>> extension with a new Certificate Authorities (certificate_authorities)
>> extension.  See more details about the specification in the TLS 1.3 draft:
>>     https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4
>>
>> Both serves a similar purpose, but the trusted_ca_keys extension will not
>> be used in TLS 1.3 any more.  The "trusted_ca_keys" extension will only be
>> used for legacy protocol versions (TLS 1.2/1.1/1.0).
>>
>> There are two options to me:
>> 1. Supports the certificate_authorities, but not trusted_ca_keys
>> extension.
>> It is acceptable to me as trusted_ca_keys is for legacy use only and the
>> certificate_authorities extension is the future.  Plus, the
>> certificate_authorities extension can also be used for TLS 1.2 and previous
>> versions.
>>
>> 2. Supports both the certificate_authorities and trusted_ca_keys
>> extensions.
>> As far as I know, I did not see much benefit of this option unless the
>> trusted_ca_keys extension is widely used in practice.
>>
>> If I did not miss something, the APIs you designed can still be used for
>> the certificate_authorities extension, with a little bit update.
>>
>> What do you think?
>>
>> Thanks & Regards,
>> Xuelei
>>
>>
>> On 6/15/2017 12:05 PM, Martin Balao wrote:
>>
>>> Hi Xuelei,
>>>
>>> The new webrev.02 is ready:
>>>
>>>   * http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste
>>> d_ca/2017_06_15/8046295.webrev.02/ (browse online)
>>>   * http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste
>>> d_ca/2017_06_15/8046295.webrev.02.zip (zip, download)
>>>
>>> The following changes have been implemented since the previous webrev.01:
>>>
>>>   * s/getUseTrustedCAIndication() methods in SSLEngine/SSLSocket and in
>>> SSLEngineImpl/SSLSocketImpl removed. s/getSSLParameters is now the only way
>>> to set or get the use of the Trusted CA Indication extension. An exception
>>> is no longer thrown if trying to disable the extension for a server, but
>>> the change takes no effect as the extension is mandatory for servers.
>>> X509KeyManagerImpl modified to use SSLParameters to get information
>>> regarding if Trusted CA Indication is enabled and should guide the
>>> certificate choice.
>>>
>>>   * TrustedAuthorityIndicator.IdentifierType has been moved from enum
>>> to String, to follow JSSE conventions. I understand how important is to be
>>> consistent. However, I still believe that an enum is a better fit for this
>>> value and does not prevent from future extension. We are choosing from a
>>> closed set (strictly defined by the RFC) and that's what enum allows to
>>> express. From the client point of view/API, it's very handy that the type
>>> gives you information regarding the allowed choices for the parameter. You
>>> don't necessarily have to look for implementation details or documentation
>>> but you can just leverage on the strongly typed language. It's also likely
>>> that enums are faster for comparisons than strings, but that's not the main
>>> point here.
>>>
>>>   * Removed X509Certificate from TrustedAuthorityIndicator class (method
>>> and property). It was there for informational purposes (when
>>> TrustedAuthorityIndicator was built from a certificate by a client and the
>>> whole extension indicators converted to String).
>>>
>>>   * "equals" and "hashCode" methods moved from TrustedAuthorityIndicator
>>> to TrustedAuthorityIndicatorImpl class.
>>>
>>>   * "getLength" method removed from TrustedAuthorityIndicator class.
>>> It's possible to get the encoded buffer and the length from there.
>>>
>>>   * "getData" method renamed to "getEncoded" in
>>> TrustedAuthorityIndicator class.
>>>
>>>   * "trustedAuthorityEncodedData" renamed to "encodedData" in
>>> TrustedAuthorityIndicator and TrustedAuthorityIndicatorImpl classes
>>>
>>>   * "identifier" and "encodedData" instance variables moved from
>>> TrustedAuthorityIndicator to TrustedAuthorityIndicatorImpl class.
>>>
>>>   * "getEncoded" and "getIdentifier" are now abstract methods in
>>> TrustedAuthorityIndicator, and their implementation is in
>>> TrustedAuthorityIndicatorImpl class.
>>>
>>>   * "getIdentifier" method renamed to "getType" in
>>> TrustedAuthorityIndicator and TrustedAuthorityIndicatorImpl classes
>>> ("identifier" instance variable and parameter in
>>> TrustedAuthorityIndicatorImpl class renamed to "type").
>>>
>>>   * Test cases (server and client) updated to reflect the new interface
>>> (enabling the use of the extension through SSLParameters)
>>>
>>> However, some changes are still not implemented and I have some concerns:
>>>
>>> 1) I still believe that identifier type information has to be on
>>> TrustedAuthorityIndicator class somehow, and implementations restricted on
>>> what they can return as part of "getType" method. This is strictly
>>> specified by the RFC TrustedAuthorityIndicator class represents, and I find
>>> desirable that any implementation is enforced to be compliant to that. If
>>> we remove all of that (including the enum), TrustedAuthorityIndicator looks
>>> too generic and does not reflect (in my opinion) what it really is. It'd
>>> also be chaotic if different implementations call pre-agreed type as
>>> "preagreed", "pre-agreed", "PRE_AGREED", etc. I prefer stricter and more
>>> explicit interfaces.
>>>
>>> 2) I agree that type mappings can be seen as part of an implementation,
>>> but they were in TrustedAuthorityIndicator (as protected) because every
>>> implementation is highly likely to need them and we can avoid the necessity
>>> for repeated code/mappings. The same for "type" and "encodedData" variables
>>> or even "hashCode" and "equals" methods. That's why I was thinking more of
>>> an abstract class and not an interface, as it happens (in example) with
>>> SNIServerName.
>>>
>>> 3) I think that "implies" method on TrustedAuthorityIndicator should be
>>> also part of the class/interface, because that's the whole point of a
>>> Trusted Authority Information: to allow queries for a given certificate.
>>> This is, in fact, the only thing a server wants from one of these objects.
>>> My concern is that if we remove this requirement for an implementation, the
>>> interface looks more like a byte buffer holder.
>>>
>>> I'd appreciate if you can re-consider these items.
>>>
>>> Thanks,
>>> Martin.-
>>>
>>> On Wed, Jun 14, 2017 at 7:17 PM, Xuelei Fan <xuelei.fan at oracle.com
>>> <mailto:xuelei.fan at oracle.com>> wrote:
>>>
>>>     Hi Martin,
>>>
>>>     The big picture of the design looks pretty good to me, except a few
>>>     comment about the JSSE conventions.  I appreciate it very much.  By
>>>     the way, I need more time to look into the details of the
>>>     specification and implementation.
>>>
>>>
>>>     In order to keep the APIs simple and small, SSLParameters is
>>>     preferred as the only configuration port for common cases.   I may
>>>     suggest to remove the s/getUseTrustedCAIndication() methods in
>>>     SSLEngine/SSLSocket.
>>>
>>>     The identify type is defined as an enum
>>>     TrustedAuthorityIndicator.IdentifierType.  In the future, if more
>>>     type is added, we need to update the specification by adding a new
>>>     enum item.  Enum is preferred in JDK, but for good extensibility, in
>>>     general JSSE does not use enum in public APIs for extensible
>>>     properties.  I may suggest to use String (or integer/byte, I prefer
>>>     to use String) as the type.  The standard trusted authority
>>>     indicator algorithm (identifier) can be documented in the "Java
>>>     Cryptography Architecture Standard Algorithm Name Documentation"[1].
>>>
>>>     In TrustedAuthorityIndicator class, some methods, like
>>>     getIdentifierTypeFromCode(), getCodeFromIdentifierType(), implies(),
>>>     getLength(), equals() and hashCode() look more like implementation
>>>     logic.  I may suggest remove them from public APIs.
>>>
>>>     I did not see the benefit to have X509Certificate in the
>>>     TrustedAuthorityIndicator class.  The class is mainly used for
>>>     server side certificate selection.  X509Certificate could be unknown
>>>     for a indicator.  I may suggestion remove the related methods and
>>>     properties.
>>>
>>>     After that, as there is no requirement to instantiate
>>>     TrustedAuthorityIndicator class in application code, looks like it
>>>     may be enough to use an interface to represent a trusted authorities:
>>>         public interface TrustedAuthorityIndicator {
>>>              // identifier type, standard algorithm name
>>>              String/int/Byte getType();
>>>
>>>              // identifier
>>>              byte[] getEncoded();
>>>         }
>>>
>>>     What do you think?
>>>
>>>
>>>     Thanks & Regards,
>>>     Xuelei
>>>
>>>     [1]
>>>     https://docs.oracle.com/javase/8/docs/technotes/guides/secur
>>> ity/StandardNames.html
>>>     <https://docs.oracle.com/javase/8/docs/technotes/guides/secu
>>> rity/StandardNames.html>
>>>
>>>
>>>     On 6/13/2017 3:41 PM, Martin Balao wrote:
>>>
>>>         Hi Xuelei,
>>>
>>>         The new webrev.01 is ready:
>>>
>>>            *
>>>         http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste
>>> d_ca/2017_06_13/8046295.webrev.01/
>>>         <http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trust
>>> ed_ca/2017_06_13/8046295.webrev.01/>
>>>         (browse online)
>>>            *
>>>         http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_truste
>>> d_ca/2017_06_13/8046295.webrev.01.zip
>>>         <http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trust
>>> ed_ca/2017_06_13/8046295.webrev.01.zip>
>>>         (zip, download)
>>>
>>>         The following changes have been implemented since the previous
>>>         webrev.00:
>>>
>>>            * Pre-agreed support removed from server-side
>>>             * Unnecessary overhead and minium benefits for JSSE.
>>>
>>>            * Enabling the use of Trusted CA Indication extension for
>>>         clients through TrustManager objects was reverted. Trusted CA
>>>         Indication extension can now be enabled through: 1) SSLEngine,
>>>         2) SSLSocket, or 3) SSLParameters (which can be applied to both
>>>         SSLEngine and SSLSocket objects). Trusted CA Indication
>>>         extension is mandatory for servers.
>>>
>>>            * SunX509KeyManagerImpl old key manager ("SunX509" algorithm)
>>>         is now out of scope. This key manager does not support other TLS
>>>         extensions as Server Name Indication (SNI), which is far more
>>>         relevant than Trusted CA Indication. The new X509KeyManagerImpl
>>>         key manager ("PKIX" algorithm) is now in scope.
>>>
>>>            * Client requested indications are now an ExtendedSSLSession
>>>         attribute. ServerHandshaker gets the information from the Client
>>>         Hello message (now parsed by TrustedCAIndicationExtension class
>>>         instead of TrustedAuthorityIndicator) and sets it in the
>>>         ExtendedSSLSession (SSLSessionImpl object). The key manager
>>>         (i.e.: X509KeyManagerImpl), when choosing a server alias, may
>>>         now get the information from the ExtendedSSLSession object and
>>>         guide the certificate selection based on it.
>>>             * In order to allow multiple key managers to use Trusted
>>>         Authority Indicators information and to allow multiple Trusted
>>>         Authority Indicators implementations, TrustedAuthorityIndicator
>>>         has now been split in an abstract class
>>>         (TrustedAuthorityIndicator, located in javax.net.ssl) and an
>>>         implementation class (TrustedAuthorityIndicatorImpl, located in
>>>         sun.security.ssl). No coupling was added between javax.net.ssl
>>>         and sun.security.ssl packages.
>>>
>>>            * Documentation extended and improved.
>>>            * Test cases (server and client) updated to reflect the new
>>>         interface and supported key manager.
>>>
>>>         Look forward to your new review!
>>>
>>>         Kind regards,
>>>         Martin.-
>>>
>>>
>>>
>>>         On Fri, Jun 9, 2017 at 6:15 PM, Xuelei Fan
>>>         <xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>
>>>         <mailto:xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>>>
>>>         wrote:
>>>
>>>              I'm OK to use SSLParameters.  Thank you very much for
>>>         considering a
>>>              new design.
>>>
>>>              Xuelei
>>>
>>>              On 6/9/2017 1:10 PM, Martin Balao wrote:
>>>
>>>                  Hi Xuelei,
>>>
>>>                  I didn't notice that some of the SSLSocket contructors
>>>         did not
>>>                  establish the connection, so SSLParameters can be
>>>         effective for
>>>                  Trusted CA Indication. This was an invalid argument on
>>>         my side,
>>>                  sorry.
>>>
>>>                  As for the configuration to enable the extension, it's
>>>         probably
>>>                  not necessary on the Server side because -as you
>>>         mentioned- it
>>>                  is mandatory and there is no harm in supporting it.
>>>         However, it
>>>                  has to be configurable on the Client side because -as we
>>>                  previously discussed- the client may cause a handshake
>>>         failure
>>>                  if the server does not support the extension. I'd
>>>         prefer the
>>>                  Client configuring the SSLSocket through SSLParameters
>>>         instead
>>>                  of a system-wide property -which has even more impact
>>>         than the
>>>                  TrustManager approach-. Would this work for you?
>>>
>>>                    > In JSSE, the benefits pre_agreed option can get by
>>>                  customizing the key/trust manager, so I did not see too
>>>         much
>>>                  benefits to support this option in JDK
>>>
>>>                  I understand your point and will remove support for
>>>         "pre_agreed".
>>>
>>>
>>>                  On Fri, Jun 9, 2017 at 1:37 AM, Xuelei Fan
>>>                  <xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>
>>>         <mailto:xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>>
>>>                  <mailto:xuelei.fan at oracle.com
>>>         <mailto:xuelei.fan at oracle.com> <mailto:xuelei.fan at oracle.com
>>>         <mailto:xuelei.fan at oracle.com>>>>
>>>                  wrote:
>>>
>>>
>>>
>>>                       On 6/8/2017 8:36 PM, Xuelei Fan wrote:
>>>
>>>                           The trusted authorities can be get from client
>>>         trust
>>>                  manager.         Server can choose the best matching of
>>>         server
>>>                  certificate of the
>>>                           client requested trusted authorities.
>>>
>>>                       >
>>>                       I missed the point that the key manager need to
>>>         know the client
>>>                       requested trusted authorities for the choosing.
>>>      So may
>>>                  need a new
>>>                       SSLSession attribute (See similar method in
>>>                  ExtendedSSLSession).
>>>
>>>                       Xuelei
>>>
>>>
>>>
>>>                  Yes, an attribute on SSLSession may do the job (both
>>>         when Key
>>>                  Manager receives a SSLSocket and a SSLEngine).
>>>
>>>                  Kind regards,
>>>                  Martin.-
>>>
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170721/7bce6150/attachment.htm>

From anders.rundgren.net at gmail.com  Tue Jul 25 04:34:35 2017
From: anders.rundgren.net at gmail.com (Anders Rundgren)
Date: Tue, 25 Jul 2017 06:34:35 +0200
Subject: IETF input on CFRG support in Java
Message-ID: <0823a6ce-a161-6540-7938-15e337f0c909@gmail.com>

https://mailarchive.ietf.org/arch/msg/curdle/GVHazpHuUxq5H7PShB0AFE8DQZI

Jim Schaad is one of the leading cryptographers in IETF.

Anders
Recently upgraded: https://github.com/cyberphone/java-cfrg-spec


From xuelei.fan at oracle.com  Tue Jul 25 16:02:50 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 25 Jul 2017 09:02:50 -0700
Subject: Code Review Request, JDK-8184316, Typo in
 javax.net.ssl.SSLServerSocket class documentation
Message-ID: <033efdac-b903-cc0d-52d7-67fe90b39774@oracle.com>

Hi,

Please review the document typo update for:
    https://bugs.openjdk.java.net/browse/JDK-8184316

The diff on javax/net/ssl/SSLServerSocket.java looks like:

  /**
- * This class extends <code>ServerSocket</code>s and
+ * This class extends <code>ServerSocket</code> and
   * provides secure server sockets using protocols such as the Secure
   * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
   * <P>
@@ -41,7 +41,7 @@
   * is to create <code>SSLSocket</code>s by <code>accept</code>ing
   * connections.
   * <P>
- * <code>SSLServerSocket</code>s contain several pieces of state data
+ * <code>SSLServerSocket</code> contains several pieces of state data
   * which are inherited by the <code>SSLSocket</code> at
   * socket creation.  These include the enabled cipher
   * suites and protocols, whether client

Thanks,
Xuelei


From sean.mullan at oracle.com  Tue Jul 25 16:14:16 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 25 Jul 2017 12:14:16 -0400
Subject: Code Review Request, JDK-8184316, Typo in
 javax.net.ssl.SSLServerSocket class documentation
In-Reply-To: <033efdac-b903-cc0d-52d7-67fe90b39774@oracle.com>
References: <033efdac-b903-cc0d-52d7-67fe90b39774@oracle.com>
Message-ID: <5ae81df9-63b2-e1f9-251d-72f63651c8f4@oracle.com>

SSLSocket has the same typo in its first sentence ("extends Sockets"), 
and should also say "provides secure sockets" (note the plural sockets). 
Can you fix that as part of this too?

One wording improvement below:

On 7/25/17 12:02 PM, Xuelei Fan wrote:
> Hi,
> 
> Please review the document typo update for:
>     https://bugs.openjdk.java.net/browse/JDK-8184316
> 
> The diff on javax/net/ssl/SSLServerSocket.java looks like:
> 
>   /**
> - * This class extends <code>ServerSocket</code>s and
> + * This class extends <code>ServerSocket</code> and
>    * provides secure server sockets using protocols such as the Secure
>    * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
>    * <P>
> @@ -41,7 +41,7 @@
>    * is to create <code>SSLSocket</code>s by <code>accept</code>ing
>    * connections.
>    * <P>
> - * <code>SSLServerSocket</code>s contain several pieces of state data
> + * <code>SSLServerSocket</code> contains several pieces of state data

An SSLServerSocket contains ...

>    * which are inherited by the <code>SSLSocket</code> at
>    * socket creation.  These include the enabled cipher
>    * suites and protocols, whether client
> 
> Thanks,
> Xuelei


From sibabrata.sahoo at oracle.com  Tue Jul 25 16:20:16 2017
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 25 Jul 2017 09:20:16 -0700 (PDT)
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java
 should clean up better
In-Reply-To: <89402164-f4b1-4e36-b894-2ad997efd409@default>
References: <89402164-f4b1-4e36-b894-2ad997efd409@default>
Message-ID: <7c76d0c8-a3a6-457a-bcb7-419f034021fe@default>

Hi,

 

This patch is pending for your review.

 

Thanks,

Siba

 

From: Sibabrata Sahoo 
Sent: Saturday, July 15, 2017 4:00 PM
To: Weijun Wang; Valerie Peng; security-dev at openjdk.java.net
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better

 

Hi,

 

Please review the patch for the following,

 

JBS: https://bugs.openjdk.java.net/browse/JDK-8183310

Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/

 

Change description:

The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file "java/security/modules/ModularTest.java".

 

SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files "TestClient.java" and "TestProvider.java" renamed and changed a little during clean up.

JaasModularClientTest.java - Verify JAAS login module in all possible modular combination.

JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed "TEST.properties" file.

 

Thanks,

Siba

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170725/b5af75d6/attachment.htm>

From xuelei.fan at oracle.com  Tue Jul 25 16:26:37 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 25 Jul 2017 09:26:37 -0700
Subject: Code Review Request, JDK-8184316, Typo in
 javax.net.ssl.SSLServerSocket class documentation
In-Reply-To: <5ae81df9-63b2-e1f9-251d-72f63651c8f4@oracle.com>
References: <033efdac-b903-cc0d-52d7-67fe90b39774@oracle.com>
 <5ae81df9-63b2-e1f9-251d-72f63651c8f4@oracle.com>
Message-ID: <6cc85184-3476-40ad-9aeb-16b85286f503@oracle.com>

Good catch!  More update:

javax/net/ssl/SSLServerSocket.java
----------------------------------
  /**
- * This class extends <code>ServerSocket</code>s and
+ * This class extends <code>ServerSocket</code> and
   * provides secure server sockets using protocols such as the Secure
   * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
   * <P>
   * Instances of this class are generally created using a
   * <code>SSLServerSocketFactory</code>.  The primary function
- * of <code>SSLServerSocket</code>s
+ * of <code>SSLServerSocket</code>
   * is to create <code>SSLSocket</code>s by <code>accept</code>ing
   * connections.
   * <P>
- * <code>SSLServerSocket</code>s contain several pieces of state data
+ * <code>SSLServerSocket</code> contains several pieces of state data
   * which are inherited by the <code>SSLSocket</code> at
   * socket creation.  These include the enabled cipher
   * suites and protocols, whether client


javax/net/ssl/SSLSocket.java
----------------------------
  /**
- * This class extends <code>Socket</code>s and provides secure
- * socket using protocols such as the "Secure
+ * This class extends <code>Socket</code> and provides secure
+ * sockets using protocols such as the "Secure
   * Sockets Layer" (SSL) or IETF "Transport Layer Security" (TLS) 
protocols.
   * <P>
   * Such sockets are normal stream sockets, but they
@@ -105,7 +105,7 @@
   * non-private (unencrypted) communications will such a ciphersuite be
   * selected.
   *
- * <P>When <code>SSLSocket</code>s are first created, no handshaking
+ * <P>When <code>SSLSocket</code> is first created, no handshaking
   * is done so that applications may first set their communication
   * preferences:  what cipher suites to use, whether the socket should be
   * in client or server mode, etc.
@@ -118,7 +118,7 @@
   * objects are passed to <em>HandshakeCompletedListener</em> instances,
   * which are registered by users of this API.
   *
- * <code>SSLSocket</code>s are created by <code>SSLSocketFactory</code>s,
+ * <code>SSLSocket</code> is created by <code>SSLSocketFactory</code>,
   * or by <code>accept</code>ing a connection from a
   * <code>SSLServerSocket</code>.


Thanks,
Xuelei

On 7/25/2017 9:14 AM, Sean Mullan wrote:
> SSLSocket has the same typo in its first sentence ("extends Sockets"), 
> and should also say "provides secure sockets" (note the plural sockets). 
> Can you fix that as part of this too?
> 
> One wording improvement below:
> 
> On 7/25/17 12:02 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the document typo update for:
>>     https://bugs.openjdk.java.net/browse/JDK-8184316
>>
>> The diff on javax/net/ssl/SSLServerSocket.java looks like:
>>
>>   /**
>> - * This class extends <code>ServerSocket</code>s and
>> + * This class extends <code>ServerSocket</code> and
>>    * provides secure server sockets using protocols such as the Secure
>>    * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
>>    * <P>
>> @@ -41,7 +41,7 @@
>>    * is to create <code>SSLSocket</code>s by <code>accept</code>ing
>>    * connections.
>>    * <P>
>> - * <code>SSLServerSocket</code>s contain several pieces of state data
>> + * <code>SSLServerSocket</code> contains several pieces of state data
> 
> An SSLServerSocket contains ...
> 
>>    * which are inherited by the <code>SSLSocket</code> at
>>    * socket creation.  These include the enabled cipher
>>    * suites and protocols, whether client
>>
>> Thanks,
>> Xuelei


From xuelei.fan at oracle.com  Tue Jul 25 16:32:38 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 25 Jul 2017 09:32:38 -0700
Subject: Code Review Request, JDK-8184316, Typo in
 javax.net.ssl.SSLServerSocket class documentation
In-Reply-To: <6cc85184-3476-40ad-9aeb-16b85286f503@oracle.com>
References: <033efdac-b903-cc0d-52d7-67fe90b39774@oracle.com>
 <5ae81df9-63b2-e1f9-251d-72f63651c8f4@oracle.com>
 <6cc85184-3476-40ad-9aeb-16b85286f503@oracle.com>
Message-ID: <42b5c07b-a844-c5a5-8321-c6e319645a65@oracle.com>

I missed a comment.

javax/net/ssl/SSLServerSocket.java
----------------------------------
  /**
- * This class extends <code>ServerSocket</code>s and
+ * This class extends <code>ServerSocket</code> and
   * provides secure server sockets using protocols such as the Secure
   * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
   * <P>
- * Instances of this class are generally created using a
+ * Instances of this class are generally created using an
   * <code>SSLServerSocketFactory</code>.  The primary function
- * of <code>SSLServerSocket</code>s
+ * of an <code>SSLServerSocket</code>
   * is to create <code>SSLSocket</code>s by <code>accept</code>ing
   * connections.
   * <P>
- * <code>SSLServerSocket</code>s contain several pieces of state data
+ * An <code>SSLServerSocket</code> contains several pieces of state data
   * which are inherited by the <code>SSLSocket</code> at
   * socket creation.  These include the enabled cipher
   * suites and protocols, whether client


javax/net/ssl/SSLSocket.java
----------------------------
  /**
- * This class extends <code>Socket</code>s and provides secure
- * socket using protocols such as the "Secure
+ * This class extends <code>Socket</code> and provides secure
+ * sockets using protocols such as the "Secure
   * Sockets Layer" (SSL) or IETF "Transport Layer Security" (TLS) 
protocols.
   * <P>
   * Such sockets are normal stream sockets, but they
@@ -105,7 +105,7 @@
   * non-private (unencrypted) communications will such a ciphersuite be
   * selected.
   *
- * <P>When <code>SSLSocket</code>s are first created, no handshaking
+ * <P>When an <code>SSLSocket</code> is first created, no handshaking
   * is done so that applications may first set their communication
   * preferences:  what cipher suites to use, whether the socket should be
   * in client or server mode, etc.
@@ -118,7 +118,7 @@
   * objects are passed to <em>HandshakeCompletedListener</em> instances,
   * which are registered by users of this API.
   *
- * <code>SSLSocket</code>s are created by <code>SSLSocketFactory</code>s,
+ * An <code>SSLSocket</code> is created by <code>SSLSocketFactory</code>,
   * or by <code>accept</code>ing a connection from a
   * <code>SSLServerSocket</code>.
   *

Thanks,
Xuelei
On 7/25/2017 9:26 AM, Xuelei Fan wrote:
> Good catch!  More update:
> 
> javax/net/ssl/SSLServerSocket.java
> ----------------------------------
>   /**
> - * This class extends <code>ServerSocket</code>s and
> + * This class extends <code>ServerSocket</code> and
>    * provides secure server sockets using protocols such as the Secure
>    * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
>    * <P>
>    * Instances of this class are generally created using a
>    * <code>SSLServerSocketFactory</code>.  The primary function
> - * of <code>SSLServerSocket</code>s
> + * of <code>SSLServerSocket</code>
>    * is to create <code>SSLSocket</code>s by <code>accept</code>ing
>    * connections.
>    * <P>
> - * <code>SSLServerSocket</code>s contain several pieces of state data
> + * <code>SSLServerSocket</code> contains several pieces of state data
>    * which are inherited by the <code>SSLSocket</code> at
>    * socket creation.  These include the enabled cipher
>    * suites and protocols, whether client
> 
> 
> javax/net/ssl/SSLSocket.java
> ----------------------------
>   /**
> - * This class extends <code>Socket</code>s and provides secure
> - * socket using protocols such as the "Secure
> + * This class extends <code>Socket</code> and provides secure
> + * sockets using protocols such as the "Secure
>    * Sockets Layer" (SSL) or IETF "Transport Layer Security" (TLS) 
> protocols.
>    * <P>
>    * Such sockets are normal stream sockets, but they
> @@ -105,7 +105,7 @@
>    * non-private (unencrypted) communications will such a ciphersuite be
>    * selected.
>    *
> - * <P>When <code>SSLSocket</code>s are first created, no handshaking
> + * <P>When <code>SSLSocket</code> is first created, no handshaking
>    * is done so that applications may first set their communication
>    * preferences:  what cipher suites to use, whether the socket should be
>    * in client or server mode, etc.
> @@ -118,7 +118,7 @@
>    * objects are passed to <em>HandshakeCompletedListener</em> instances,
>    * which are registered by users of this API.
>    *
> - * <code>SSLSocket</code>s are created by <code>SSLSocketFactory</code>s,
> + * <code>SSLSocket</code> is created by <code>SSLSocketFactory</code>,
>    * or by <code>accept</code>ing a connection from a
>    * <code>SSLServerSocket</code>.
> 
> 
> Thanks,
> Xuelei
> 
> On 7/25/2017 9:14 AM, Sean Mullan wrote:
>> SSLSocket has the same typo in its first sentence ("extends Sockets"), 
>> and should also say "provides secure sockets" (note the plural 
>> sockets). Can you fix that as part of this too?
>>
>> One wording improvement below:
>>
>> On 7/25/17 12:02 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Please review the document typo update for:
>>>     https://bugs.openjdk.java.net/browse/JDK-8184316
>>>
>>> The diff on javax/net/ssl/SSLServerSocket.java looks like:
>>>
>>>   /**
>>> - * This class extends <code>ServerSocket</code>s and
>>> + * This class extends <code>ServerSocket</code> and
>>>    * provides secure server sockets using protocols such as the Secure
>>>    * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
>>>    * <P>
>>> @@ -41,7 +41,7 @@
>>>    * is to create <code>SSLSocket</code>s by <code>accept</code>ing
>>>    * connections.
>>>    * <P>
>>> - * <code>SSLServerSocket</code>s contain several pieces of state data
>>> + * <code>SSLServerSocket</code> contains several pieces of state data
>>
>> An SSLServerSocket contains ...
>>
>>>    * which are inherited by the <code>SSLSocket</code> at
>>>    * socket creation.  These include the enabled cipher
>>>    * suites and protocols, whether client
>>>
>>> Thanks,
>>> Xuelei


From sean.mullan at oracle.com  Tue Jul 25 17:14:30 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 25 Jul 2017 13:14:30 -0400
Subject: Code Review Request, JDK-8184316, Typo in
 javax.net.ssl.SSLServerSocket class documentation
In-Reply-To: <6cc85184-3476-40ad-9aeb-16b85286f503@oracle.com>
References: <033efdac-b903-cc0d-52d7-67fe90b39774@oracle.com>
 <5ae81df9-63b2-e1f9-251d-72f63651c8f4@oracle.com>
 <6cc85184-3476-40ad-9aeb-16b85286f503@oracle.com>
Message-ID: <f6adf93a-9968-d7d7-e1b3-9d1dd091d869@oracle.com>

On 7/25/17 12:26 PM, Xuelei Fan wrote:
> Good catch!  More update:
> 
> javax/net/ssl/SSLServerSocket.java
> ----------------------------------
>   /**
> - * This class extends <code>ServerSocket</code>s and
> + * This class extends <code>ServerSocket</code> and
>    * provides secure server sockets using protocols such as the Secure
>    * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
>    * <P>
>    * Instances of this class are generally created using a
>    * <code>SSLServerSocketFactory</code>.  The primary function
> - * of <code>SSLServerSocket</code>s
> + * of <code>SSLServerSocket</code>
>    * is to create <code>SSLSocket</code>s by <code>accept</code>ing
>    * connections.
>    * <P>
> - * <code>SSLServerSocket</code>s contain several pieces of state data
> + * <code>SSLServerSocket</code> contains several pieces of state data

I think this sentence sounds better if it starts with "An 
SSLServerSocket ...". Same comment below ...

>    * which are inherited by the <code>SSLSocket</code> at
>    * socket creation.  These include the enabled cipher
>    * suites and protocols, whether client
> 
> 
> javax/net/ssl/SSLSocket.java
> ----------------------------
>   /**
> - * This class extends <code>Socket</code>s and provides secure
> - * socket using protocols such as the "Secure
> + * This class extends <code>Socket</code> and provides secure
> + * sockets using protocols such as the "Secure
>    * Sockets Layer" (SSL) or IETF "Transport Layer Security" (TLS) 
> protocols.
>    * <P>
>    * Such sockets are normal stream sockets, but they
> @@ -105,7 +105,7 @@
>    * non-private (unencrypted) communications will such a ciphersuite be
>    * selected.
>    *
> - * <P>When <code>SSLSocket</code>s are first created, no handshaking
> + * <P>When <code>SSLSocket</code> is first created, no handshaking
>    * is done so that applications may first set their communication
>    * preferences:  what cipher suites to use, whether the socket should be
>    * in client or server mode, etc.
> @@ -118,7 +118,7 @@
>    * objects are passed to <em>HandshakeCompletedListener</em> instances,
>    * which are registered by users of this API.
>    *
> - * <code>SSLSocket</code>s are created by <code>SSLSocketFactory</code>s,
> + * <code>SSLSocket</code> is created by <code>SSLSocketFactory</code>,

"An SSLSocket ..."

--Sean


From sean.mullan at oracle.com  Tue Jul 25 17:14:55 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 25 Jul 2017 13:14:55 -0400
Subject: Code Review Request, JDK-8184316, Typo in
 javax.net.ssl.SSLServerSocket class documentation
In-Reply-To: <42b5c07b-a844-c5a5-8321-c6e319645a65@oracle.com>
References: <033efdac-b903-cc0d-52d7-67fe90b39774@oracle.com>
 <5ae81df9-63b2-e1f9-251d-72f63651c8f4@oracle.com>
 <6cc85184-3476-40ad-9aeb-16b85286f503@oracle.com>
 <42b5c07b-a844-c5a5-8321-c6e319645a65@oracle.com>
Message-ID: <39bc9a6a-aa7e-22b7-c27a-1a618e131f29@oracle.com>

Looks good now.

--Sean

On 7/25/17 12:32 PM, Xuelei Fan wrote:
> I missed a comment.
> 
> javax/net/ssl/SSLServerSocket.java
> ----------------------------------
>   /**
> - * This class extends <code>ServerSocket</code>s and
> + * This class extends <code>ServerSocket</code> and
>    * provides secure server sockets using protocols such as the Secure
>    * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
>    * <P>
> - * Instances of this class are generally created using a
> + * Instances of this class are generally created using an
>    * <code>SSLServerSocketFactory</code>.  The primary function
> - * of <code>SSLServerSocket</code>s
> + * of an <code>SSLServerSocket</code>
>    * is to create <code>SSLSocket</code>s by <code>accept</code>ing
>    * connections.
>    * <P>
> - * <code>SSLServerSocket</code>s contain several pieces of state data
> + * An <code>SSLServerSocket</code> contains several pieces of state data
>    * which are inherited by the <code>SSLSocket</code> at
>    * socket creation.  These include the enabled cipher
>    * suites and protocols, whether client
> 
> 
> javax/net/ssl/SSLSocket.java
> ----------------------------
>   /**
> - * This class extends <code>Socket</code>s and provides secure
> - * socket using protocols such as the "Secure
> + * This class extends <code>Socket</code> and provides secure
> + * sockets using protocols such as the "Secure
>    * Sockets Layer" (SSL) or IETF "Transport Layer Security" (TLS) 
> protocols.
>    * <P>
>    * Such sockets are normal stream sockets, but they
> @@ -105,7 +105,7 @@
>    * non-private (unencrypted) communications will such a ciphersuite be
>    * selected.
>    *
> - * <P>When <code>SSLSocket</code>s are first created, no handshaking
> + * <P>When an <code>SSLSocket</code> is first created, no handshaking
>    * is done so that applications may first set their communication
>    * preferences:  what cipher suites to use, whether the socket should be
>    * in client or server mode, etc.
> @@ -118,7 +118,7 @@
>    * objects are passed to <em>HandshakeCompletedListener</em> instances,
>    * which are registered by users of this API.
>    *
> - * <code>SSLSocket</code>s are created by <code>SSLSocketFactory</code>s,
> + * An <code>SSLSocket</code> is created by <code>SSLSocketFactory</code>,
>    * or by <code>accept</code>ing a connection from a
>    * <code>SSLServerSocket</code>.
>    *
> 
> Thanks,
> Xuelei
> On 7/25/2017 9:26 AM, Xuelei Fan wrote:
>> Good catch!  More update:
>>
>> javax/net/ssl/SSLServerSocket.java
>> ----------------------------------
>>   /**
>> - * This class extends <code>ServerSocket</code>s and
>> + * This class extends <code>ServerSocket</code> and
>>    * provides secure server sockets using protocols such as the Secure
>>    * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
>>    * <P>
>>    * Instances of this class are generally created using a
>>    * <code>SSLServerSocketFactory</code>.  The primary function
>> - * of <code>SSLServerSocket</code>s
>> + * of <code>SSLServerSocket</code>
>>    * is to create <code>SSLSocket</code>s by <code>accept</code>ing
>>    * connections.
>>    * <P>
>> - * <code>SSLServerSocket</code>s contain several pieces of state data
>> + * <code>SSLServerSocket</code> contains several pieces of state data
>>    * which are inherited by the <code>SSLSocket</code> at
>>    * socket creation.  These include the enabled cipher
>>    * suites and protocols, whether client
>>
>>
>> javax/net/ssl/SSLSocket.java
>> ----------------------------
>>   /**
>> - * This class extends <code>Socket</code>s and provides secure
>> - * socket using protocols such as the "Secure
>> + * This class extends <code>Socket</code> and provides secure
>> + * sockets using protocols such as the "Secure
>>    * Sockets Layer" (SSL) or IETF "Transport Layer Security" (TLS) 
>> protocols.
>>    * <P>
>>    * Such sockets are normal stream sockets, but they
>> @@ -105,7 +105,7 @@
>>    * non-private (unencrypted) communications will such a ciphersuite be
>>    * selected.
>>    *
>> - * <P>When <code>SSLSocket</code>s are first created, no handshaking
>> + * <P>When <code>SSLSocket</code> is first created, no handshaking
>>    * is done so that applications may first set their communication
>>    * preferences:  what cipher suites to use, whether the socket 
>> should be
>>    * in client or server mode, etc.
>> @@ -118,7 +118,7 @@
>>    * objects are passed to <em>HandshakeCompletedListener</em> instances,
>>    * which are registered by users of this API.
>>    *
>> - * <code>SSLSocket</code>s are created by 
>> <code>SSLSocketFactory</code>s,
>> + * <code>SSLSocket</code> is created by <code>SSLSocketFactory</code>,
>>    * or by <code>accept</code>ing a connection from a
>>    * <code>SSLServerSocket</code>.
>>
>>
>> Thanks,
>> Xuelei
>>
>> On 7/25/2017 9:14 AM, Sean Mullan wrote:
>>> SSLSocket has the same typo in its first sentence ("extends 
>>> Sockets"), and should also say "provides secure sockets" (note the 
>>> plural sockets). Can you fix that as part of this too?
>>>
>>> One wording improvement below:
>>>
>>> On 7/25/17 12:02 PM, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Please review the document typo update for:
>>>>     https://bugs.openjdk.java.net/browse/JDK-8184316
>>>>
>>>> The diff on javax/net/ssl/SSLServerSocket.java looks like:
>>>>
>>>>   /**
>>>> - * This class extends <code>ServerSocket</code>s and
>>>> + * This class extends <code>ServerSocket</code> and
>>>>    * provides secure server sockets using protocols such as the Secure
>>>>    * Sockets Layer (SSL) or Transport Layer Security (TLS) protocols.
>>>>    * <P>
>>>> @@ -41,7 +41,7 @@
>>>>    * is to create <code>SSLSocket</code>s by <code>accept</code>ing
>>>>    * connections.
>>>>    * <P>
>>>> - * <code>SSLServerSocket</code>s contain several pieces of state data
>>>> + * <code>SSLServerSocket</code> contains several pieces of state data
>>>
>>> An SSLServerSocket contains ...
>>>
>>>>    * which are inherited by the <code>SSLSocket</code> at
>>>>    * socket creation.  These include the enabled cipher
>>>>    * suites and protocols, whether client
>>>>
>>>> Thanks,
>>>> Xuelei


From xuelei.fan at oracle.com  Tue Jul 25 17:47:16 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 25 Jul 2017 10:47:16 -0700
Subject: Code Review request, JDK-6645409, Remove not used
 DefaultHostnameVerifier
Message-ID: <b4303227-212f-e460-b6cd-0c77f673bff6@oracle.com>

Hi,

Please review a code cleanup update:

    https://bugs.openjdk.java.net/browse/JDK-6645409

The sun.net.www.protocol.https.DefaultHostnameVerifier is not used any 
more. We can remove it safely now.

% hg remove 
src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java

% hg status 
src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java
R 
src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java


Thanks,
Xuelei


From sean.mullan at oracle.com  Tue Jul 25 17:54:59 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 25 Jul 2017 13:54:59 -0400
Subject: Code Review request, JDK-6645409, Remove not used
 DefaultHostnameVerifier
In-Reply-To: <b4303227-212f-e460-b6cd-0c77f673bff6@oracle.com>
References: <b4303227-212f-e460-b6cd-0c77f673bff6@oracle.com>
Message-ID: <1320d81a-9f80-36fc-dedb-d23ce9b103c3@oracle.com>

The bug needs a noreg-cleanup label. Also, I would change the title to 
"Remove unused DefaultHostNameVerifier".

Looks fine otherwise.

--Sean

On 7/25/17 1:47 PM, Xuelei Fan wrote:
> Hi,
> 
> Please review a code cleanup update:
> 
>     https://bugs.openjdk.java.net/browse/JDK-6645409
> 
> The sun.net.www.protocol.https.DefaultHostnameVerifier is not used any 
> more. We can remove it safely now.
> 
> % hg remove 
> src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java 
> 
> 
> % hg status 
> src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java 
> 
> R 
> src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java 
> 
> 
> 
> Thanks,
> Xuelei


From xuelei.fan at oracle.com  Tue Jul 25 17:56:13 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 25 Jul 2017 10:56:13 -0700
Subject: Code Review request, JDK-6645409, Remove not used
 DefaultHostnameVerifier
In-Reply-To: <1320d81a-9f80-36fc-dedb-d23ce9b103c3@oracle.com>
References: <b4303227-212f-e460-b6cd-0c77f673bff6@oracle.com>
 <1320d81a-9f80-36fc-dedb-d23ce9b103c3@oracle.com>
Message-ID: <903bd5b7-9a7e-7976-1707-98987ce29f71@oracle.com>

Updated.  Thanks for the quick review.

Xuelei

On 7/25/2017 10:54 AM, Sean Mullan wrote:
> The bug needs a noreg-cleanup label. Also, I would change the title to 
> "Remove unused DefaultHostNameVerifier".
> 
> Looks fine otherwise.
> 
> --Sean
> 
> On 7/25/17 1:47 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review a code cleanup update:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-6645409
>>
>> The sun.net.www.protocol.https.DefaultHostnameVerifier is not used any 
>> more. We can remove it safely now.
>>
>> % hg remove 
>> src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java 
>>
>>
>> % hg status 
>> src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java 
>>
>> R 
>> src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java 
>>
>>
>>
>> Thanks,
>> Xuelei


From mbalao at redhat.com  Wed Jul 26 19:12:42 2017
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 26 Jul 2017 16:12:42 -0300
Subject: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel
 Bindings)
Message-ID: <CAKZz+gdM8QJyEontxaVCruFDfEUWTnD9dxyu5hDZ1bSTwiSELw@mail.gmail.com>

Hi,

Here it is my proposal for JDK-6491070 (Support for RFC 5929-Channel
Bindings: e.g. public API to obtain TLS finished message) [1]:

 *
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/
 *
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/6491070.webrev.01.zip

Notes:

 * Implementation based on Channel Bindings for TLS (RFC 5929) [2]

 * Only "tls-unique" currently supported

Look forward to your comments.

Kind regards,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-6491070
[2] - https://tools.ietf.org/html/rfc5929
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170726/2ce7553a/attachment.htm>

From weijun.wang at oracle.com  Sun Jul 30 22:11:31 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 31 Jul 2017 06:11:31 +0800
Subject: RFR 8183591: Incorrect behavior when reading DER value with
 Integer.MAX_VALUE length
In-Reply-To: <56293781-cbd8-f861-3c81-414672debfc2@oracle.com>
References: <27cc92ad-2e3a-1fb2-6c8f-9edee0072162@oracle.com>
 <56293781-cbd8-f861-3c81-414672debfc2@oracle.com>
Message-ID: <CE081E88-E585-4648-BBD2-8585424FF8A9@oracle.com>


> On Jul 19, 2017, at 1:55 AM, Adam Petcher <adam.petcher at oracle.com> wrote:
> 
> Some additional investigation revealed that IOUtils.readFully() is only used by DER, JKS, and Kerberos. None of these need the "read to the end of the buffer" feature. This behavior of readFully() is confusing, so it is probably best to remove it.

Just back from vacation.

Yes, you are right. I filed https://bugs.openjdk.java.net/browse/JDK-8182151 some time ago. IIRC, with the proposed InputStream::readNBytes(int length) and existing InputStream::readAllBytes(), there will be no need to call IOUtils.readFully() anymore.

Thanks
Max

> 
> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.01/
> 
> 
> On 7/12/2017 2:38 PM, Adam Petcher wrote:
>> This is a bug fix for a corner case in which a DER value has length equal to Integer.MAX_VALUE. The code uses IOUtils.readFully() to read the value, which interprets length=Integer.MAX_VALUE to mean "read to the end." The result is that no exception will be thrown when fewer then Integer.MAX_VALUE bytes are read from the stream. The fix adds a check after the readFully() to ensure that the expected number of bytes were read.
>> 
>> Webrev: http://cr.openjdk.java.net/~apetcher/8183591/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183591
>> 
> 



From mbalao at redhat.com  Mon Jul 31 15:53:13 2017
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 31 Jul 2017 12:53:13 -0300
Subject: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel
 Bindings)
In-Reply-To: <CAKZz+gdM8QJyEontxaVCruFDfEUWTnD9dxyu5hDZ1bSTwiSELw@mail.gmail.com>
References: <CAKZz+gdM8QJyEontxaVCruFDfEUWTnD9dxyu5hDZ1bSTwiSELw@mail.gmail.com>
Message-ID: <CAKZz+geBHevOXG14oiQ3QfnVJr79Wi=ZWOYa-bpCgfCb8BCu1A@mail.gmail.com>

Hi,

Here it is an update for the proposed TLS Channel Bindings support in
OpenJDK:

 *
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/
(browse online)
 *
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/6491070.webrev.02.zip
(download)

Changes since v01:

 * getTlsChannelBinding API changed to return null by default (if not
implemented), instead of throwing an UnsupportedOperationException.

 * "tls-server-end-point" TLS channel binding now supported.

Kind regards,
Martin.-

On Wed, Jul 26, 2017 at 4:12 PM, Martin Balao <mbalao at redhat.com> wrote:

> Hi,
>
> Here it is my proposal for JDK-6491070 (Support for RFC 5929-Channel
> Bindings: e.g. public API to obtain TLS finished message) [1]:
>
>  * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-
> 6491070/webrev.01/
>  * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-
> 6491070/webrev.01/6491070.webrev.01.zip
>
> Notes:
>
>  * Implementation based on Channel Bindings for TLS (RFC 5929) [2]
>
>  * Only "tls-unique" currently supported
>
> Look forward to your comments.
>
> Kind regards,
> Martin.-
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-6491070
> [2] - https://tools.ietf.org/html/rfc5929
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170731/8fb2d3d1/attachment.htm>