From bradford.wetmore at oracle.com  Fri Mar  1 00:26:07 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 28 Feb 2019 16:26:07 -0800
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
In-Reply-To: <C3A79D63-F1A7-4BFA-B8B6-1AA28199E21D@oracle.com>
References: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
 <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>
 <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>
 <C3A79D63-F1A7-4BFA-B8B6-1AA28199E21D@oracle.com>
Message-ID: <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com>

AbstractDelegateHttpsURLConnection.java
---------------------------------------
74/88/etc.  I haven't checked for sure, but IIRC we made setNewClient 
public from protected and other such changes in order for these classes 
to use the delegation model and allow calls to both sun/net/www/protocol 
and com/sun/net/ssl/internal/www/protocol...  Should the delegation code 
be stripped out, and these methods be set back to protected?

ProviderConfig.java
-------------------
I think we're over-rotating on this one, I'd be very surprised if anyone 
is still using com.sun.net.ssl.internal.ssl.Provider.  My personal 
preference is to kill it now, but if you really want to keep it, please 
file a bug and commit to a near release so we can finally kill this 
thing off.

test/jdk/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
test/jdk/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
--------------------------------------------------------------------
When we opensourced the JSSE code, we left some of the javax and com 
tests in the com/sun/net/ssl test directory.  The test names are very 
similar, with the exception of the Com/Javax prefix.  The tests were 
identical, with the exception of whether they called into the com or 
javax APIs.

Here you are deleting the ComTrustManagerFactoryImpl test which is 
probably correct, but should you also be deleting the 
JavaxTrustManagerFactoryImpl test as well?  Please check that we didn't 
get too carried away and are deleting still valid tests.

Thanks,

Brad


On 2/26/2019 7:33 AM, Chris Hegarty wrote:
> 
>> On 26 Feb 2019, at 03:53, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> <Loop in net-dev>
>>
>> It makes sense to me to leave the AbstractDelegateHttpsURLConnection methods as public.  We may need to re-org the code later, but it is out of the scope of this update.
>>
>> Here is the new webrev (only AbstractDelegateHttpsURLConnection updated):
>>     http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/
> 
> I think that this is probably ok ( since the package is not exported ),
> but it seems a little distasteful to not have the API move through
> the terminal deprecation route before being removed.
> 
> -Chris.
> 

From sha.jiang at oracle.com  Fri Mar  1 00:53:27 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Fri, 1 Mar 2019 08:53:27 +0800
Subject: RFR[13] JDK-8219723:
 javax/net/ssl/compatibility/Compatibility.java failed on some SNI cases
In-Reply-To: <6364ede7-ab43-6f03-af3d-40d8414120f8@oracle.com>
References: <fb6e0626-346c-9490-323a-33079db65531@oracle.com>
 <6364ede7-ab43-6f03-af3d-40d8414120f8@oracle.com>
Message-ID: <51472664-3d41-d25d-e0d0-4c744ec5f502@oracle.com>

Hi Jamil,
Thanks for your suggestion.

Best regards,
John Jiang

On 2019/3/1 01:54, Jamil Nimeh wrote:
> This comment doesn't directly apply to this fix, but tests that depend 
> on the certs from Cert.java and have configurable PKIXParameters might 
> also just set setDate to something in the middle of this validity 
> period so you never have to worry about regenerating the certs due to 
> date issues.? That may not work for all your tests though, if? you're 
> not customizing the trust managers with PKIXParameter objects.
>
> Just something to consider as you're going forward, no changes to this 
> webrev.
>
> --Jamil
>
> On 2/27/2019 6:20 PM, sha.jiang at oracle.com wrote:
>> Hi,
>> Test javax/net/ssl/compatibility/Compatibility.java failed due to the 
>> associated certificates are expired.
>> This fix just re-generates the certificates and set much longer 
>> validity period.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8219723
>> Webrev: http://cr.openjdk.java.net/~jjiang/8219723/webrev.00/
>>
>> Best regards,
>> John Jiang
>>
>
>

From xuelei.fan at oracle.com  Fri Mar  1 16:27:47 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 1 Mar 2019 08:27:47 -0800
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
In-Reply-To: <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com>
References: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
 <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>
 <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>
 <C3A79D63-F1A7-4BFA-B8B6-1AA28199E21D@oracle.com>
 <413d46d7-4d61-d587-e7bb-847939d37187@oracle.com>
Message-ID: <906d46a3-b26c-3cae-2e5a-827fbfff7435@oracle.com>

On 2/28/2019 4:26 PM, Bradford Wetmore wrote:
> AbstractDelegateHttpsURLConnection.java
> ---------------------------------------
> 74/88/etc.? I haven't checked for sure, but IIRC we made setNewClient 
> public from protected and other such changes in order for these classes 
> to use the delegation model and allow calls to both sun/net/www/protocol 
> and com/sun/net/ssl/internal/www/protocol...? Should the delegation code 
> be stripped out, and these methods be set back to protected?
> 
It should be safe to use "protected", but it's less risky to keep it 
unchanged.  I agree that the delegation code should be stripped out. 
The HttpsURLConnection implementation could be re-designed.  I filed a 
new bug to track the enhancement (JDK-8219987).

> ProviderConfig.java
> -------------------
> I think we're over-rotating on this one, I'd be very surprised if anyone 
> is still using com.sun.net.ssl.internal.ssl.Provider.? My personal 
> preference is to kill it now, but if you really want to keep it, please 
> file a bug and commit to a near release so we can finally kill this 
> thing off.
> 
I would like do it later as the old java.security use this string, and 
I'm not sure if someone really use it in their application.  It is safer 
to fix in a separate bug.  I filled a new bug to tack the update 
(JDK-8219989).

> test/jdk/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java
> test/jdk/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java
> --------------------------------------------------------------------
> When we opensourced the JSSE code, we left some of the javax and com 
> tests in the com/sun/net/ssl test directory.? The test names are very 
> similar, with the exception of the Com/Javax prefix.? The tests were 
> identical, with the exception of whether they called into the com or 
> javax APIs.
> 
> Here you are deleting the ComTrustManagerFactoryImpl test which is 
> probably correct, but should you also be deleting the 
> JavaxTrustManagerFactoryImpl test as well?? Please check that we didn't 
> get too carried away and are deleting still valid tests.
> 
They are helper classes and used by ProviderTest, which is used to test 
the com.sun.net.ssl wrappers.

Thanks,
Xuelei

> Thanks,
> 
> Brad
> 
> 
> On 2/26/2019 7:33 AM, Chris Hegarty wrote:
>>
>>> On 26 Feb 2019, at 03:53, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>> <Loop in net-dev>
>>>
>>> It makes sense to me to leave the AbstractDelegateHttpsURLConnection 
>>> methods as public.? We may need to re-org the code later, but it is 
>>> out of the scope of this update.
>>>
>>> Here is the new webrev (only AbstractDelegateHttpsURLConnection 
>>> updated):
>>> ??? http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/
>>
>> I think that this is probably ok ( since the package is not exported ),
>> but it seems a little distasteful to not have the API move through
>> the terminal deprecation route before being removed.
>>
>> -Chris.
>>

From xuelei.fan at oracle.com  Fri Mar  1 16:54:52 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 1 Mar 2019 08:54:52 -0800
Subject: RFR [13] JDK-8219990, Backout JDK-8219658
Message-ID: <dac447c3-6645-0a40-75b7-f2f82712b72e@oracle.com>

Hi Daniel,

Could I have a review of the following update:
    http://cr.openjdk.java.net/~xuelei/8219990/webrev.00/

The update in the previous fix:
    http://cr.openjdk.java.net/~xuelei/8219658/webrev.00/
is causing other thread safe problems.  I would look for a new solution 
for the deadlock issue.

Thanks,
Xuelei

From daniel.fuchs at oracle.com  Fri Mar  1 17:23:27 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 1 Mar 2019 17:23:27 +0000
Subject: RFR [13] JDK-8219990, Backout JDK-8219658
In-Reply-To: <dac447c3-6645-0a40-75b7-f2f82712b72e@oracle.com>
References: <dac447c3-6645-0a40-75b7-f2f82712b72e@oracle.com>
Message-ID: <2bbfddc8-8d3c-4e03-214e-9991266354c8@oracle.com>

Looks good to me Xuelei!

Thanks for taking this on.

best regards,

-- daniel

On 01/03/2019 16:54, Xuelei Fan wrote:
> Hi Daniel,
> 
> Could I have a review of the following update:
>  ?? http://cr.openjdk.java.net/~xuelei/8219990/webrev.00/
> 
> The update in the previous fix:
>  ?? http://cr.openjdk.java.net/~xuelei/8219658/webrev.00/
> is causing other thread safe problems.? I would look for a new solution 
> for the deadlock issue.
> 
> Thanks,
> Xuelei


From xuelei.fan at oracle.com  Fri Mar  1 19:17:23 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 1 Mar 2019 11:17:23 -0800
Subject: RFR [13] JDK-8219994: CheckSecurityProvider.java fails with
 unexpected sun.security.ssl.SunJSSE
Message-ID: <e77b265f-23ca-5fea-3c37-17b0756512ef@oracle.com>

Hi,

Could I have the following update reviewed?
   http://cr.openjdk.java.net/~xuelei/8219994/webrev.00/

In my previous update for JDK-8215430 (removing the internal 
com.sun.net.ssl package), I missed to update 
java/lang/SecurityManager/CheckSecurityProvider.java to use the revised 
provider name.

Thanks,
Xuelei

From sean.mullan at oracle.com  Fri Mar  1 19:45:59 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 1 Mar 2019 14:45:59 -0500
Subject: RFR [13] JDK-8219994: CheckSecurityProvider.java fails with
 unexpected sun.security.ssl.SunJSSE
In-Reply-To: <e77b265f-23ca-5fea-3c37-17b0756512ef@oracle.com>
References: <e77b265f-23ca-5fea-3c37-17b0756512ef@oracle.com>
Message-ID: <640b6e9c-96d0-4dc8-441a-d65241df4a65@oracle.com>

Looks good.

--Sean

On 3/1/19 2:17 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I have the following update reviewed?
>  ? http://cr.openjdk.java.net/~xuelei/8219994/webrev.00/
> 
> In my previous update for JDK-8215430 (removing the internal 
> com.sun.net.ssl package), I missed to update 
> java/lang/SecurityManager/CheckSecurityProvider.java to use the revised 
> provider name.
> 
> Thanks,
> Xuelei

From bradford.wetmore at oracle.com  Fri Mar  1 20:19:12 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 1 Mar 2019 12:19:12 -0800
Subject: RFR [13] JDK-8219994: CheckSecurityProvider.java fails with
 unexpected sun.security.ssl.SunJSSE
In-Reply-To: <640b6e9c-96d0-4dc8-441a-d65241df4a65@oracle.com>
References: <e77b265f-23ca-5fea-3c37-17b0756512ef@oracle.com>
 <640b6e9c-96d0-4dc8-441a-d65241df4a65@oracle.com>
Message-ID: <ffa04610-edc5-d602-633c-7ffa237170fd@oracle.com>

Ditto.

Brad


On 3/1/2019 11:45 AM, Sean Mullan wrote:
> Looks good.
> 
> --Sean
> 
> On 3/1/19 2:17 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I have the following update reviewed?
>> ?? http://cr.openjdk.java.net/~xuelei/8219994/webrev.00/
>>
>> In my previous update for JDK-8215430 (removing the internal 
>> com.sun.net.ssl package), I missed to update 
>> java/lang/SecurityManager/CheckSecurityProvider.java to use the 
>> revised provider name.
>>
>> Thanks,
>> Xuelei

From weijun.wang at oracle.com  Mon Mar  4 03:32:02 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 4 Mar 2019 11:32:02 +0800
Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK
 11
In-Reply-To: <da254096-8a75-09b5-3436-21d4e1d53d33@oracle.com>
References: <da254096-8a75-09b5-3436-21d4e1d53d33@oracle.com>
Message-ID: <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com>

Two questions:

1. There is no DOMCryptoBinary.java. Maybe you forgot "hg add"?

2. The Base64 class is called directly in several places. Aren't the helper methods in XMLUtils enough?

Thanks,
Max

> On Feb 26, 2019, at 4:46 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> In JDK 11, we included an updated version of Apache Santuario (which the JDK XML Signature implementation is based on) [1]. This contained a newer XML marshalling implementation, which has caused a couple of serious regressions (this one and JDK-8218629 [2]).
> 
> After unsuccessfully trying to patch the current implementation, we decided to back it out and restore the previous code, which had been very stable for many years. The newer implementation is different in subtle ways and doesn't really offer any advantages other than a bit of reduction in lines of code. The Apache Santuario Project also has backed out the implementation.
> 
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8217878
> 
> New test cases have also been added for the regressions.
> 
> Note that this also fixes JDK-8218629 [2]. Since technically they are different issues, I will probably include both bug-ids in this changeset.
> 
> --Sean
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8177334
> [2] https://bugs.openjdk.java.net/browse/JDK-8218629


From sean.mullan at oracle.com  Mon Mar  4 13:33:32 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 4 Mar 2019 08:33:32 -0500
Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK
 11
In-Reply-To: <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com>
References: <da254096-8a75-09b5-3436-21d4e1d53d33@oracle.com>
 <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com>
Message-ID: <0b3c3107-b9e4-baa6-a1c6-24b32f9a4e7a@oracle.com>

On 3/3/19 10:32 PM, Weijun Wang wrote:
> Two questions:
> 
> 1. There is no DOMCryptoBinary.java. Maybe you forgot "hg add"?

Yes, I did. I will add it.

> 2. The Base64 class is called directly in several places. Aren't the helper methods in XMLUtils enough?

Good catch, since that code is not using XMLUtils, it is not checking 
the linebreaks property to see if linebreaks should be inserted 
(com.sun.org.apache.xml.internal.security.ignoreLineBreaks). Let me fix 
that to use XMLUtils and I'll follow up with another webrev.

Thanks,
Sean

> 
> Thanks,
> Max
> 
>> On Feb 26, 2019, at 4:46 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> In JDK 11, we included an updated version of Apache Santuario (which the JDK XML Signature implementation is based on) [1]. This contained a newer XML marshalling implementation, which has caused a couple of serious regressions (this one and JDK-8218629 [2]).
>>
>> After unsuccessfully trying to patch the current implementation, we decided to back it out and restore the previous code, which had been very stable for many years. The newer implementation is different in subtle ways and doesn't really offer any advantages other than a bit of reduction in lines of code. The Apache Santuario Project also has backed out the implementation.
>>
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/
>> bug: https://bugs.openjdk.java.net/browse/JDK-8217878
>>
>> New test cases have also been added for the regressions.
>>
>> Note that this also fixes JDK-8218629 [2]. Since technically they are different issues, I will probably include both bug-ids in this changeset.
>>
>> --Sean
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8177334
>> [2] https://bugs.openjdk.java.net/browse/JDK-8218629
> 

From adam.petcher at oracle.com  Mon Mar  4 19:40:34 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Mon, 4 Mar 2019 14:40:34 -0500
Subject: RFR 8147502: Digest is incorrectly truncated for ECDSA signatures...
Message-ID: <89a71a98-52a1-dcdb-f4f4-85e1c5c065dd@oracle.com>

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

Please review this fix to a bug that causes ECDSA signatures to be 
incorrect in some cases. The fix is simple, but testing this issue is 
difficult because the API doesn't give access to the raw signing 
operation so we can check it using known answer tests. I got around this 
difficulty in the regression test by using a modified SecureRandom that 
supplies specific bits in order to produce the correct nonce. The test 
is a bit complicated and brittle, so if anyone has any other suggestions 
on how to do this, please share.


From sean.mullan at oracle.com  Mon Mar  4 20:11:13 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 4 Mar 2019 15:11:13 -0500
Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK
 11
In-Reply-To: <0b3c3107-b9e4-baa6-a1c6-24b32f9a4e7a@oracle.com>
References: <da254096-8a75-09b5-3436-21d4e1d53d33@oracle.com>
 <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com>
 <0b3c3107-b9e4-baa6-a1c6-24b32f9a4e7a@oracle.com>
Message-ID: <bdb3a6e3-c76f-e326-0f8d-d92eb1ceada3@oracle.com>

Updated webrev: 
http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.01/

Changes:

   - Added DOMCryptoBinary.java
   - Changed Base64 calls to XMLUtils in DOMKeyValue, DOMPGPData, 
DOMReference, DOMSignedInfo, DOMX509Data, and DOMXMLSignature

Thanks,
Sean

On 3/4/19 8:33 AM, Sean Mullan wrote:
> On 3/3/19 10:32 PM, Weijun Wang wrote:
>> Two questions:
>>
>> 1. There is no DOMCryptoBinary.java. Maybe you forgot "hg add"?
> 
> Yes, I did. I will add it.
> 
>> 2. The Base64 class is called directly in several places. Aren't the 
>> helper methods in XMLUtils enough?
> 
> Good catch, since that code is not using XMLUtils, it is not checking 
> the linebreaks property to see if linebreaks should be inserted 
> (com.sun.org.apache.xml.internal.security.ignoreLineBreaks). Let me fix 
> that to use XMLUtils and I'll follow up with another webrev.
> 
> Thanks,
> Sean
> 
>>
>> Thanks,
>> Max
>>
>>> On Feb 26, 2019, at 4:46 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>
>>> In JDK 11, we included an updated version of Apache Santuario (which 
>>> the JDK XML Signature implementation is based on) [1]. This contained 
>>> a newer XML marshalling implementation, which has caused a couple of 
>>> serious regressions (this one and JDK-8218629 [2]).
>>>
>>> After unsuccessfully trying to patch the current implementation, we 
>>> decided to back it out and restore the previous code, which had been 
>>> very stable for many years. The newer implementation is different in 
>>> subtle ways and doesn't really offer any advantages other than a bit 
>>> of reduction in lines of code. The Apache Santuario Project also has 
>>> backed out the implementation.
>>>
>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8217878
>>>
>>> New test cases have also been added for the regressions.
>>>
>>> Note that this also fixes JDK-8218629 [2]. Since technically they are 
>>> different issues, I will probably include both bug-ids in this 
>>> changeset.
>>>
>>> --Sean
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8177334
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8218629
>>

From norman.maurer at googlemail.com  Mon Mar  4 20:15:08 2019
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Mon, 4 Mar 2019 21:15:08 +0100
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
Message-ID: <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>

Any comments here ?

Bye
Norman


> On 28. Feb 2019, at 09:24, Norman Maurer <norman.maurer at googlemail.com> wrote:
> 
> Hi all,
> 
> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho.
> 
> I pushed a reproducer for this here:
> 
> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug <https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug>
> 
> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions.
> 
> Here is the Java version I used to reproduce:
> 
> # java -version
> openjdk version "12" 2019-03-19
> OpenJDK Runtime Environment (build 12+33)
> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
> 
> 
> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version:
> 
> #java -version
> openjdk version "12-ea" 2019-03-19
> OpenJDK Runtime Environment (build 12-ea+27)
> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
> 
> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/
> 
> Thanks
> Norman
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190304/f4594be1/attachment.html>

From weijun.wang at oracle.com  Tue Mar  5 00:26:41 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 5 Mar 2019 08:26:41 +0800
Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain
 java tests
In-Reply-To: <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com>
References: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com>
 <1550223285.2497.12.camel@paratix.ch>
 <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com>
Message-ID: <B5E5C972-8C01-42B6-8CD7-500B2AF99A7F@oracle.com>

Webrev updated at

   https://cr.openjdk.java.net/~weijun/8180573/webrev.01

BTW, last time I mistakenly removed ExportPrivateKeyNoPwd.java which is used by ListKeychainStore.sh. It's now back.

Thanks,
Max

> On Feb 15, 2019, at 9:31 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Hi Philipp,
> 
> In most cases, it's just about creating a non-empty file; in some case, the content is relevant. For the former, I will change it to something like "new byte[10]"; for the latter, I'll use getBytes(UTF_8).
> 
> Thanks,
> Max
> 
> 
>> On Feb 15, 2019, at 5:34 PM, Philipp Kunz <philipp.kunz at paratix.ch> wrote:
>> 
>> Hi Max,
>> 
>> I don't know if it is important enough, certainly not a serious issue.
>> In your patch, for example in DiffEnd.java and a few other tests, Strings are encoded to byte streams with String.getBytes() which uses the default platform character set to encode the strings.
>> Manifests, however, always use UTF-8 as the character set to encode. In my opinion, getBytes(java.nio.charset.StandardCharsets.UTF_8) would be appropriate to specify the encoding in a platform-independent way.
>> Now the manifests used in the tests use so few different characters that this might not even make a real difference because the first around 100 characters or so of most character sets are the same in most encodings.
>> I suspect that the encoding might also have been platform-dependent in at least some of the previous shell tests and therefore this aspect might as well be addressed separately and is not strictly necessary to just properly convert shell tests to java.
>> 
>> Regards,
>> Philipp
>> 
>> 
>> On Wed, 2019-02-13 at 11:01 +0800, Weijun Wang wrote:
>>> Please review the fix at
>>> 
>>> 
>>> https://cr.openjdk.java.net/~weijun/8180573/webrev.00/
>>> 
>>> 
>>> Notes:
>>> 
>>> - Most changes are just .sh -> .java
>>> 
>>> - StorePasswordsByShell.sh combined into StorePasswords.java
>>> 
>>> - In most cases, JarUtils is called to create a jar file. Sometimes the jar command is called because of delicate differences, for example, jar adds directory entries also.
>>> 
>>> - The i18n tests are completely manual described in i18n.html. Old i18n.java is useless, now is also empty.
>>> 
>>> - Copyright year updated to 2019, @bug unchanged.
>>> 
>>> Two files not converted yet:
>>> 
>>> - ./keytool/console.sh
>>> 
>>> This is a manual test calling old versions of JDK.
>>> 
>>> - ./keytool/ListKeychainStore.sh
>>> 
>>> I tried on this one but "security list-keychains -s ..." has no effect on mach5 machines when calling by ProcessTools. No idea why, I've created a separate bug (JDK-8218886) for it.
>>> 
>>> Thanks,
>>> Max
>>> 
>>> 
> 


From weijun.wang at oracle.com  Tue Mar  5 03:06:03 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 5 Mar 2019 11:06:03 +0800
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
 SequenceInputStream
Message-ID: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com>

Please take a review at

   https://cr.openjdk.java.net/~weijun/8157404/webrev.00/

When Java finds out data is not enough while resolving a BER, it reads in more data and try converting again. Please note that calling available() again after readNBytes is not reliable because it might return zero even if there are more bytes.

A more efficient fix could be rewriting the convert logic to use the stream directly (parsing while reading), and thus avoid the need to call the whole convertBytes method again, but that's a big change and there is a risk getting wrong somewhere. This fix is likely to be backported to older LTS releases.

Note this could block but it should only happen when data is not enough, and it only reads one byte. 

The test included in the bug report passed, but I'll see if I can write a new test not depending on any existing binary data.

And I'm running a mach5 test job now.

Thanks,
Max


From weijun.wang at oracle.com  Tue Mar  5 03:23:22 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 5 Mar 2019 11:23:22 +0800
Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK
 11
In-Reply-To: <bdb3a6e3-c76f-e326-0f8d-d92eb1ceada3@oracle.com>
References: <da254096-8a75-09b5-3436-21d4e1d53d33@oracle.com>
 <637BDC6E-2999-41A1-82C2-F0AFB90881DC@oracle.com>
 <0b3c3107-b9e4-baa6-a1c6-24b32f9a4e7a@oracle.com>
 <bdb3a6e3-c76f-e326-0f8d-d92eb1ceada3@oracle.com>
Message-ID: <FF54EF59-1E0B-4105-9774-0A73B4E460D4@oracle.com>

Everything is fine now.

Thanks,
Max

> On Mar 5, 2019, at 4:11 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Updated webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.01/
> 
> Changes:
> 
>  - Added DOMCryptoBinary.java
>  - Changed Base64 calls to XMLUtils in DOMKeyValue, DOMPGPData, DOMReference, DOMSignedInfo, DOMX509Data, and DOMXMLSignature
> 
> Thanks,
> Sean
> 
> On 3/4/19 8:33 AM, Sean Mullan wrote:
>> On 3/3/19 10:32 PM, Weijun Wang wrote:
>>> Two questions:
>>> 
>>> 1. There is no DOMCryptoBinary.java. Maybe you forgot "hg add"?
>> Yes, I did. I will add it.
>>> 2. The Base64 class is called directly in several places. Aren't the helper methods in XMLUtils enough?
>> Good catch, since that code is not using XMLUtils, it is not checking the linebreaks property to see if linebreaks should be inserted (com.sun.org.apache.xml.internal.security.ignoreLineBreaks). Let me fix that to use XMLUtils and I'll follow up with another webrev.
>> Thanks,
>> Sean
>>> 
>>> Thanks,
>>> Max
>>> 
>>>> On Feb 26, 2019, at 4:46 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>> 
>>>> In JDK 11, we included an updated version of Apache Santuario (which the JDK XML Signature implementation is based on) [1]. This contained a newer XML marshalling implementation, which has caused a couple of serious regressions (this one and JDK-8218629 [2]).
>>>> 
>>>> After unsuccessfully trying to patch the current implementation, we decided to back it out and restore the previous code, which had been very stable for many years. The newer implementation is different in subtle ways and doesn't really offer any advantages other than a bit of reduction in lines of code. The Apache Santuario Project also has backed out the implementation.
>>>> 
>>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8217878
>>>> 
>>>> New test cases have also been added for the regressions.
>>>> 
>>>> Note that this also fixes JDK-8218629 [2]. Since technically they are different issues, I will probably include both bug-ids in this changeset.
>>>> 
>>>> --Sean
>>>> 
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8177334
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8218629
>>> 


From Nico.Williams at twosigma.com  Tue Mar  5 18:57:43 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Tue, 5 Mar 2019 18:57:43 +0000
Subject: JGSS Enhancements (contribution by Two Sigma Open Source)
In-Reply-To: <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com>
References: <20181002230433.GU703@twosigma.com>
 <e44b9ddf-da37-ebab-e845-048b0b9d3a6f@oracle.com>
 <20181003204928.GA26310@twosigma.com>
 <fcf57680-2197-d413-5c87-ce57a5fd79a5@oracle.com>
 <20181004171547.GE26310@twosigma.com>
 <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com>
 <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com>
Message-ID: <20190305185743.GA9177@twosigma.com>

On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote:
> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/.

Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub
clone:

    https://github.com/twosigma/OpenJDK/pull/1

Nico
-- 

From sean.mullan at oracle.com  Tue Mar  5 19:53:17 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 5 Mar 2019 14:53:17 -0500
Subject: RFR [13]: 8218618: Program fails when using JDK addressed by UNC path
 and using Security Manager
Message-ID: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com>

Please review this fix to a regression introduced in JDK 9. An 
application run with a SecurityManager and using a JDK that is accessed 
over the network using a UNC path fails to startup and throws an 
InternalError.

The fix is to load default.policy as a regular File rather than a URL 
(URLs are only necessary for policy files configured in the 
java.security file). No regression test because it involves a manual 
setup (noreg-hard).

webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/
bugid: https://bugs.openjdk.java.net/browse/JDK-8218618

--Sean

From Alan.Bateman at oracle.com  Tue Mar  5 19:55:41 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 5 Mar 2019 19:55:41 +0000
Subject: JGSS Enhancements (contribution by Two Sigma Open Source)
In-Reply-To: <20190305185743.GA9177@twosigma.com>
References: <20181002230433.GU703@twosigma.com>
 <e44b9ddf-da37-ebab-e845-048b0b9d3a6f@oracle.com>
 <20181003204928.GA26310@twosigma.com>
 <fcf57680-2197-d413-5c87-ce57a5fd79a5@oracle.com>
 <20181004171547.GE26310@twosigma.com>
 <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com>
 <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com>
 <20190305185743.GA9177@twosigma.com>
Message-ID: <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com>

On 05/03/2019 18:57, Nico Williams wrote:
> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote:
>> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/.
> Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub
> clone:
>
Sorry, code reviews and discussions of patches for OpenJDK need to be 
use the OpenJDK mailing lists.

-Alan

From weijun.wang at oracle.com  Wed Mar  6 00:39:45 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 6 Mar 2019 08:39:45 +0800
Subject: JGSS Enhancements (contribution by Two Sigma Open Source)
In-Reply-To: <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com>
References: <20181002230433.GU703@twosigma.com>
 <e44b9ddf-da37-ebab-e845-048b0b9d3a6f@oracle.com>
 <20181003204928.GA26310@twosigma.com>
 <fcf57680-2197-d413-5c87-ce57a5fd79a5@oracle.com>
 <20181004171547.GE26310@twosigma.com>
 <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com>
 <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com>
 <20190305185743.GA9177@twosigma.com>
 <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com>
Message-ID: <D0562FC5-3B69-44CF-9BB8-F533D3F1E66D@oracle.com>



> On Mar 6, 2019, at 3:55 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 05/03/2019 18:57, Nico Williams wrote:
>> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote:
>>> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/.
>> Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub
>> clone:
>> 
> Sorry, code reviews and discussions of patches for OpenJDK need to be use the OpenJDK mailing lists.

Yes, this is the rule.

Also, I'm not sure what Peter is reviewing here as the title is not clear to me. Is it about all patches you are contributing? Or is it about the OpenJDK bugs we have already filed (which is only the first few steps of the big contribution)?. You are OK to discuss any change you are preparing to contribute anywhere, but once you decide to contribute a piece of code into OpenJDK, please follow these steps:

1. File a bug or RFE (If you cannot do that, ask me).

2. Post the patch on cr.openjdk.java.net and ask security-dev at o.j.n for code review, or the patch is short, include it in the mail.

3. Anyone can reply the mail.

You might heard there is a effort [1] going on about switching to another SCM or hosting service, but not now yet.

Thanks,
Max

[1] https://openjdk.java.net/projects/skara/

> 
> -Alan


From weijun.wang at oracle.com  Wed Mar  6 00:50:36 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 6 Mar 2019 08:50:36 +0800
Subject: RFR [13]: 8218618: Program fails when using JDK addressed by UNC
 path and using Security Manager
In-Reply-To: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com>
References: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com>
Message-ID: <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com>

The fix looks fine to me.

However, is PolicyUtil::getInputStream correct? Will it cause any problem when a UNC path is used in -Djava.security.policy?

I've seen several code changes around UNC recently. Wonder if we've finally fix it and PolicyUtil::getInputStream can always call url.openStream() now. I've added core-libs-dev at o.j.n, maybe someone there can give a clear answer.

Thanks,
Max

> On Mar 6, 2019, at 3:53 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Please review this fix to a regression introduced in JDK 9. An application run with a SecurityManager and using a JDK that is accessed over the network using a UNC path fails to startup and throws an InternalError.
> 
> The fix is to load default.policy as a regular File rather than a URL (URLs are only necessary for policy files configured in the java.security file). No regression test because it involves a manual setup (noreg-hard).
> 
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/
> bugid: https://bugs.openjdk.java.net/browse/JDK-8218618
> 
> --Sean


From Nico.Williams at twosigma.com  Wed Mar  6 02:09:46 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Wed, 6 Mar 2019 02:09:46 +0000
Subject: JGSS Enhancements (contribution by Two Sigma Open Source)
In-Reply-To: <D0562FC5-3B69-44CF-9BB8-F533D3F1E66D@oracle.com>
References: <20181002230433.GU703@twosigma.com>
 <e44b9ddf-da37-ebab-e845-048b0b9d3a6f@oracle.com>
 <20181003204928.GA26310@twosigma.com>
 <fcf57680-2197-d413-5c87-ce57a5fd79a5@oracle.com>
 <20181004171547.GE26310@twosigma.com>
 <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com>
 <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com>
 <20190305185743.GA9177@twosigma.com>
 <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com>
 <D0562FC5-3B69-44CF-9BB8-F533D3F1E66D@oracle.com>
Message-ID: <20190306020946.GC9177@twosigma.com>

On Wed, Mar 06, 2019 at 08:39:45AM +0800, Weijun Wang wrote:
> > On 05/03/2019 18:57, Nico Williams wrote:
> >> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote:
> >>> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/.
> >> Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub
> >> clone:
> >> 
> > Sorry, code reviews and discussions of patches for OpenJDK need to be use the OpenJDK mailing lists.
> 
> Yes, this is the rule.

That's fair.

> Also, I'm not sure what Peter is reviewing here as the title is not clear to
> me. Is it about all patches you are contributing? Or is it about the OpenJDK

Yes.

> bugs we have already filed (which is only the first few steps of the big
> contribution)?. You are OK to discuss any change you are preparing to
> contribute anywhere, but once you decide to contribute a piece of code into
> OpenJDK, please follow these steps:

We did decide to make a contribution.  I thought your making a webrev
for it, and my being approved to be a contributor, kickstarted the
process.

> 1. File a bug or RFE (If you cannot do that, ask me).

How?

> 2. Post the patch on cr.openjdk.java.net and ask security-dev at o.j.n
> for code review, or the patch is short, include it in the mail.

You did the first part.  I did the second.

> 3. Anyone can reply the mail.

So Peter, for example, doesn't need to be a contributor?

> You might heard there is a effort [1] going on about switching to
> another SCM or hosting service, but not now yet.

Right, GitHub is sure a lot more convenient than webrevs.

Nico
-- 

From weijun.wang at oracle.com  Wed Mar  6 02:24:50 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 6 Mar 2019 10:24:50 +0800
Subject: JGSS Enhancements (contribution by Two Sigma Open Source)
In-Reply-To: <20190306020946.GC9177@twosigma.com>
References: <20181002230433.GU703@twosigma.com>
 <e44b9ddf-da37-ebab-e845-048b0b9d3a6f@oracle.com>
 <20181003204928.GA26310@twosigma.com>
 <fcf57680-2197-d413-5c87-ce57a5fd79a5@oracle.com>
 <20181004171547.GE26310@twosigma.com>
 <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com>
 <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com>
 <20190305185743.GA9177@twosigma.com>
 <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com>
 <D0562FC5-3B69-44CF-9BB8-F533D3F1E66D@oracle.com>
 <20190306020946.GC9177@twosigma.com>
Message-ID: <B6B0E4D2-CE46-4EC2-AFDC-B4695ECF375E@oracle.com>



> On Mar 6, 2019, at 10:09 AM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> 
> On Wed, Mar 06, 2019 at 08:39:45AM +0800, Weijun Wang wrote:
>>> On 05/03/2019 18:57, Nico Williams wrote:
>>>> On Mon, Oct 08, 2018 at 12:35:33PM +0800, Weijun Wang wrote:
>>>>> All patches are posted to http://cr.openjdk.java.net/~weijun/twosigma-gss/.
>>>> Peter Burka (cc'ed), of Two Sigma, did a code review using our GitHub
>>>> clone:
>>>> 
>>> Sorry, code reviews and discussions of patches for OpenJDK need to be use the OpenJDK mailing lists.
>> 
>> Yes, this is the rule.
> 
> That's fair.
> 
>> Also, I'm not sure what Peter is reviewing here as the title is not clear to
>> me. Is it about all patches you are contributing? Or is it about the OpenJDK
> 
> Yes.
> 
>> bugs we have already filed (which is only the first few steps of the big
>> contribution)?. You are OK to discuss any change you are preparing to
>> contribute anywhere, but once you decide to contribute a piece of code into
>> OpenJDK, please follow these steps:
> 
> We did decide to make a contribution.  I thought your making a webrev
> for it, and my being approved to be a contributor, kickstarted the
> process.
> 
>> 1. File a bug or RFE (If you cannot do that, ask me).
> 
> How?

Tell me the title and description of the bug/RFE, and I'll create one like https://bugs.openjdk.java.net/browse/JDK-8212217.

> 
>> 2. Post the patch on cr.openjdk.java.net and ask security-dev at o.j.n
>> for code review, or the patch is short, include it in the mail.
> 
> You did the first part.  I did the second.

You're an author now, right? You can post one yourself, webrev is at https://hg.openjdk.java.net/code-tools/webrev.

If see see any problem, you can always send me a patch and I can post a webrev.

Anyway we need to do this one by one.

> 
>> 3. Anyone can reply the mail.
> 
> So Peter, for example, doesn't need to be a contributor?

Anyone can reply, but to push the change, a formal openjdk reviewer is needed.

If Peter rewrite the patch in total then he might need to sign the OCA.

> 
>> You might heard there is a effort [1] going on about switching to
>> another SCM or hosting service, but not now yet.
> 
> Right, GitHub is sure a lot more convenient than webrevs.

Hope so, but I do switch between the udiff, sdiff, frames and new views of webrev a lot. It's not very friendly to comment of course.

--Max

> 
> Nico
> -- 


From sgehwolf at redhat.com  Wed Mar  6 09:55:04 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 06 Mar 2019 10:55:04 +0100
Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o
 shutdown
In-Reply-To: <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com>
References: <CAAcXADf9cy+vwSP36hj5A=dMwhdS8ou_VxDW+_h4x1WrLpD6hw@mail.gmail.com>
 <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com>
Message-ID: <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com>

On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
> It looks like this is JDK-8214418 - which has been fixed
> in 12.0.1 b03 and 13-ea b04.

Is there any reason why JDK-8214418 is not public?

"You can't view this issue"

Thanks,
Severin


From sean.mullan at oracle.com  Wed Mar  6 18:32:19 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 6 Mar 2019 13:32:19 -0500
Subject: CSR Review Request, JDK-8163326, The default enabled cipher
 suites should prefer forward secrecy
In-Reply-To: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com>
References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com>
Message-ID: <ad81eda1-e411-cd8f-0c0d-eab7efa8a1d4@oracle.com>

Hi Xuelei,

In the Specification section, I think it would be useful to note which 
cipher suites are forward secret and which are not. Otherwise, it is 
difficult to see what has changed, since there are so many supported 
suites. Perhaps in parentheses, ex:

TLS_AES_128_GCM_SHA256 (forward secret)
...

I also think you should summarize what has changed or what is roughly 
the new order, for example:

- The TLS_RSA suites have moved down ...
- The TLS_ECDH suites have moved
- The SSL_RSA suites have moved down ...
etc...

--Sean

On 2/21/19 4:45 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the CSR reviewed?
>  ??? https://bugs.openjdk.java.net/browse/JDK-8219545
> 
> It is proposed to increase the priority of forward secrecy cipher 
> suites, and decrease the priority of RSA key exchange based cipher 
> suites for the default enabled cipher suites in the SunJSSE provider.
> 
> Thanks,
> Xuelei

From sean.mullan at oracle.com  Wed Mar  6 20:50:15 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 6 Mar 2019 15:50:15 -0500
Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o
 shutdown
In-Reply-To: <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com>
References: <CAAcXADf9cy+vwSP36hj5A=dMwhdS8ou_VxDW+_h4x1WrLpD6hw@mail.gmail.com>
 <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com>
 <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com>
Message-ID: <4b61df3f-a85f-908e-9a77-062381b4fdac@oracle.com>

On 3/6/19 4:55 AM, Severin Gehwolf wrote:
> On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
>> It looks like this is JDK-8214418 - which has been fixed
>> in 12.0.1 b03 and 13-ea b04.
> 
> Is there any reason why JDK-8214418 is not public?
> 
> "You can't view this issue"

There are internal hostnames and ip addresses and other potentially 
sensitive content in the bug description (it was a dump of a test log). 
I think we would have to remove that sensitive information and copy it 
into a new bug otherwise it would still be in the bug history if we made 
it public. Doesn't seem worth it at this point since it is already fixed.

--Sean

From anthony.scarpino at oracle.com  Wed Mar  6 23:04:25 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 6 Mar 2019 15:04:25 -0800
Subject: RFR [13] 8220165: Encryption using GCM results in RuntimeException-
 input length out of bound
Message-ID: <eb27ea8a-2cca-6d5b-73cf-39b1e7659248@oracle.com>

Hi

Can I get a review of a simple fix to the previous GCM change that got 
the lengths wrong on large data sizes.  I thought I covered this in my 
original testing, but I guess not.  So with this I created a test to 
check larger data sizes and different byte lengths

http://cr.openjdk.java.net/~ascarpino/8220165/

Tony


From ecki at zusammenkunft.net  Wed Mar  6 23:41:42 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 6 Mar 2019 23:41:42 +0000
Subject: CSR Review Request, JDK-8163326, The default enabled cipher
 suites should prefer forward secrecy
In-Reply-To: <ad81eda1-e411-cd8f-0c0d-eab7efa8a1d4@oracle.com>
References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com>,
 <ad81eda1-e411-cd8f-0c0d-eab7efa8a1d4@oracle.com>
Message-ID: <DB7PR08MB3307B541FB88E30ECEA81792FF730@DB7PR08MB3307.eurprd08.prod.outlook.com>

I am not clear on what would ?preferred in current default context? mean. Does that mean it preferred the PFS ciphers anyway.. for suggested order in client handshake? as server? And what would be the non-Default context. Is this ?TLS? context?

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: security-dev <security-dev-bounces at openjdk.java.net> im Auftrag von Sean Mullan <sean.mullan at oracle.com>
Gesendet: Mittwoch, M?rz 6, 2019 9:12 PM
An: security-dev at openjdk.java.net
Betreff: Re: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy

Hi Xuelei,

In the Specification section, I think it would be useful to note which
cipher suites are forward secret and which are not. Otherwise, it is
difficult to see what has changed, since there are so many supported
suites. Perhaps in parentheses, ex:

TLS_AES_128_GCM_SHA256 (forward secret)
...

I also think you should summarize what has changed or what is roughly
the new order, for example:

- The TLS_RSA suites have moved down ...
- The TLS_ECDH suites have moved
- The SSL_RSA suites have moved down ...
etc...

--Sean

On 2/21/19 4:45 PM, Xuelei Fan wrote:
> Hi,
>
> Could I get the CSR reviewed?
>     https://bugs.openjdk.java.net/browse/JDK-8219545
>
> It is proposed to increase the priority of forward secrecy cipher
> suites, and decrease the priority of RSA key exchange based cipher
> suites for the default enabled cipher suites in the SunJSSE provider.
>
> Thanks,
> Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190306/949aead2/attachment.html>

From valerie.peng at oracle.com  Thu Mar  7 02:52:05 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 6 Mar 2019 18:52:05 -0800
Subject: RFR [13] 8220165: Encryption using GCM results in
 RuntimeException- input length out of bound
In-Reply-To: <eb27ea8a-2cca-6d5b-73cf-39b1e7659248@oracle.com>
References: <eb27ea8a-2cca-6d5b-73cf-39b1e7659248@oracle.com>
Message-ID: <08774412-e6ac-cda4-cce7-2cb7c7f92fca@oracle.com>

Hi Tony,

Source change looks fine.

For the regression test GCMLargeDataKAT.java
1) typo on line 42, "has" -> "hash".
2) Line 128, we should also check result.length to be the expected 
value, i.e. data.length - GCM_TAG_LENGTH.
3) Currently, the test continues even if enc check failed (line149-155). 
If the enc result is incorrect, why proceed with decryption? Perhaps, 
testing against the next key (i.e. data length) after line 155?
4) Remove line 184-189 as they are not used?
5) line 195, no need for this being public?
6) Are 65536, 65537 and 67584 input sizes add additional coverage? For 
data sizes 102400 to 102416, they can easily be tested with two byte[]s, 
sizes 102400 and 16.
Thanks,
Valerie
On 3/6/2019 3:04 PM, Anthony Scarpino wrote:
> Hi
>
> Can I get a review of a simple fix to the previous GCM change that got 
> the lengths wrong on large data sizes.? I thought I covered this in my 
> original testing, but I guess not.? So with this I created a test to 
> check larger data sizes and different byte lengths
>
> http://cr.openjdk.java.net/~ascarpino/8220165/
>
> Tony
>

From andimullaraj at gmail.com  Thu Mar  7 07:46:23 2019
From: andimullaraj at gmail.com (Andi Mullaraj)
Date: Wed, 6 Mar 2019 23:46:23 -0800
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
 <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
 <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>
Message-ID: <CADvBZ+3Ov=oL9d0OwpsCP_rOxwGrmkufF_8j989-6J6-aC+pOg@mail.gmail.com>

Hi again,

> That implies multiple threads using 1 selector ...

It definitely looks like we are talking about different things. You seem to
be talking about *how to use a Selector and encrypt/decrypt ssl and do it
in an efficient way in order to build some server or so*. I am talking
about *providing an SSLSelector (which agreed, would be wrapping a Selector
and handle the encrypt/decrypt) of the same exact
API/Semantics/Functionality as a Selector*.

I agree the implementation is super complex, that's why I keep swerving
away from implementation details. I agree with you that there is no point
in using one Selector (either flavor) from a multitude of threads, but
(since I am on the provider side) in order to claim the SSLSelector is a
true reflection of a Selector I have to provide a way to make it work even
when callers perform concurrent select() operations from various threads
(which normally results in the locks being acquired in the order defined in
the documentation). So yes,the implementation is even more complex than you
actually describe it, but doable and very performant as well.

So, trying to swerve back to the API discussion, I will re ask my last
question in a different way:  If you have developed an application which
communicates in TCP using java.nio.channels package classes (one Selector,
multiple SocketChannel, one or more threads, doesn't matter), and you
wanted to enhance your application to be able to communicate over SSL, what
would stop you from using an SSLSelector with SSLSocketChannels (just
import them, pass the SSLContext during the SSLSocketChannelCreation,
recompile and done)? *Restating that the implementation is in pure Java,
with no extra threads for selection, with minimal cpu and memory impact
(only for SSL channels) over the current implementation. What would prevent
someone from using it?*

Thanks again,
--Andi



On Tue, Feb 19, 2019 at 8:18 AM Dean Hiller <dhiller at twitter.com> wrote:

> I am beginning to think we might be on different pages here. Someone from
>> outside the selector calls selector.select(), and all selector's
>> functionality is handled within the context of the calling thread. So where
>> is the need for the extra thread here? More specifically, in the
>> SSLSelector case, a call to its select, ends up usually to a call to its
>> inner selector.select(), always in the context of the calling thread ... so
>> same thing again. Why do you think another thread is necessary here (within
>> the selector itself)?
>>
>
> That implies multiple threads using 1 selector.  That can be very
> dangerous and prone to bugs.  Even with SSL, I would shy away from making
> something like that unless putting it behind some library/abstraction like
> netty, webpieces channelmanager or something.
>
> In fact, the performance of 1 thread that runs the selector who dishes the
> work to a threadpool immediately (N sockets to X threads) has been
> amazing!!!  *It was even better than multiple threads on a selector we
> found.* This was because that caused lots of contention with
> locks(slowing it down).  The contention depended on the application as some
> apps had more contention than others.  I would highly advise just sticking
> 1 thread on the selector dishing out to a thread pool which removed all
> contention to streamline the whole process for speed.
>
> THEN, if you do have a threadpool and an simple implementation that runs
> the data serially per socket in the threadpool(this is quite easy to do),
> you can do the decryption in the threadpool as well.  webpieces impl does
> this as well.
>
> just my 2 cents,
> later,
>
> Dean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190306/929da8b6/attachment.html>

From daniel.fuchs at oracle.com  Thu Mar  7 10:59:36 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 7 Mar 2019 10:59:36 +0000
Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o
 shutdown
In-Reply-To: <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com>
References: <CAAcXADf9cy+vwSP36hj5A=dMwhdS8ou_VxDW+_h4x1WrLpD6hw@mail.gmail.com>
 <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com>
 <0f21cb9d50cc5ce935932bf5eb2e84fe2ebe9e32.camel@redhat.com>
Message-ID: <e96b0e29-13bb-386e-9d4e-037c5468f91f@oracle.com>

Hi Severin,

Yes - sorry about that - as Sean explained we had to keep
that bug report private.

However you should be able to find all the information about the
issue in the public review thread in the security-dev archive:

http://mail.openjdk.java.net/pipermail/security-dev/2018-December/019100.html
http://mail.openjdk.java.net/pipermail/security-dev/2019-January/019142.html

Hope this help,

-- daniel


On 06/03/2019 09:55, Severin Gehwolf wrote:
> On Mon, 2019-02-11 at 10:58 +0100, Daniel Fuchs wrote:
>> It looks like this is JDK-8214418 - which has been fixed
>> in 12.0.1 b03 and 13-ea b04.
> 
> Is there any reason why JDK-8214418 is not public?
> 
> "You can't view this issue"
> 
> Thanks,
> Severin
> 


From sean.mullan at oracle.com  Thu Mar  7 15:02:39 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 7 Mar 2019 10:02:39 -0500
Subject: RFR [13]: 8218618: Program fails when using JDK addressed by UNC
 path and using Security Manager
In-Reply-To: <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com>
References: <377c7db6-d5e6-0e1a-0659-0c2702d05f3b@oracle.com>
 <3EDE766D-F4BC-4924-849D-DE222924E6DC@oracle.com>
Message-ID: <d4787ae9-5014-961b-fb62-d57d51254620@oracle.com>

On 3/5/19 7:50 PM, Weijun Wang wrote:
> The fix looks fine to me.
> 
> However, is PolicyUtil::getInputStream correct? Will it cause any problem when a UNC path is used in -Djava.security.policy?

If you specify the UNC policy file as just a file pathname (and not a 
"file:" URL), ex:

-Djava.security.policy=\\host\Users\duke\java.policy

In this case, the Policy implementation converts the canonical form of 
the path into an encoded "file:" URL (see 
sun.net.www.ParseUtil.fileToEncodedURL) and the URL works when passed to 
PolicyUtil.getInputStream (which decodes it into a path and opens it 
with FileInputStream).

However, if you specify the UNC policy file as a "file:" URL, it depends 
on the user getting the proper URL encoding (escaped characters, etc) 
right. For example:

-Djava.security.policy=file:\\host\Users\duke\java.policy

will not work because it ignores the hostname and tries to load 
\Users\duke\java.policy. However:

-Djava.security.policy=file:\\\\host\Users\duke\java.policy

does work. I'm not entirely sure, but I think it has something to do 
with escaping the leading backslashes so that it is not considered a 
host part of the URL.

There's possibly some unnecessary overhead encoding the path into a URL 
and decoding back again, but I don't want to tinker with it unless there 
is a known issue.

--Sean

> 
> I've seen several code changes around UNC recently. Wonder if we've finally fix it and PolicyUtil::getInputStream can always call url.openStream() now. I've added core-libs-dev at o.j.n, maybe someone there can give a clear answer.
> 
> Thanks,
> Max
> 
>> On Mar 6, 2019, at 3:53 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> Please review this fix to a regression introduced in JDK 9. An application run with a SecurityManager and using a JDK that is accessed over the network using a UNC path fails to startup and throws an InternalError.
>>
>> The fix is to load default.policy as a regular File rather than a URL (URLs are only necessary for policy files configured in the java.security file). No regression test because it involves a manual setup (noreg-hard).
>>
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8218618/webrev.00/
>> bugid: https://bugs.openjdk.java.net/browse/JDK-8218618
>>
>> --Sean
> 

From anthony.scarpino at oracle.com  Thu Mar  7 18:25:46 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 7 Mar 2019 10:25:46 -0800
Subject: RFR [13] 8220165: Encryption using GCM results in
 RuntimeException- input length out of bound
In-Reply-To: <08774412-e6ac-cda4-cce7-2cb7c7f92fca@oracle.com>
References: <eb27ea8a-2cca-6d5b-73cf-39b1e7659248@oracle.com>
 <08774412-e6ac-cda4-cce7-2cb7c7f92fca@oracle.com>
Message-ID: <b301188b-552e-cda4-50b0-dd2d6bc6d7aa@oracle.com>

On 3/6/19 6:52 PM, Valerie Peng wrote:
> Hi Tony,
> 
> Source change looks fine.
> 
> For the regression test GCMLargeDataKAT.java
> 1) typo on line 42, "has" -> "hash".
> 2) Line 128, we should also check result.length to be the expected 
> value, i.e. data.length - GCM_TAG_LENGTH.

I had intentionally left a length check out figuring that a nulled 
plaintext would have to be the proper length, but I guess it worth to 
check the array was returned property

> 3) Currently, the test continues even if enc check failed (line149-155). 
> If the enc result is incorrect, why proceed with decryption? Perhaps, 
> testing against the next key (i.e. data length) after line 155?

Yeah, that's true.

> 4) Remove line 184-189 as they are not used?

It's used to create new data lengths if passed a length argument.  As I 
was able to do with your point #6.  In jtreg operation it is not used.

> 5) line 195, no need for this being public?

yep

> 6) Are 65536, 65537 and 67584 input sizes add additional coverage? For 
> data sizes 102400 to 102416, they can easily be tested with two byte[]s, 
> sizes 102400 and 16.

I chose them when I was debugging the problem and left them there.  I 
added a few more lengths around the AES block size.  64k is when the 
intrinsic warmup code starts, so anything above 65535 is equally 
relevant to test.  I used 102400 through 102416 just to cover every byte.

I also changed the plaintext to use one byte array instead of
encrypt(new byte[inLen])

new webrev:
http://cr.openjdk.java.net/~ascarpino/8220165/webrev.01/


> Thanks,
> Valerie
> On 3/6/2019 3:04 PM, Anthony Scarpino wrote:
>> Hi
>>
>> Can I get a review of a simple fix to the previous GCM change that got 
>> the lengths wrong on large data sizes.? I thought I covered this in my 
>> original testing, but I guess not.? So with this I created a test to 
>> check larger data sizes and different byte lengths
>>
>> http://cr.openjdk.java.net/~ascarpino/8220165/
>>
>> Tony
>>

From philipp.kunz at paratix.ch  Thu Mar  7 15:27:30 2019
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Thu, 07 Mar 2019 16:27:30 +0100
Subject: Jarsigner compatibility issue invalidating existing signatures
In-Reply-To: <AD5055BB-8844-4C95-B0EB-4AF7E7015CE3@oracle.com>
References: <1547972414.2363.9.camel@paratix.ch>
 <85CB8E69-66A9-4E28-BC93-3FD9DEE58E41@oracle.com>
 <1548019729.2363.13.camel@paratix.ch>
 <3B9DE791-9F08-4A45-9415-E311F516F947@oracle.com>
 <AD5055BB-8844-4C95-B0EB-4AF7E7015CE3@oracle.com>
Message-ID: <1551972450.2495.29.camel@paratix.ch>

Hi,

Following up [1], [2] and to some extent [3] find a new patch attached.

Apart from ManifestDigester having problems parsing manifests with \r
for the line break, manifests without a trailing blank line are not
processed correctly in all cases. As an example, look at the existing
diffend.sh test which produces a jar diffend.new.jar file with an
invalid signature on lines 88..93.?Jarsigner fails to detect this and
so does the test. The resulting manifest is missing a blank line after
the main attributes section and looks like this:

Manifest-Version: 1.0
Created-By: 1.7.0-internal (Sun Microsystems Inc.)
Today: Monday
Name: 1
SHA1-Digest: 5fpE8rMcH7VTtgIec2DQfV2R/14=

Another speciality is that endOfSection contains a blank line if and
only if that blank line is at the very end of the manifest file (or
stream or byte array). This makes digestWorkaround useless in that case
because digestWorkaround is then the same as digest without workaround.
Initially I thought, the missing lines after the last section could be
compensated by digestWorkaround which essentially produces a digest
without the trailing blank line but digestWorkaround is not applied to
main attributes and if successful would set
SignatureFileVerifier.workaround flag that would remain set for
subsequent digests which are processed in the order of the entries of
the signature file which is hard to predict and certainly does not
support to assume that the last manifest entry would be verified last.

As a starting point for further discussions, I'd like to suggest that
jarsigner keeps main attributes without a trailing blank line if there
are no files contained in the jar to sign. I wonder if this is worth it
but at least I believe that this is the most backwards-compatible
option possible. A trailing line is then added only when necessary and
the resulting jarfile would be invalid without as in the example above
with diffend.sh.

Any feedback and opinions welcome.

Regards,
Philipp


[1] https://mail.openjdk.java.net/pipermail/security-dev/2019-January/0
19200.html
[2] https://mail.openjdk.java.net/pipermail/security-dev/2019-January/0
19213.html
[3] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February
/058774.html
[4] https://bugs.openjdk.java.net/browse/JDK-8217375
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190307/4a2f36f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8217375.patch
Type: text/x-patch
Size: 315333 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190307/4a2f36f1/8217375-0001.patch>

From dhiller at twitter.com  Thu Mar  7 15:50:38 2019
From: dhiller at twitter.com (Dean Hiller)
Date: Thu, 7 Mar 2019 08:50:38 -0700
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CADvBZ+3Ov=oL9d0OwpsCP_rOxwGrmkufF_8j989-6J6-aC+pOg@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
 <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
 <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>
 <CADvBZ+3Ov=oL9d0OwpsCP_rOxwGrmkufF_8j989-6J6-aC+pOg@mail.gmail.com>
Message-ID: <CAN1v_zrenJqA=vcV4=5RxAJ4-6TVEuqRuFQd_+NfwdF8ZOAoTA@mail.gmail.com>

I think nothing would prevent it but they chose to separate the SSL from
the nio such that it was more re-usable and opted to not spend the
money/time on creating an SSLSelector knowing people could program it on
top.  (ie. the history).

Most stuff should be done outside the jdk anyways.  ie. look at logback and
how good it is and how the jdk logging which tried to copy log4j(and
failed) kinda sucks.

The federation model in my opinion is better with libraries on top of nio
out in the wild.

Coming back to why not do it?  There are so many things on their plate
already and the problem of ssl over nio is solved so why spend money to
make it more perfect with so many other issues and things to work on that
are most likely more important.

Dean


On Thu, Mar 7, 2019 at 12:46 AM Andi Mullaraj <andimullaraj at gmail.com>
wrote:

> Hi again,
>
> > That implies multiple threads using 1 selector ...
>
> It definitely looks like we are talking about different things. You seem
> to be talking about *how to use a Selector and encrypt/decrypt ssl and do
> it in an efficient way in order to build some server or so*. I am talking
> about *providing an SSLSelector (which agreed, would be wrapping a Selector
> and handle the encrypt/decrypt) of the same exact
> API/Semantics/Functionality as a Selector*.
>
> I agree the implementation is super complex, that's why I keep swerving
> away from implementation details. I agree with you that there is no point
> in using one Selector (either flavor) from a multitude of threads, but
> (since I am on the provider side) in order to claim the SSLSelector is a
> true reflection of a Selector I have to provide a way to make it work even
> when callers perform concurrent select() operations from various threads
> (which normally results in the locks being acquired in the order defined in
> the documentation). So yes,the implementation is even more complex than you
> actually describe it, but doable and very performant as well.
>
> So, trying to swerve back to the API discussion, I will re ask my last
> question in a different way:  If you have developed an application which
> communicates in TCP using java.nio.channels package classes (one Selector,
> multiple SocketChannel, one or more threads, doesn't matter), and you
> wanted to enhance your application to be able to communicate over SSL, what
> would stop you from using an SSLSelector with SSLSocketChannels (just
> import them, pass the SSLContext during the SSLSocketChannelCreation,
> recompile and done)? *Restating that the implementation is in pure Java,
> with no extra threads for selection, with minimal cpu and memory impact
> (only for SSL channels) over the current implementation. What would prevent
> someone from using it?*
>
> Thanks again,
> --Andi
>
>
>
> On Tue, Feb 19, 2019 at 8:18 AM Dean Hiller <dhiller at twitter.com> wrote:
>
>> I am beginning to think we might be on different pages here. Someone from
>>> outside the selector calls selector.select(), and all selector's
>>> functionality is handled within the context of the calling thread. So where
>>> is the need for the extra thread here? More specifically, in the
>>> SSLSelector case, a call to its select, ends up usually to a call to its
>>> inner selector.select(), always in the context of the calling thread ... so
>>> same thing again. Why do you think another thread is necessary here (within
>>> the selector itself)?
>>>
>>
>> That implies multiple threads using 1 selector.  That can be very
>> dangerous and prone to bugs.  Even with SSL, I would shy away from making
>> something like that unless putting it behind some library/abstraction like
>> netty, webpieces channelmanager or something.
>>
>> In fact, the performance of 1 thread that runs the selector who dishes
>> the work to a threadpool immediately (N sockets to X threads) has been
>> amazing!!!  *It was even better than multiple threads on a selector we
>> found.* This was because that caused lots of contention with
>> locks(slowing it down).  The contention depended on the application as some
>> apps had more contention than others.  I would highly advise just sticking
>> 1 thread on the selector dishing out to a thread pool which removed all
>> contention to streamline the whole process for speed.
>>
>> THEN, if you do have a threadpool and an simple implementation that runs
>> the data serially per socket in the threadpool(this is quite easy to do),
>> you can do the decryption in the threadpool as well.  webpieces impl does
>> this as well.
>>
>> just my 2 cents,
>> later,
>>
>> Dean
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190307/8fa31a46/attachment.html>

From valerie.peng at oracle.com  Fri Mar  8 00:56:22 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 7 Mar 2019 16:56:22 -0800
Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to the
 SunJSSE provider"
Message-ID: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>

Hi Brad,

Do you have time to help review the changes for JDK-8220016? Current 
changes are to register the same list of RSA-related services as these 
prior to the fix for JDK-7092821. I am not sure what are the old RSA 
impls for pre-JDK1.4 implementations. Otherwise, I can remove them as 
well. Please let me know.

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

Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/

Thanks,
Valerie

From valerie.peng at oracle.com  Fri Mar  8 00:58:17 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 7 Mar 2019 16:58:17 -0800
Subject: [13] RFR JDK-8213008 "Cipher with UNWRAP_MODE should support the
 generation of an AES key type"
Message-ID: <5c71b918-e320-676f-b318-065900911b38@oracle.com>


Anyone has time to help review this fix? According to the bug report, 
some vendors require the keytype attribute to match the encryption 
algorithm. So, the change is to match the key type based on the 
algorithm specified. There is no regression test as this issue is not 
reproducible against Solaris or NSS PKCS11 libraries.

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

Webrev: http://cr.openjdk.java.net/~valeriep/8213008/webrev.00/

Thanks,

Valerie


From anthony.scarpino at oracle.com  Fri Mar  8 01:23:01 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 7 Mar 2019 17:23:01 -0800
Subject: [13] RFR JDK-8213008 "Cipher with UNWRAP_MODE should support the
 generation of an AES key type"
In-Reply-To: <5c71b918-e320-676f-b318-065900911b38@oracle.com>
References: <5c71b918-e320-676f-b318-065900911b38@oracle.com>
Message-ID: <706980d0-70fe-52c7-3a3f-b23953637583@oracle.com>

This change looks fine.

Tony

On 3/7/19 4:58 PM, Valerie Peng wrote:
> 
> Anyone has time to help review this fix? According to the bug report, 
> some vendors require the keytype attribute to match the encryption 
> algorithm. So, the change is to match the key type based on the 
> algorithm specified. There is no regression test as this issue is not 
> reproducible against Solaris or NSS PKCS11 libraries.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213008
> 
> Webrev: http://cr.openjdk.java.net/~valeriep/8213008/webrev.00/
> 
> Thanks,
> 
> Valerie
> 


From valerie.peng at oracle.com  Fri Mar  8 01:36:10 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 7 Mar 2019 17:36:10 -0800
Subject: RFR [13] 8220165: Encryption using GCM results in
 RuntimeException- input length out of bound
In-Reply-To: <b301188b-552e-cda4-50b0-dd2d6bc6d7aa@oracle.com>
References: <eb27ea8a-2cca-6d5b-73cf-39b1e7659248@oracle.com>
 <08774412-e6ac-cda4-cce7-2cb7c7f92fca@oracle.com>
 <b301188b-552e-cda4-50b0-dd2d6bc6d7aa@oracle.com>
Message-ID: <78c87261-f63e-f664-bf7e-2473352fbe7f@oracle.com>

Updated webrev looks good.

Thanks,

Valerie

On 3/7/2019 10:25 AM, Anthony Scarpino wrote:
> On 3/6/19 6:52 PM, Valerie Peng wrote:
>> Hi Tony,
>>
>> Source change looks fine.
>>
>> For the regression test GCMLargeDataKAT.java
>> 1) typo on line 42, "has" -> "hash".
>> 2) Line 128, we should also check result.length to be the expected 
>> value, i.e. data.length - GCM_TAG_LENGTH.
>
> I had intentionally left a length check out figuring that a nulled 
> plaintext would have to be the proper length, but I guess it worth to 
> check the array was returned property
>
>> 3) Currently, the test continues even if enc check failed 
>> (line149-155). If the enc result is incorrect, why proceed with 
>> decryption? Perhaps, testing against the next key (i.e. data length) 
>> after line 155?
>
> Yeah, that's true.
>
>> 4) Remove line 184-189 as they are not used?
>
> It's used to create new data lengths if passed a length argument. As I 
> was able to do with your point #6.? In jtreg operation it is not used.
>
>> 5) line 195, no need for this being public?
>
> yep
>
>> 6) Are 65536, 65537 and 67584 input sizes add additional coverage? 
>> For data sizes 102400 to 102416, they can easily be tested with two 
>> byte[]s, sizes 102400 and 16.
>
> I chose them when I was debugging the problem and left them there.? I 
> added a few more lengths around the AES block size.? 64k is when the 
> intrinsic warmup code starts, so anything above 65535 is equally 
> relevant to test.? I used 102400 through 102416 just to cover every byte.
>
> I also changed the plaintext to use one byte array instead of
> encrypt(new byte[inLen])
>
> new webrev:
> http://cr.openjdk.java.net/~ascarpino/8220165/webrev.01/
>
>
>> Thanks,
>> Valerie
>> On 3/6/2019 3:04 PM, Anthony Scarpino wrote:
>>> Hi
>>>
>>> Can I get a review of a simple fix to the previous GCM change that 
>>> got the lengths wrong on large data sizes.? I thought I covered this 
>>> in my original testing, but I guess not.? So with this I created a 
>>> test to check larger data sizes and different byte lengths
>>>
>>> http://cr.openjdk.java.net/~ascarpino/8220165/
>>>
>>> Tony
>>>

From xuelei.fan at oracle.com  Fri Mar  8 01:45:56 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 7 Mar 2019 17:45:56 -0800
Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to
 the SunJSSE provider"
In-Reply-To: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>
References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>
Message-ID: <fa6062fb-a6a7-e841-d9ce-0e92ccd4be23@oracle.com>

Hi Valerie,

As you are already there, I may suggest to remove the old RSA crypto 
algorithms in the SunJSSE providers as well.  As may simplify the code a 
little bit, though a CSR is needed for the SunJSSE behavior change.

Thanks,
Xuelei

On 3/7/2019 4:56 PM, Valerie Peng wrote:
> Hi Brad,
> 
> Do you have time to help review the changes for JDK-8220016? Current 
> changes are to register the same list of RSA-related services as these 
> prior to the fix for JDK-7092821. I am not sure what are the old RSA 
> impls for pre-JDK1.4 implementations. Otherwise, I can remove them as 
> well. Please let me know.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016
> 
> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
> 
> Thanks,
> Valerie

From valerie.peng at oracle.com  Fri Mar  8 02:15:10 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 7 Mar 2019 18:15:10 -0800
Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to
 the SunJSSE provider"
In-Reply-To: <fa6062fb-a6a7-e841-d9ce-0e92ccd4be23@oracle.com>
References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>
 <fa6062fb-a6a7-e841-d9ce-0e92ccd4be23@oracle.com>
Message-ID: <c6d7d143-a788-e0d3-51b9-3b4b813cbccf@oracle.com>

Do you mean removing the part about SunRsaSignEntries completely? Or 
only remove the MD2/MD5withRSA signature algorithms?

Do you know the history of including them in the first place? Since 
SunRsaSign provider has been in early JDK releases, I wonder why SunJSSE 
provider duplicated these RSA algorithms in the first place? I can file 
a CSR, knowing the history/reason would help.

Thanks,

Valerie


On 3/7/2019 5:45 PM, Xuelei Fan wrote:
> Hi Valerie,
>
> As you are already there, I may suggest to remove the old RSA crypto 
> algorithms in the SunJSSE providers as well.? As may simplify the code 
> a little bit, though a CSR is needed for the SunJSSE behavior change.
>
> Thanks,
> Xuelei
>
> On 3/7/2019 4:56 PM, Valerie Peng wrote:
>> Hi Brad,
>>
>> Do you have time to help review the changes for JDK-8220016? Current 
>> changes are to register the same list of RSA-related services as 
>> these prior to the fix for JDK-7092821. I am not sure what are the 
>> old RSA impls for pre-JDK1.4 implementations. Otherwise, I can remove 
>> them as well. Please let me know.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016
>>
>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>
>> Thanks,
>> Valerie

From xuelei.fan at oracle.com  Fri Mar  8 03:30:58 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 7 Mar 2019 19:30:58 -0800
Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to
 the SunJSSE provider"
In-Reply-To: <c6d7d143-a788-e0d3-51b9-3b4b813cbccf@oracle.com>
References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>
 <fa6062fb-a6a7-e841-d9ce-0e92ccd4be23@oracle.com>
 <c6d7d143-a788-e0d3-51b9-3b4b813cbccf@oracle.com>
Message-ID: <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com>

On 3/7/2019 6:15 PM, Valerie Peng wrote:
> Do you mean removing the part about SunRsaSignEntries completely? Or 
> only remove the MD2/MD5withRSA signature algorithms?
> 
I meant to remove the SunRsaSignEntries completely from the SunJSSE 
provider.

> Do you know the history of including them in the first place? Since 
> SunRsaSign provider has been in early JDK releases, I wonder why SunJSSE 
> provider duplicated these RSA algorithms in the first place?
The JSSE provider was originally provided as an standalone library, and 
using the com.sun.net.ssl packet.  I think it was in JDK 1.4, the 
package became part of JDK, and start to using the javax.net.ssl package 
and the standard JCE providers.  However, for compatibility, the old 
supported signature algorithms are still linked in the SunJSSE provider.

In the JDK 9, a noted was added in the SunJSSE provider documentation:
    The SunJSSE provider is for backwards compatibility with
    older releases, and should no longer be used for Signature.

The compatibility is mainly about coding with explicitly SunJSSE 
provider name.  For example,
     Signature.getInstance("SHA1withRSA",
         "com.sun.net.ssl.internal.ssl.Provider");

The use may not be common in practice.  And the JDK JCE providers 
support these algorithms, I was wondering the risk of removing them from 
the SunJSSE provider may be low now.

Thanks,
Xuelei

> I can file a CSR, knowing the history/reason would help.
> 
> Thanks,
> 
> Valerie
> 
> 
> On 3/7/2019 5:45 PM, Xuelei Fan wrote:
>> Hi Valerie,
>>
>> As you are already there, I may suggest to remove the old RSA crypto 
>> algorithms in the SunJSSE providers as well.? As may simplify the code 
>> a little bit, though a CSR is needed for the SunJSSE behavior change.
>>
>> Thanks,
>> Xuelei
>>
>> On 3/7/2019 4:56 PM, Valerie Peng wrote:
>>> Hi Brad,
>>>
>>> Do you have time to help review the changes for JDK-8220016? Current 
>>> changes are to register the same list of RSA-related services as 
>>> these prior to the fix for JDK-7092821. I am not sure what are the 
>>> old RSA impls for pre-JDK1.4 implementations. Otherwise, I can remove 
>>> them as well. Please let me know.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016
>>>
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>>
>>> Thanks,
>>> Valerie

From andimullaraj at gmail.com  Fri Mar  8 22:17:28 2019
From: andimullaraj at gmail.com (Andi Mullaraj)
Date: Fri, 8 Mar 2019 14:17:28 -0800
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CAN1v_zrenJqA=vcV4=5RxAJ4-6TVEuqRuFQd_+NfwdF8ZOAoTA@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
 <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
 <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>
 <CADvBZ+3Ov=oL9d0OwpsCP_rOxwGrmkufF_8j989-6J6-aC+pOg@mail.gmail.com>
 <CAN1v_zrenJqA=vcV4=5RxAJ4-6TVEuqRuFQd_+NfwdF8ZOAoTA@mail.gmail.com>
Message-ID: <CADvBZ+0vr+cnb6JUEgLjijJSmBzEzvW8vdT_cHqNd3Q1qYCghQ@mail.gmail.com>

Inline my comments but putting this upfront so that it doesn't go unnoticed
for the occasional reader:

I was directed to this forum for discussing the merits and technicals
details of a possible SSLSelector/SSLSocketChannels. The level of
engagement seems to be very minimal though (I appreciate the effort of the
two members pitching their feedback). The best I have heard was "[..] make
SSL with Selectors easier, because right now it is very painful.  But this
approach is unlikely to succeed, at least in the JDK.", but without saying
why. Every Java developer I pitch this idea to, says the same thing "Are
you sure that SSLSelector/SSLSocketChannels are not in JDK? It cannot be
...". I proposed a concrete API but never got any feedback on that. I would
really appreciate if someone could tell me if this is the right path/forum
for discussing this.

Best,
--Andi Mullaraj


> I think nothing would prevent it
Great.

> but they chose to separate the SSL from the nio such that it was more
re-usable and opted to not spend the money/time on creating an SSLSelector
knowing people could program it on top.  (ie. the history).
That decision must have been made 15 years ago.

> Most stuff should be done outside the jdk anyways.  ie. look at logback
and how good it is and how the jdk logging which tried to copy log4j(and
failed) kinda sucks.
The reason I tackled this problem 2 years ago is that I could find no
third-party implementation of SSLSocketChannels with Selectors. I checked
how other applications dealt with that and felt the pain they must have
felt to get huge dependencies in, just to get a functionality as primordial
as this.

> The federation model in my opinion is better with libraries on top of nio
out in the wild.
The base java.nio.channels follows a federation model (SPI) and so could
this. Nothing would prevent a third party to plug in their desired
implementation (if there existed others, beyond the default)

> Coming back to why not do it?  There are so many things on their plate
already
I assume you are referring to the main/Oracle contributors being busy. I
certainly looks like that.

> and the problem of ssl over nio is solved so why spend money to make it
more perfect with so many other issues and things to work on that are most
likely more important.
This must be related to the pain threshold. I believe (and David also
mentioned) that working with SSLEngine is very painful. I mean, in order to
achieve a robust application with no edge cases especially when security
comes into play. This is not about making it perfect, it is about offering
something decent that, IMO, should have been there in first place.

Thanks,
--Andi


On Thu, Mar 7, 2019 at 7:50 AM Dean Hiller <dhiller at twitter.com> wrote:

> I think nothing would prevent it but they chose to separate the SSL from
> the nio such that it was more re-usable and opted to not spend the
> money/time on creating an SSLSelector knowing people could program it on
> top.  (ie. the history).
>
> Most stuff should be done outside the jdk anyways.  ie. look at logback
> and how good it is and how the jdk logging which tried to copy log4j(and
> failed) kinda sucks.
>
> The federation model in my opinion is better with libraries on top of nio
> out in the wild.
>
> Coming back to why not do it?  There are so many things on their plate
> already and the problem of ssl over nio is solved so why spend money to
> make it more perfect with so many other issues and things to work on that
> are most likely more important.
>
> Dean
>
>
> On Thu, Mar 7, 2019 at 12:46 AM Andi Mullaraj <andimullaraj at gmail.com>
> wrote:
>
>> Hi again,
>>
>> > That implies multiple threads using 1 selector ...
>>
>> It definitely looks like we are talking about different things. You seem
>> to be talking about *how to use a Selector and encrypt/decrypt ssl and do
>> it in an efficient way in order to build some server or so*. I am talking
>> about *providing an SSLSelector (which agreed, would be wrapping a Selector
>> and handle the encrypt/decrypt) of the same exact
>> API/Semantics/Functionality as a Selector*.
>>
>> I agree the implementation is super complex, that's why I keep swerving
>> away from implementation details. I agree with you that there is no point
>> in using one Selector (either flavor) from a multitude of threads, but
>> (since I am on the provider side) in order to claim the SSLSelector is a
>> true reflection of a Selector I have to provide a way to make it work even
>> when callers perform concurrent select() operations from various threads
>> (which normally results in the locks being acquired in the order defined in
>> the documentation). So yes,the implementation is even more complex than you
>> actually describe it, but doable and very performant as well.
>>
>> So, trying to swerve back to the API discussion, I will re ask my last
>> question in a different way:  If you have developed an application which
>> communicates in TCP using java.nio.channels package classes (one Selector,
>> multiple SocketChannel, one or more threads, doesn't matter), and you
>> wanted to enhance your application to be able to communicate over SSL, what
>> would stop you from using an SSLSelector with SSLSocketChannels (just
>> import them, pass the SSLContext during the SSLSocketChannelCreation,
>> recompile and done)? *Restating that the implementation is in pure Java,
>> with no extra threads for selection, with minimal cpu and memory impact
>> (only for SSL channels) over the current implementation. What would prevent
>> someone from using it?*
>>
>> Thanks again,
>> --Andi
>>
>>
>>
>> On Tue, Feb 19, 2019 at 8:18 AM Dean Hiller <dhiller at twitter.com> wrote:
>>
>>> I am beginning to think we might be on different pages here. Someone
>>>> from outside the selector calls selector.select(), and all selector's
>>>> functionality is handled within the context of the calling thread. So where
>>>> is the need for the extra thread here? More specifically, in the
>>>> SSLSelector case, a call to its select, ends up usually to a call to its
>>>> inner selector.select(), always in the context of the calling thread ... so
>>>> same thing again. Why do you think another thread is necessary here (within
>>>> the selector itself)?
>>>>
>>>
>>> That implies multiple threads using 1 selector.  That can be very
>>> dangerous and prone to bugs.  Even with SSL, I would shy away from making
>>> something like that unless putting it behind some library/abstraction like
>>> netty, webpieces channelmanager or something.
>>>
>>> In fact, the performance of 1 thread that runs the selector who dishes
>>> the work to a threadpool immediately (N sockets to X threads) has been
>>> amazing!!!  *It was even better than multiple threads on a selector we
>>> found.* This was because that caused lots of contention with
>>> locks(slowing it down).  The contention depended on the application as some
>>> apps had more contention than others.  I would highly advise just sticking
>>> 1 thread on the selector dishing out to a thread pool which removed all
>>> contention to streamline the whole process for speed.
>>>
>>> THEN, if you do have a threadpool and an simple implementation that runs
>>> the data serially per socket in the threadpool(this is quite easy to do),
>>> you can do the decryption in the threadpool as well.  webpieces impl does
>>> this as well.
>>>
>>> just my 2 cents,
>>> later,
>>>
>>> Dean
>>> I assume
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190308/0488ca3c/attachment.html>

From david.lloyd at redhat.com  Sat Mar  9 02:20:50 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 8 Mar 2019 20:20:50 -0600
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CADvBZ+0vr+cnb6JUEgLjijJSmBzEzvW8vdT_cHqNd3Q1qYCghQ@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
 <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
 <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>
 <CADvBZ+3Ov=oL9d0OwpsCP_rOxwGrmkufF_8j989-6J6-aC+pOg@mail.gmail.com>
 <CAN1v_zrenJqA=vcV4=5RxAJ4-6TVEuqRuFQd_+NfwdF8ZOAoTA@mail.gmail.com>
 <CADvBZ+0vr+cnb6JUEgLjijJSmBzEzvW8vdT_cHqNd3Q1qYCghQ@mail.gmail.com>
Message-ID: <CANghgrRkE_oqSyPfQq9C7v1k7gSmGMz20uMW=7J=-WVwSgGjKA@mail.gmail.com>

On Fri, Mar 8, 2019 at 4:17 PM Andi Mullaraj <andimullaraj at gmail.com> wrote:
>
> Inline my comments but putting this upfront so that it doesn't go unnoticed for the occasional reader:
>
> I was directed to this forum for discussing the merits and technicals details of a possible SSLSelector/SSLSocketChannels. The level of engagement seems to be very minimal though (I appreciate the effort of the two members pitching their feedback). The best I have heard was "[..] make SSL with Selectors easier, because right now it is very painful.  But this approach is unlikely to succeed, at least in the JDK.", but without saying why.

The answer is that selectors are for implementing event loops.  SSL is
a thing that applies to sockets.  Combining them doesn't make sense
from any rational engineering perspective.  Having a special Selector
type for SSL channels is weird, period.  It's ugly, it smells.  It
doesn't solve the problem in a clean way.  It's certainly not the
*best* solution.  And what other things will we then need special
Selector types for?  If the answer is "nothing", then why do we need a
special Selector subclass for SSL to begin with, instead of just using
Selector?

> Every Java developer I pitch this idea to, says the same thing "Are you sure that SSLSelector/SSLSocketChannels are not in JDK?"

All this says is that the Java developers you have talked to have (a)
never implemented non-blocking SSL (as evidenced by the fact that they
do not have any familiarity with the APIs) and (b) therefore do not
understand the complexities therein, or to put it more bluntly, they
have no idea what they're talking about.  I mean saying that Joe
Developer thinks some complex thing they've never looked at or
bothered to understand ought to be simple isn't really a great
argument for a lot of otherwise very busy people to drop everything to
review something that they know, based on their own expertise, isn't
really a workable solution to the problem.

> > but they chose to separate the SSL from the nio such that it was more re-usable and opted to not spend the money/time on creating an SSLSelector knowing people could program it on top.  (ie. the history).
> That decision must have been made 15 years ago.

This, for the record, has nothing to do with anything.  Some things
designed long ago are good; some are not good.  Age doesn't make ideas
go rotten.  These decisions were made for good reasons; the result may
not be perfect but it's not significantly worse now than in the 1.4
days.  The OS-level APIs that underpin Selector have not changed that
much either.

> > Most stuff should be done outside the jdk anyways.  ie. look at logback and how good it is and how the jdk logging which tried to copy log4j(and failed) kinda sucks.
> The reason I tackled this problem 2 years ago is that I could find no third-party implementation of SSLSocketChannels with Selectors. I checked how other applications dealt with that and felt the pain they must have felt to get huge dependencies in, just to get a functionality as primordial as this.

The correct abstraction you're looking for is not a Selector, it's an
"event loop".  It is possible to have an API based on Channels that is
ready-callback driven instead of Selector-driven, and such an API can
support SSL cleanly.  This is the basis of my XNIO project.  It is
only slightly higher level than Selector; the Channels are otherwise
largely similar.

Selector is just too low-level to abstract the concept neatly (see:
countless discussions about the difficulty of implementing the
lowest-level event loop in every network daemon software written in
the past 30 years).

> This must be related to the pain threshold. I believe (and David also mentioned) that working with SSLEngine is very painful. I mean, in order to achieve a robust application with no edge cases especially when security comes into play. This is not about making it perfect, it is about offering something decent that, IMO, should have been there in first place.

What you're looking for is a better non-blocking approach to SSL, and
I too would love to see it.  If it ever comes to the JDK though, it
would have to come in the form of a JDK-level event loop abstraction,
with callback-driven channels that extend NIO.  I don't see that
happening unless it would be part of a long term plan to deprecate
NIO: the JDK folks hate needless duplication.  This seems unlikely.
But hey, maybe it's time for that idea to get its day.

-- 
- DML

From andimullaraj at gmail.com  Sat Mar  9 09:35:19 2019
From: andimullaraj at gmail.com (Andi Mullaraj)
Date: Sat, 9 Mar 2019 01:35:19 -0800
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CANghgrRkE_oqSyPfQq9C7v1k7gSmGMz20uMW=7J=-WVwSgGjKA@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
 <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
 <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>
 <CADvBZ+3Ov=oL9d0OwpsCP_rOxwGrmkufF_8j989-6J6-aC+pOg@mail.gmail.com>
 <CAN1v_zrenJqA=vcV4=5RxAJ4-6TVEuqRuFQd_+NfwdF8ZOAoTA@mail.gmail.com>
 <CADvBZ+0vr+cnb6JUEgLjijJSmBzEzvW8vdT_cHqNd3Q1qYCghQ@mail.gmail.com>
 <CANghgrRkE_oqSyPfQq9C7v1k7gSmGMz20uMW=7J=-WVwSgGjKA@mail.gmail.com>
Message-ID: <CADvBZ+1NwvWsVC6qx_Ovk+FZKRb9cUi-BuCjyeRpjm8iiEsYbQ@mail.gmail.com>

Thanks for following up David,

You just made my day. Really. I have finally something concrete in front of
me that I can address.
In interest of keeping this discussion in focus, I will bypass the rest and
address a couple of key points from your response:

> Having a special Selector type for SSL channels is weird, period.  It's
ugly, it smells.  It doesn't solve the problem in a clean way.

Cut & pasting from a previous message of mine in this same thread, here is
the way a java.nio.channels loop works as of today (no SSL):

Selector selector = Selector.open();
SocketChannel socketChannel = SocketChannel.open();
socketChannel.register(selector, SelectionKey.OP_READ);

while(true) {
    selector.select();
    for (SocketChannel sc : selector.selectedKeys() {
        sc.read(...)
    }
}

and here it is how it works with my implementation (which I am considering
offering it to JDK):

Selector selector = SSLSelector.open(); // notice the SSL
SocketChannel socketChannel = SSLSocketChannel.open();  // notice the SSL
socketChannel.register(selector, SelectionKey.OP_READ);

while(true) {
    selector.select();
    for (SocketChannel sc : selector.selectedKeys() {
        sc.read(...)
    }
}

Adding the following block to show the same (and some) if it ever made it
to JDK -- is quite evident, but adding it here to avoid any possible
misunderstanding:

Selector selector = Selector.open(); // notice no SSL, but internally
the SelectorProvider pics the SSLSelector
SocketChannel socketChannel1 = SocketChannel.open();      // notice Plain
SocketChannel socketChannel2 = SSLSocketChannel.open();   // notice SSL
socketChannel1.register(selector, SelectionKey.OP_READ);  // notice
mixture of channels
socketChannel2.register(selector, SelectionKey.OP_WRITE); // notice
mixture of channels

while(true) {
    selector.select();
    for (SocketChannel sc : selector.selectedKeys() {
	if (sc.isReadable()) sc.read(...)
	if (sc.isWritable()) sc.write(...)
    }
}

So:

1. There is no special Selector (that the user sees), just the good old
Selector.
2. The user creates SSLSocketChannels (and possibly SocketChannels,
SSLServerSocketChannels, ServerSocketChannels) and registers them
altogether with the Selector.

What is ugly and smelly here? How much cleaner can we bridge today's world
and tomorrow's? At the end of the day, a developer wants to use the same
model, to achieve performant SSL communication the same way it used to with
non-SSL communication. Just like in the blocking world, an InputStream can
be obtained from a Socket or an SSLSocket, then it can be read upon in
indistinguishable manner.

> If it ever comes to the JDK though, it would have to come in the form of
a JDK-level event loop abstraction, with callback-driven channels that
extend NIO. I don't see that happening unless it would be part of a long
term plan to deprecate NIO: the JDK folks hate needless duplication.  This
seems unlikely. But hey, maybe it's time for that idea to get its day.

In light of the previous point, I couldn't disagree more. As it is
painfully clear, the proposed approach stays within the confines of nio,
and no duplication is needed (I also hate duplication).



I am commenting on the rest, but I believe this is nearly not as important
as the points above. Feel free to discard:

> This, for the record, has nothing to do with anything.  Some things
designed long ago are good; some are not good.  Age doesn't make ideas go
rotten.
Agreed. My answer has to be taken in the context of "... opted to not spend
the money/time on creating an SSLSelector knowing people could program it
on top"

> The correct abstraction you're looking for is not a Selector, it's an
"event loop".

The "event loop" or whatever pattern that can be chosen today will be
possible tomorrow with the proposed API. XNIO should be able to ingest this
right in, same way (I assume) it does with Selector/SocketChannel, and
without need to use SSLEngine to encrypt/decrypt SSL.

> Selector is just too low-level to abstract the concept neatly (see:
countless discussions about the difficulty of implementing the lowest-level
event loop in every network daemon software written in the past 30 years).

Not to say I don't follow discussions, but why should I when I can develop
something myself, see it work perfectly, test it to work with hundreds of
thousands of SSL connections on a single host, handling 23GBPS of SSL
traffic on a 25GBPS network (75% usage over 48 CPUs)?

Thanks again,
--Andi

On Fri, Mar 8, 2019 at 6:21 PM David Lloyd <david.lloyd at redhat.com> wrote:

> On Fri, Mar 8, 2019 at 4:17 PM Andi Mullaraj <andimullaraj at gmail.com>
> wrote:
> >
> > Inline my comments but putting this upfront so that it doesn't go
> unnoticed for the occasional reader:
> >
> > I was directed to this forum for discussing the merits and technicals
> details of a possible SSLSelector/SSLSocketChannels. The level of
> engagement seems to be very minimal though (I appreciate the effort of the
> two members pitching their feedback). The best I have heard was "[..] make
> SSL with Selectors easier, because right now it is very painful.  But this
> approach is unlikely to succeed, at least in the JDK.", but without saying
> why.
>
> The answer is that selectors are for implementing event loops.  SSL is
> a thing that applies to sockets.  Combining them doesn't make sense
> from any rational engineering perspective.  Having a special Selector
> type for SSL channels is weird, period.  It's ugly, it smells.  It
> doesn't solve the problem in a clean way.  It's certainly not the
> *best* solution.  And what other things will we then need special
> Selector types for?  If the answer is "nothing", then why do we need a
> special Selector subclass for SSL to begin with, instead of just using
> Selector?
>
> > Every Java developer I pitch this idea to, says the same thing "Are you
> sure that SSLSelector/SSLSocketChannels are not in JDK?"
>
> All this says is that the Java developers you have talked to have (a)
> never implemented non-blocking SSL (as evidenced by the fact that they
> do not have any familiarity with the APIs) and (b) therefore do not
> understand the complexities therein, or to put it more bluntly, they
> have no idea what they're talking about.  I mean saying that Joe
> Developer thinks some complex thing they've never looked at or
> bothered to understand ought to be simple isn't really a great
> argument for a lot of otherwise very busy people to drop everything to
> review something that they know, based on their own expertise, isn't
> really a workable solution to the problem.
>
> > > but they chose to separate the SSL from the nio such that it was more
> re-usable and opted to not spend the money/time on creating an SSLSelector
> knowing people could program it on top.  (ie. the history).
> > That decision must have been made 15 years ago.
>
> This, for the record, has nothing to do with anything.  Some things
> designed long ago are good; some are not good.  Age doesn't make ideas
> go rotten.  These decisions were made for good reasons; the result may
> not be perfect but it's not significantly worse now than in the 1.4
> days.  The OS-level APIs that underpin Selector have not changed that
> much either.
>
> > > Most stuff should be done outside the jdk anyways.  ie. look at
> logback and how good it is and how the jdk logging which tried to copy
> log4j(and failed) kinda sucks.
> > The reason I tackled this problem 2 years ago is that I could find no
> third-party implementation of SSLSocketChannels with Selectors. I checked
> how other applications dealt with that and felt the pain they must have
> felt to get huge dependencies in, just to get a functionality as primordial
> as this.
>
> The correct abstraction you're looking for is not a Selector, it's an
> "event loop".  It is possible to have an API based on Channels that is
> ready-callback driven instead of Selector-driven, and such an API can
> support SSL cleanly.  This is the basis of my XNIO project.  It is
> only slightly higher level than Selector; the Channels are otherwise
> largely similar.
>
> Selector is just too low-level to abstract the concept neatly (see:
> countless discussions about the difficulty of implementing the
> lowest-level event loop in every network daemon software written in
> the past 30 years).
>
> > This must be related to the pain threshold. I believe (and David also
> mentioned) that working with SSLEngine is very painful. I mean, in order to
> achieve a robust application with no edge cases especially when security
> comes into play. This is not about making it perfect, it is about offering
> something decent that, IMO, should have been there in first place.
>
> What you're looking for is a better non-blocking approach to SSL, and
> I too would love to see it.  If it ever comes to the JDK though, it
> would have to come in the form of a JDK-level event loop abstraction,
> with callback-driven channels that extend NIO.  I don't see that
> happening unless it would be part of a long term plan to deprecate
> NIO: the JDK folks hate needless duplication.  This seems unlikely.
> But hey, maybe it's time for that idea to get its day.
>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190309/b11c87b4/attachment-0001.html>

From Alan.Bateman at oracle.com  Mon Mar 11 07:58:37 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 11 Mar 2019 07:58:37 +0000
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CADvBZ+1NwvWsVC6qx_Ovk+FZKRb9cUi-BuCjyeRpjm8iiEsYbQ@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
 <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
 <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>
 <CADvBZ+3Ov=oL9d0OwpsCP_rOxwGrmkufF_8j989-6J6-aC+pOg@mail.gmail.com>
 <CAN1v_zrenJqA=vcV4=5RxAJ4-6TVEuqRuFQd_+NfwdF8ZOAoTA@mail.gmail.com>
 <CADvBZ+0vr+cnb6JUEgLjijJSmBzEzvW8vdT_cHqNd3Q1qYCghQ@mail.gmail.com>
 <CANghgrRkE_oqSyPfQq9C7v1k7gSmGMz20uMW=7J=-WVwSgGjKA@mail.gmail.com>
 <CADvBZ+1NwvWsVC6qx_Ovk+FZKRb9cUi-BuCjyeRpjm8iiEsYbQ@mail.gmail.com>
Message-ID: <d817c9d2-726d-5b55-0d00-7c4ee23b2867@oracle.com>

On 09/03/2019 09:35, Andi Mullaraj wrote:
>
> In light of the previous point, I couldn't disagree more. As it is 
> painfully clear, the proposed approach stays within the confines of 
> nio, and no duplication is needed (I also hate duplication).
>
This is a topic that was explored, and ruled out, in JSR-51 but lead to 
SSLEngine. Yes, SSLEngine has pain points and performance issues and I 
think it would be better to focus on those issues and see how SSLEngine 
could be improved. This would be more beneficial for the eco system 
today as most developers don't use SocketChannels or Selectors directly 
(those APIs tend to be hidden by libraries and frameworks so most 
developers don't see them).

Also as a reminder is that we are exploring, in Project Loom, ways to 
make it easy to develop simple blocking code that scales as well as code 
forced to asynchronous frameworks today. If we get that right then it 
should eliminate many of the reasons to create further asynchronous or 
non-blocking APIs.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190311/81b0ad23/attachment.html>

From weijun.wang at oracle.com  Mon Mar 11 10:31:01 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 11 Mar 2019 18:31:01 +0800
Subject: RFR 8220256: fix headings in java.security.sasl
Message-ID: <858B845F-E812-419E-AD6C-2304468EAD2D@oracle.com>

Hi Jon,

Please take a look at the patch below.

diff --git a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java
--- a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java
+++ b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java
@@ -30,7 +30,7 @@
  * It is used by developers to add authentication support for
  * connection-based protocols that use SASL.
  *
- * <h3>SASL Overview</h3>
+ * <h2>SASL Overview</h2>
  *
  * Simple Authentication and Security Layer (SASL) specifies a
  * challenge-response protocol in which data is exchanged between the
@@ -74,7 +74,7 @@
  * allow negotiation of the security layer.  For External, the
  * security layer is determined by the external protocol.
  *
- * <h3>Usage</h3>
+ * <h2>Usage</h2>
  *
  * Users of this API are typically developers who produce
  * client library implementations for connection-based protocols,

In case you want to look at the whole file, its current content is at https://hg.openjdk.java.net/jdk/jdk/file/9a1dd1203a4f/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java <https://hg.openjdk.java.net/jdk/jdk/file/9a1dd1203a4f/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java>.

Thanks,
Max

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190311/9a64041c/attachment.html>

From sean.mullan at oracle.com  Mon Mar 11 12:23:54 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 11 Mar 2019 08:23:54 -0400
Subject: Disable TLS 1.3 backward compatibility mode?
In-Reply-To: <trinity-d0d2382d-dc38-486b-9f51-0e7b0abed1ad-1552245858881@3c-app-webde-bap17>
References: <trinity-d0d2382d-dc38-486b-9f51-0e7b0abed1ad-1552245858881@3c-app-webde-bap17>
Message-ID: <6bfc7216-6b20-b570-fb14-c9f6f391ccea@oracle.com>

-bcc net-dev

Copying security-dev as TLS 1.3 topics are more appropriate for that 
mailing list.

--Sean

On 3/10/19 3:24 PM, raell at web.de wrote:
> Dear,
> the Java TLS 1.3 implementation supports middlebox compatibility (e.g. 
> sends a non-empty session id and a ChangeCipherSpec message). Out of 
> interest: Is it possible to disable this compatibility mode?
> Regards, Ralph

From xuelei.fan at oracle.com  Mon Mar 11 18:15:49 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 11 Mar 2019 11:15:49 -0700
Subject: Disable TLS 1.3 backward compatibility mode?
In-Reply-To: <6bfc7216-6b20-b570-fb14-c9f6f391ccea@oracle.com>
References: <trinity-d0d2382d-dc38-486b-9f51-0e7b0abed1ad-1552245858881@3c-app-webde-bap17>
 <6bfc7216-6b20-b570-fb14-c9f6f391ccea@oracle.com>
Message-ID: <de79f6b2-f93f-aa9e-d1bb-292660cd1395@oracle.com>

Hi Ralph,

Currently, TLS 1.3 is implemented in JDK in compatibility mode.  Please 
feel free to submit a request if this feature matters to you.

Regards,
Xuelei

On 3/11/2019 5:23 AM, Sean Mullan wrote:
> -bcc net-dev
> 
> Copying security-dev as TLS 1.3 topics are more appropriate for that 
> mailing list.
> 
> --Sean
> 
> On 3/10/19 3:24 PM, raell at web.de wrote:
>> Dear,
>> the Java TLS 1.3 implementation supports middlebox compatibility (e.g. 
>> sends a non-empty session id and a ChangeCipherSpec message). Out of 
>> interest: Is it possible to disable this compatibility mode?
>> Regards, Ralph

From valerie.peng at oracle.com  Mon Mar 11 22:59:44 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 11 Mar 2019 15:59:44 -0700
Subject: [13] RFR JDK-8220016 "SunRsaSignEntries were mistakenly added to
 the SunJSSE provider"
In-Reply-To: <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com>
References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>
 <fa6062fb-a6a7-e841-d9ce-0e92ccd4be23@oracle.com>
 <c6d7d143-a788-e0d3-51b9-3b4b813cbccf@oracle.com>
 <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com>
Message-ID: <b9ce5943-dd56-b453-69cb-2836257cfa86@oracle.com>

Thanks for the info, I'd prefer to completely remove the SunRsaSign 
entries from SunJSSE provider as well.

I will update the webrev and file a CSR then.

Thanks,

Valerie


On 3/7/2019 7:30 PM, Xuelei Fan wrote:
> On 3/7/2019 6:15 PM, Valerie Peng wrote:
>> Do you mean removing the part about SunRsaSignEntries completely? Or 
>> only remove the MD2/MD5withRSA signature algorithms?
>>
> I meant to remove the SunRsaSignEntries completely from the SunJSSE 
> provider.
>
>> Do you know the history of including them in the first place? Since 
>> SunRsaSign provider has been in early JDK releases, I wonder why 
>> SunJSSE provider duplicated these RSA algorithms in the first place?
> The JSSE provider was originally provided as an standalone library, 
> and using the com.sun.net.ssl packet.? I think it was in JDK 1.4, the 
> package became part of JDK, and start to using the javax.net.ssl 
> package and the standard JCE providers.? However, for compatibility, 
> the old supported signature algorithms are still linked in the SunJSSE 
> provider.
>
> In the JDK 9, a noted was added in the SunJSSE provider documentation:
> ?? The SunJSSE provider is for backwards compatibility with
> ?? older releases, and should no longer be used for Signature.
>
> The compatibility is mainly about coding with explicitly SunJSSE 
> provider name.? For example,
> ??? Signature.getInstance("SHA1withRSA",
> ??????? "com.sun.net.ssl.internal.ssl.Provider");
>
> The use may not be common in practice.? And the JDK JCE providers 
> support these algorithms, I was wondering the risk of removing them 
> from the SunJSSE provider may be low now.
>
> Thanks,
> Xuelei
>
>> I can file a CSR, knowing the history/reason would help.
>>
>> Thanks,
>>
>> Valerie
>>
>>
>> On 3/7/2019 5:45 PM, Xuelei Fan wrote:
>>> Hi Valerie,
>>>
>>> As you are already there, I may suggest to remove the old RSA crypto 
>>> algorithms in the SunJSSE providers as well.? As may simplify the 
>>> code a little bit, though a CSR is needed for the SunJSSE behavior 
>>> change.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 3/7/2019 4:56 PM, Valerie Peng wrote:
>>>> Hi Brad,
>>>>
>>>> Do you have time to help review the changes for JDK-8220016? 
>>>> Current changes are to register the same list of RSA-related 
>>>> services as these prior to the fix for JDK-7092821. I am not sure 
>>>> what are the old RSA impls for pre-JDK1.4 implementations. 
>>>> Otherwise, I can remove them as well. Please let me know.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>>>
>>>> Thanks,
>>>> Valerie

From valerie.peng at oracle.com  Mon Mar 11 23:45:55 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 11 Mar 2019 16:45:55 -0700
Subject: [13] RFR JDK-8220258 "fix headings in java.smartcardio"
Message-ID: <a94cebcd-0bb2-9d2a-adca-67d47d37ba06@oracle.com>

Can someone help reviewing this? Just a javadoc one-line fix.

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

Webrev: http://cr.openjdk.java.net/~valeriep/8220258/webrev.00/

Thanks,

Valerie


From anthony.scarpino at oracle.com  Mon Mar 11 23:56:24 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 11 Mar 2019 16:56:24 -0700
Subject: [13] RFR JDK-8220258 "fix headings in java.smartcardio"
In-Reply-To: <a94cebcd-0bb2-9d2a-adca-67d47d37ba06@oracle.com>
References: <a94cebcd-0bb2-9d2a-adca-67d47d37ba06@oracle.com>
Message-ID: <18B01115-984B-4C42-ACA9-39E4E88B5D40@oracle.com>

Looks good 

> On Mar 11, 2019, at 4:45 PM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Can someone help reviewing this? Just a javadoc one-line fix.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220258
> 
> Webrev: http://cr.openjdk.java.net/~valeriep/8220258/webrev.00/
> 
> Thanks,
> 
> Valerie
> 

From sgehwolf at redhat.com  Tue Mar 12 10:54:41 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 12 Mar 2019 11:54:41 +0100
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
Message-ID: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>

Adding security-dev as reviews should happen on the corresponding area
lists. Even for 8.

On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/

This looks OK to me. It removes the same tests as was done for JDK 9.
I've verified that KdcPolicy.java passes after your changes. Not a
Reviewer, though.

Thanks,
Severin

> Original review:
> https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html
> 
> This is not a clean backport because the tests in 8u differ slightly
> from those in OpenJDK 10:
> 
> 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly".
> That same change (adding a property to the @run line) also needs to be
> applied to the new KdcPolicy.java test for it to succeed.
> 
> 2. 10u contains "JDK-8006690: sun/security/krb5/auto/BadKdc* tests fails
> intermittently" which I assume is obsoleted by the more reliable
> KdcPolicy.java test
> 
> Strangely enough, this & JDK-8164656 were already approved last July,
> but never pushed [0].  I can't see how this was a straightforward
> backport then though either.
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-July/007667.html


From sean.mullan at oracle.com  Tue Mar 12 13:05:12 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 12 Mar 2019 09:05:12 -0400
Subject: CSR Review Request JDK-816826, Use server cipher suites
 preference by default
In-Reply-To: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com>
References: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com>
Message-ID: <3c1cb2e0-9506-0563-1aa6-b7b3a70d9860@oracle.com>

Looks good, but a couple of comments:

In the Solution section, it says: "Applications can change the behavior 
with the existing SSLParameters.setUseCipherSuitesOrder?() method."

I think you should be more clear that this means applications can change 
the order of the server's preferred cipher suites. There will be no way 
to go back to the previous behavior where the client's order is respected.

Same comment in the proposed Release Note, although I don't think this 
section needs to be in the CSR, does it?

--Sean

On 2/25/19 12:36 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I have the following CSR reviewed?
>  ?? https://bugs.openjdk.java.net/browse/JDK-8219657
> 
> It is proposing to use server cipher suite preference by default for TLS 
> connections in JDK. In the current implementation, the server honors the 
> client cipher suite preference by default. It is easier to maintain if 
> using the server cipher suite preference, and then the server can have 
> more control over the security parameters of TLS connections.
> 
> I think the compatibility impact should be minimal.? If there is a known 
> risk for you, please let me know by the end of March 4, 2019.
> 
> Thanks,
> Xuelei

From xuelei.fan at oracle.com  Tue Mar 12 17:12:37 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 12 Mar 2019 10:12:37 -0700
Subject: CSR Review Request JDK-816826, Use server cipher suites
 preference by default
In-Reply-To: <3c1cb2e0-9506-0563-1aa6-b7b3a70d9860@oracle.com>
References: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com>
 <3c1cb2e0-9506-0563-1aa6-b7b3a70d9860@oracle.com>
Message-ID: <c0abc941-780b-3f21-aa58-2c4d078444ee@oracle.com>

On 3/12/2019 6:05 AM, Sean Mullan wrote:
> Looks good, but a couple of comments:
> 
> In the Solution section, it says: "Applications can change the behavior 
> with the existing SSLParameters.setUseCipherSuitesOrder?() method."
> 
> I think you should be more clear that this means applications can change 
> the order of the server's preferred cipher suites. There will be no way 
> to go back to the previous behavior where the client's order is respected.
> 
If a server call SSLParameters.setUseCipherSuitesOrder?(false),  the 
client's order is respected.

> Same comment in the proposed Release Note, although I don't think this 
> section needs to be in the CSR, does it?
> 
It's not a required part of the CSR.  I use this section to have the 
release note reviewed as well.  I will remove this section as it is a 
kind of duplication of the release-note entry.

Thanks,
Xuelei

> --Sean
> 
> On 2/25/19 12:36 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I have the following CSR reviewed?
>> ??? https://bugs.openjdk.java.net/browse/JDK-8219657
>>
>> It is proposing to use server cipher suite preference by default for 
>> TLS connections in JDK. In the current implementation, the server 
>> honors the client cipher suite preference by default. It is easier to 
>> maintain if using the server cipher suite preference, and then the 
>> server can have more control over the security parameters of TLS 
>> connections.
>>
>> I think the compatibility impact should be minimal.? If there is a 
>> known risk for you, please let me know by the end of March 4, 2019.
>>
>> Thanks,
>> Xuelei

From sean.mullan at oracle.com  Tue Mar 12 17:27:25 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 12 Mar 2019 13:27:25 -0400
Subject: CSR Review Request JDK-816826, Use server cipher suites
 preference by default
In-Reply-To: <c0abc941-780b-3f21-aa58-2c4d078444ee@oracle.com>
References: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com>
 <3c1cb2e0-9506-0563-1aa6-b7b3a70d9860@oracle.com>
 <c0abc941-780b-3f21-aa58-2c4d078444ee@oracle.com>
Message-ID: <1da7072b-71fd-1b21-d143-9b338593b4e1@oracle.com>

On 3/12/19 1:12 PM, Xuelei Fan wrote:
> On 3/12/2019 6:05 AM, Sean Mullan wrote:
>> Looks good, but a couple of comments:
>>
>> In the Solution section, it says: "Applications can change the 
>> behavior with the existing SSLParameters.setUseCipherSuitesOrder?() 
>> method."
>>
>> I think you should be more clear that this means applications can 
>> change the order of the server's preferred cipher suites. There will 
>> be no way to go back to the previous behavior where the client's order 
>> is respected.
>>
> If a server call SSLParameters.setUseCipherSuitesOrder?(false),? the 
> client's order is respected.

Oh, ok, I retract my comment then. When I read this, I had 
misinterpreted this to be the method that you use to set the enabled suites.

--Sean

> 
>> Same comment in the proposed Release Note, although I don't think this 
>> section needs to be in the CSR, does it?
>>
> It's not a required part of the CSR.? I use this section to have the 
> release note reviewed as well.? I will remove this section as it is a 
> kind of duplication of the release-note entry.
> 
> Thanks,
> Xuelei
> 
>> --Sean
>>
>> On 2/25/19 12:36 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I have the following CSR reviewed?
>>> ??? https://bugs.openjdk.java.net/browse/JDK-8219657
>>>
>>> It is proposing to use server cipher suite preference by default for 
>>> TLS connections in JDK. In the current implementation, the server 
>>> honors the client cipher suite preference by default. It is easier to 
>>> maintain if using the server cipher suite preference, and then the 
>>> server can have more control over the security parameters of TLS 
>>> connections.
>>>
>>> I think the compatibility impact should be minimal.? If there is a 
>>> known risk for you, please let me know by the end of March 4, 2019.
>>>
>>> Thanks,
>>> Xuelei

From xuelei.fan at oracle.com  Tue Mar 12 18:14:37 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 12 Mar 2019 11:14:37 -0700
Subject: RFR [13] JDK-8160247 : Mark deprecated javax.security.cert APIs with
 forRemoval=true
Message-ID: <1dd0c727-f9be-2738-6483-553314dd6284@oracle.com>

Hi,

Could I get the following update reviewed?
    http://cr.openjdk.java.net/~xuelei/8160247/webrev.00/

The javax.security.cert API has been deprecated. The classes in this 
package should no longer be used.  In the changeset, the 
"forRemoval=true" was added to the Deprecated annotation of the 
javax.security.cert classes.

For more details, please refer to CSR:
    https://bugs.openjdk.java.net/browse/JDK-8219472

Thanks,
Xuelei

From sean.mullan at oracle.com  Tue Mar 12 18:22:50 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 12 Mar 2019 14:22:50 -0400
Subject: RFR 8220256: fix headings in java.security.sasl
In-Reply-To: <858B845F-E812-419E-AD6C-2304468EAD2D@oracle.com>
References: <858B845F-E812-419E-AD6C-2304468EAD2D@oracle.com>
Message-ID: <710de6fa-7696-8639-1695-3f3f6b240d72@oracle.com>

Looks fine to me.

--Sean

On 3/11/19 6:31 AM, Weijun Wang wrote:
> Hi Jon,
> 
> Please take a look at the patch below.
> 
> *diff --git 
> a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java 
> b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java*
> *--- 
> a/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java*
> *+++ 
> b/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java*
> @@ -30,7 +30,7 @@
>  ? * It is used by developers to add authentication support for
>  ? * connection-based protocols that use SASL.
>  ? *
> - * <h3>SASL Overview</h3>
> + * <h2>SASL Overview</h2>
>  ? *
>  ? * Simple Authentication and Security Layer (SASL) specifies a
>  ? * challenge-response protocol in which data is exchanged between the
> @@ -74,7 +74,7 @@
>  ? * allow negotiation of the security layer.? For External, the
>  ? * security layer is determined by the external protocol.
>  ? *
> - * <h3>Usage</h3>
> + * <h2>Usage</h2>
>  ? *
>  ? * Users of this API are typically developers who produce
>  ? * client library implementations for connection-based protocols,
> 
> In case you want to look at the whole file, its current content is at 
> https://hg.openjdk.java.net/jdk/jdk/file/9a1dd1203a4f/src/java.security.sasl/share/classes/javax/security/sasl/package-info.java.
> 
> Thanks,
> Max
> 

From jamil.j.nimeh at oracle.com  Tue Mar 12 18:33:14 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 12 Mar 2019 11:33:14 -0700
Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance( algo_, 
 provider_ ) ignores the provider argument.
Message-ID: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com>

Hello all,

Please review the CSR for the behavioral change to SunJCE's PBKDF2 
implementaion.? This change will make the underlying Mac also come from 
SunJCE.? This change only affects the SunJCE implementation of PBKDF2, 
not any other implementation from any different provider.

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

Thanks,
--Jamil

From mbalao at redhat.com  Tue Mar 12 19:56:36 2019
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 12 Mar 2019 16:56:36 -0300
Subject: SunJSSE and SunPKCS11 (NSS + FIPS)
Message-ID: <aad7a951-32dd-da32-125b-c6790cc16cb5@redhat.com>

Hi,

There is an issue that I'd like to bring here for discussion.

I've been trying to reproduce a purely-OpenJDK TLS 1.2 exchange between
a client and server using SunPKCS11 crypto provider -with NSS software
token configured in FIPS mode-, after JDK-8217835 change [1].

My 1st preference crypto provider is SunPKCS11 and my 2nd is SUN.

All my keys for this communication will then be non-extractable P11Key
keys. This means that we cannot convert them to work with any other
service from any other provider. Otherwise, FIPS constraints would be
violated.

SignatureScheme considers multiple signing algorithms as available when
there is at least one crypto provider that supports them. As an example,
"RSASSA-PSS" is listed as available because I have "SUN" crypto provider
enabled. SunPKCS11 does not currently support "RSASSA-PSS" algorithm.
Even though it would be pretty easy to support it (CKM_RSA_PKCS_PSS
mechanism), we may still be in a case in which the underlying SunPKCS11
library does not implement it or where there is not a mechanism in the
PKCS#11 latest standard.

Now, SignatureScheme.getSignature gets called with a P11Key [2]. Inside
this method, Signature.getInstance(algorithm) will return a SUN service
provider that cannot work with these P11Key keys.

Disabling SUN provider is not an option because we need support for
X.509 certificates.

My understanding is that the previous experimental FIPS mode in SunJSSE
provided consistency through a unique underlying crypto provider, used
across the engine. I believe we still need to support the SunPKCS11 -
FIPS case, as it's pretty common in enterprises.

In addition, I'm working towards re-introducing TestTLS12 to JDK. This
test does not only reproduce this scenario, but has helped to find bugs
such as JDK-8220513 [3].

Thoughts?

Kind regards,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8217835
[2] -
http://hg.openjdk.java.net/jdk/jdk/file/daec95ed6795/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l469
[3] - https://bugs.openjdk.java.net/browse/JDK-8220513

From mbalao at redhat.com  Tue Mar 12 22:34:24 2019
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 12 Mar 2019 19:34:24 -0300
Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in
 SunPKCS11 crypto provider
Message-ID: <a03d6a49-5811-faad-e6ba-0e6c668d614a@redhat.com>

Hi,

I'd like to propose a fix for JDK-8220513 [1]:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.00/

Testing:

 * No regressions found in sun/security/pkcs11

 * This bug was exposed by TestTLS12 test, in jdk11u [2]. I'm working in
re-introducing this test to JDK (after JDK-8217835 deleted it). An issue
[4] has to be worked out first though. I'll followup on this.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8220513
[2] -
http://hg.openjdk.java.net/jdk-updates/jdk11u/file/d17a1764a0f3/test/jdk/sun/security/pkcs11/fips/TestTLS12.java
[3] - https://bugs.openjdk.java.net/browse/JDK-8217835
[4] -
https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html

From valerie.peng at oracle.com  Wed Mar 13 02:57:50 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 12 Mar 2019 19:57:50 -0700
Subject: [13] RFR JDK-8220016 "Clean up redundant RSA services in the
 SunJSSE provider"
In-Reply-To: <b9ce5943-dd56-b453-69cb-2836257cfa86@oracle.com>
References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>
 <fa6062fb-a6a7-e841-d9ce-0e92ccd4be23@oracle.com>
 <c6d7d143-a788-e0d3-51b9-3b4b813cbccf@oracle.com>
 <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com>
 <b9ce5943-dd56-b453-69cb-2836257cfa86@oracle.com>
Message-ID: <dc3fa2cd-3647-261a-1daa-896cf1b78180@oracle.com>

Please review the CSR at: https://bugs.openjdk.java.net/browse/JDK-8220549

Webrev updated in place for this new approach: 
http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/

I changed the synopsis to clarify that we are now removing these 
duplicated RSA support.

Thanks,

Valerie


On 3/11/2019 3:59 PM, Valerie Peng wrote:
> Thanks for the info, I'd prefer to completely remove the SunRsaSign 
> entries from SunJSSE provider as well.
>
> I will update the webrev and file a CSR then.
>
> Thanks,
>
> Valerie
>
>
> On 3/7/2019 7:30 PM, Xuelei Fan wrote:
>> On 3/7/2019 6:15 PM, Valerie Peng wrote:
>>> Do you mean removing the part about SunRsaSignEntries completely? Or 
>>> only remove the MD2/MD5withRSA signature algorithms?
>>>
>> I meant to remove the SunRsaSignEntries completely from the SunJSSE 
>> provider.
>>
>>> Do you know the history of including them in the first place? Since 
>>> SunRsaSign provider has been in early JDK releases, I wonder why 
>>> SunJSSE provider duplicated these RSA algorithms in the first place?
>> The JSSE provider was originally provided as an standalone library, 
>> and using the com.sun.net.ssl packet.? I think it was in JDK 1.4, the 
>> package became part of JDK, and start to using the javax.net.ssl 
>> package and the standard JCE providers. However, for compatibility, 
>> the old supported signature algorithms are still linked in the 
>> SunJSSE provider.
>>
>> In the JDK 9, a noted was added in the SunJSSE provider documentation:
>> ?? The SunJSSE provider is for backwards compatibility with
>> ?? older releases, and should no longer be used for Signature.
>>
>> The compatibility is mainly about coding with explicitly SunJSSE 
>> provider name.? For example,
>> ??? Signature.getInstance("SHA1withRSA",
>> ??????? "com.sun.net.ssl.internal.ssl.Provider");
>>
>> The use may not be common in practice.? And the JDK JCE providers 
>> support these algorithms, I was wondering the risk of removing them 
>> from the SunJSSE provider may be low now.
>>
>> Thanks,
>> Xuelei
>>
>>> I can file a CSR, knowing the history/reason would help.
>>>
>>> Thanks,
>>>
>>> Valerie
>>>
>>>
>>> On 3/7/2019 5:45 PM, Xuelei Fan wrote:
>>>> Hi Valerie,
>>>>
>>>> As you are already there, I may suggest to remove the old RSA 
>>>> crypto algorithms in the SunJSSE providers as well.? As may 
>>>> simplify the code a little bit, though a CSR is needed for the 
>>>> SunJSSE behavior change.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>> On 3/7/2019 4:56 PM, Valerie Peng wrote:
>>>>> Hi Brad,
>>>>>
>>>>> Do you have time to help review the changes for JDK-8220016? 
>>>>> Current changes are to register the same list of RSA-related 
>>>>> services as these prior to the fix for JDK-7092821. I am not sure 
>>>>> what are the old RSA impls for pre-JDK1.4 implementations. 
>>>>> Otherwise, I can remove them as well. Please let me know.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Valerie

From weijun.wang at oracle.com  Wed Mar 13 03:02:01 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 13 Mar 2019 11:02:01 +0800
Subject: RFR [13] JDK-8160247 : Mark deprecated javax.security.cert APIs
 with forRemoval=true
In-Reply-To: <1dd0c727-f9be-2738-6483-553314dd6284@oracle.com>
References: <1dd0c727-f9be-2738-6483-553314dd6284@oracle.com>
Message-ID: <BC900C6D-8D8F-468C-9388-50DADA527D82@oracle.com>

The change looks fine.

--Max

> On Mar 13, 2019, at 2:14 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Hi,
> 
> Could I get the following update reviewed?
>   http://cr.openjdk.java.net/~xuelei/8160247/webrev.00/
> 
> The javax.security.cert API has been deprecated. The classes in this package should no longer be used.  In the changeset, the "forRemoval=true" was added to the Deprecated annotation of the javax.security.cert classes.
> 
> For more details, please refer to CSR:
>   https://bugs.openjdk.java.net/browse/JDK-8219472
> 
> Thanks,
> Xuelei


From xuelei.fan at oracle.com  Wed Mar 13 03:18:11 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 12 Mar 2019 20:18:11 -0700
Subject: [13] RFR JDK-8220016 "Clean up redundant RSA services in the
 SunJSSE provider"
In-Reply-To: <dc3fa2cd-3647-261a-1daa-896cf1b78180@oracle.com>
References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>
 <fa6062fb-a6a7-e841-d9ce-0e92ccd4be23@oracle.com>
 <c6d7d143-a788-e0d3-51b9-3b4b813cbccf@oracle.com>
 <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com>
 <b9ce5943-dd56-b453-69cb-2836257cfa86@oracle.com>
 <dc3fa2cd-3647-261a-1daa-896cf1b78180@oracle.com>
Message-ID: <1f20f66b-5157-6180-4e7c-fbc15ab1444e@oracle.com>

On 3/12/2019 7:57 PM, Valerie Peng wrote:
> Please review the CSR at: https://bugs.openjdk.java.net/browse/JDK-8220549
> 
I added myself as reviewer.

> Webrev updated in place for this new approach: 
> http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
> 
It looks fine to me.

Xuelei

> I changed the synopsis to clarify that we are now removing these 
> duplicated RSA support.
> 
> Thanks,
> 
> Valerie
> 
> 
> On 3/11/2019 3:59 PM, Valerie Peng wrote:
>> Thanks for the info, I'd prefer to completely remove the SunRsaSign 
>> entries from SunJSSE provider as well.
>>
>> I will update the webrev and file a CSR then.
>>
>> Thanks,
>>
>> Valerie
>>
>>
>> On 3/7/2019 7:30 PM, Xuelei Fan wrote:
>>> On 3/7/2019 6:15 PM, Valerie Peng wrote:
>>>> Do you mean removing the part about SunRsaSignEntries completely? Or 
>>>> only remove the MD2/MD5withRSA signature algorithms?
>>>>
>>> I meant to remove the SunRsaSignEntries completely from the SunJSSE 
>>> provider.
>>>
>>>> Do you know the history of including them in the first place? Since 
>>>> SunRsaSign provider has been in early JDK releases, I wonder why 
>>>> SunJSSE provider duplicated these RSA algorithms in the first place?
>>> The JSSE provider was originally provided as an standalone library, 
>>> and using the com.sun.net.ssl packet.? I think it was in JDK 1.4, the 
>>> package became part of JDK, and start to using the javax.net.ssl 
>>> package and the standard JCE providers. However, for compatibility, 
>>> the old supported signature algorithms are still linked in the 
>>> SunJSSE provider.
>>>
>>> In the JDK 9, a noted was added in the SunJSSE provider documentation:
>>> ?? The SunJSSE provider is for backwards compatibility with
>>> ?? older releases, and should no longer be used for Signature.
>>>
>>> The compatibility is mainly about coding with explicitly SunJSSE 
>>> provider name.? For example,
>>> ??? Signature.getInstance("SHA1withRSA",
>>> ??????? "com.sun.net.ssl.internal.ssl.Provider");
>>>
>>> The use may not be common in practice.? And the JDK JCE providers 
>>> support these algorithms, I was wondering the risk of removing them 
>>> from the SunJSSE provider may be low now.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> I can file a CSR, knowing the history/reason would help.
>>>>
>>>> Thanks,
>>>>
>>>> Valerie
>>>>
>>>>
>>>> On 3/7/2019 5:45 PM, Xuelei Fan wrote:
>>>>> Hi Valerie,
>>>>>
>>>>> As you are already there, I may suggest to remove the old RSA 
>>>>> crypto algorithms in the SunJSSE providers as well.? As may 
>>>>> simplify the code a little bit, though a CSR is needed for the 
>>>>> SunJSSE behavior change.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>> On 3/7/2019 4:56 PM, Valerie Peng wrote:
>>>>>> Hi Brad,
>>>>>>
>>>>>> Do you have time to help review the changes for JDK-8220016? 
>>>>>> Current changes are to register the same list of RSA-related 
>>>>>> services as these prior to the fix for JDK-7092821. I am not sure 
>>>>>> what are the old RSA impls for pre-JDK1.4 implementations. 
>>>>>> Otherwise, I can remove them as well. Please let me know.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> Valerie

From norman.maurer at googlemail.com  Wed Mar 13 06:31:06 2019
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Wed, 13 Mar 2019 07:31:06 +0100
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
Message-ID: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>

Is there anything else I can do to have anyone look into this? 

I just want to make sure this does not fall through before the final JDK 12 release is done. 

Bye
Norman


> On 4. Mar 2019, at 21:15, Norman Maurer <norman.maurer at googlemail.com> wrote:
> 
> Any comments here ?
> 
> Bye
> Norman
> 
> 
>> On 28. Feb 2019, at 09:24, Norman Maurer <norman.maurer at googlemail.com <mailto:norman.maurer at googlemail.com>> wrote:
>> 
>> Hi all,
>> 
>> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho.
>> 
>> I pushed a reproducer for this here:
>> 
>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug <https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug>
>> 
>> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions.
>> 
>> Here is the Java version I used to reproduce:
>> 
>> # java -version
>> openjdk version "12" 2019-03-19
>> OpenJDK Runtime Environment (build 12+33)
>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
>> 
>> 
>> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version:
>> 
>> #java -version
>> openjdk version "12-ea" 2019-03-19
>> OpenJDK Runtime Environment (build 12-ea+27)
>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
>> 
>> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/
>> 
>> Thanks
>> Norman
>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190313/8f8ce68d/attachment.html>

From Alan.Bateman at oracle.com  Wed Mar 13 07:48:00 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 13 Mar 2019 07:48:00 +0000
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
 <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
Message-ID: <f77377c1-01ac-b958-087f-ad587f792646@oracle.com>

On 13/03/2019 06:31, Norman Maurer wrote:
> Is there anything else I can do to have anyone look into this?
>
> I just want to make sure this does not fall through before the final 
> JDK 12 release is done.
>
Can you attach or inline the test that demonstrates the issue you are 
seeing? (we can't use reproducers that are hosted on github).

-Alan.

From norman.maurer at googlemail.com  Wed Mar 13 07:51:56 2019
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Wed, 13 Mar 2019 08:51:56 +0100
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <f77377c1-01ac-b958-087f-ad587f792646@oracle.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
 <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
 <f77377c1-01ac-b958-087f-ad587f792646@oracle.com>
Message-ID: <E1B0A48A-6E0E-41FB-ACE1-D748FBCF3740@googlemail.com>

As it contains also keymaterial can I just tar it or will you be able to use your own keymaterial and fill in the missing pieces?

Bye
Norman


> On 13. Mar 2019, at 08:48, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 13/03/2019 06:31, Norman Maurer wrote:
>> Is there anything else I can do to have anyone look into this?
>> 
>> I just want to make sure this does not fall through before the final JDK 12 release is done.
>> 
> Can you attach or inline the test that demonstrates the issue you are seeing? (we can't use reproducers that are hosted on github).
> 
> -Alan.


From sha.jiang at oracle.com  Wed Mar 13 08:58:25 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Wed, 13 Mar 2019 16:58:25 +0800
Subject: RFR[13] JDK-8220410:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with
 missing expected output
Message-ID: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>

Hi,
This fix just makes sure that specified timezone is not null, and the 
jar verifying and date formatting use the same different timezone.

Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8220410

Best regards,
John Jiang


From sha.jiang at oracle.com  Wed Mar 13 09:01:46 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Wed, 13 Mar 2019 17:01:46 +0800
Subject: RFR[13] JDK-8220410:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with
 missing expected output
In-Reply-To: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>
References: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>
Message-ID: <0c6a78e2-e1a7-fc57-4a29-104a683cae30@oracle.com>

On 2019/3/13 16:58, sha.jiang at oracle.com wrote:

> Hi,
> This fix just makes sure that specified timezone is not null, and the 
> jar verifying and date formatting use the same different timezone.
... use the same (not different) timezone.

John

>
> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410
>
> Best regards,
> John Jiang
>

From Alan.Bateman at oracle.com  Wed Mar 13 09:04:18 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 13 Mar 2019 09:04:18 +0000
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <E1B0A48A-6E0E-41FB-ACE1-D748FBCF3740@googlemail.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
 <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
 <f77377c1-01ac-b958-087f-ad587f792646@oracle.com>
 <E1B0A48A-6E0E-41FB-ACE1-D748FBCF3740@googlemail.com>
Message-ID: <2e8471f2-33b7-e01d-e1cd-e28fa38155a2@oracle.com>

On 13/03/2019 07:51, Norman Maurer wrote:
> As it contains also keymaterial can I just tar it or will you be able to use your own keymaterial and fill in the missing pieces?
If it's needed to demonstrate the issue then include but if it's just 
setup then it would be better to provide the instructions. I don't know 
file types are stripped by the mail servers but if you cc me then I can 
create an issue in JBS.

-Alan

From sean.mullan at oracle.com  Wed Mar 13 12:31:36 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 13 Mar 2019 08:31:36 -0400
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
 <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
Message-ID: <ec98abdb-5e2b-0291-c2d7-5e09ab609c6b@oracle.com>

My best guess is that https://bugs.openjdk.java.net/browse/JDK-8214418 
is the cause.

Xuelei, would you have time to look at this?

Thanks,
Sean

On 3/13/19 2:31 AM, Norman Maurer wrote:
> Is there anything else I can do to have anyone look into this?
> 
> I just want to make sure this does not fall through before the final JDK 
> 12 release is done.
> 
> Bye
> Norman
> 
> 
>> On 4. Mar 2019, at 21:15, Norman Maurer <norman.maurer at googlemail.com 
>> <mailto:norman.maurer at googlemail.com>> wrote:
>>
>> Any comments here ?
>>
>> Bye
>> Norman
>>
>>
>>> On 28. Feb 2019, at 09:24, Norman Maurer 
>>> <norman.maurer at googlemail.com <mailto:norman.maurer at googlemail.com>> 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I think I found a possible regression / bug in the latest JDK12 
>>> release when trying to upgrade the Netty CI server to test with the 
>>> latest JDK12 release. The problem is that SSLEngine.wrap(?) returns 
>>> NOT_HANDSHAKING even when there are bytes left that should be 
>>> consumed (the alert itself). My understanding is that it should only 
>>> return ?NOT_HANDSHAKING? once we also consumed the alert. Please 
>>> correct me if I wrong tho.
>>>
>>> I pushed a reproducer for this here:
>>>
>>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug
>>>
>>> When running this on the latest JDK12 release (and later JDK 
>>> versions) it will fail with an AssertionError, while everything works 
>>> as expected when using earlier Java versions.
>>>
>>> Here is the Java version I used to reproduce:
>>>
>>> # java -version
>>> openjdk version "12" 2019-03-19
>>> OpenJDK Runtime Environment (build 12+33)
>>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
>>>
>>>
>>> It seems like this was not always the case for Java12 tho, as I can 
>>> not reproduce it with this version:
>>>
>>> #java -version
>>> openjdk version "12-ea" 2019-03-19
>>> OpenJDK Runtime Environment (build 12-ea+27)
>>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
>>>
>>> I don't have all the ?in between? releases on my machine atm so I can 
>>> not tell exactly on which release this ?broke? :/
>>>
>>> Thanks
>>> Norman
>>>
>>>
>>>
>>
> 

From norman.maurer at googlemail.com  Wed Mar 13 12:54:20 2019
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Wed, 13 Mar 2019 13:54:20 +0100
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <ec98abdb-5e2b-0291-c2d7-5e09ab609c6b@oracle.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
 <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
 <ec98abdb-5e2b-0291-c2d7-5e09ab609c6b@oracle.com>
Message-ID: <274E72A5-CAB9-4956-851D-B9A05763A04E@googlemail.com>

Wasn?t it possible at some point to browse the bugs without a login ? When I try to look at the issue it asks me for a login :/

Bye
Norman


> On 13. Mar 2019, at 13:31, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> My best guess is that https://bugs.openjdk.java.net/browse/JDK-8214418 is the cause.
> 
> Xuelei, would you have time to look at this?
> 
> Thanks,
> Sean
> 
> On 3/13/19 2:31 AM, Norman Maurer wrote:
>> Is there anything else I can do to have anyone look into this?
>> I just want to make sure this does not fall through before the final JDK 12 release is done.
>> Bye
>> Norman
>>> On 4. Mar 2019, at 21:15, Norman Maurer <norman.maurer at googlemail.com <mailto:norman.maurer at googlemail.com>> wrote:
>>> 
>>> Any comments here ?
>>> 
>>> Bye
>>> Norman
>>> 
>>> 
>>>> On 28. Feb 2019, at 09:24, Norman Maurer <norman.maurer at googlemail.com <mailto:norman.maurer at googlemail.com>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho.
>>>> 
>>>> I pushed a reproducer for this here:
>>>> 
>>>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug
>>>> 
>>>> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions.
>>>> 
>>>> Here is the Java version I used to reproduce:
>>>> 
>>>> # java -version
>>>> openjdk version "12" 2019-03-19
>>>> OpenJDK Runtime Environment (build 12+33)
>>>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
>>>> 
>>>> 
>>>> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version:
>>>> 
>>>> #java -version
>>>> openjdk version "12-ea" 2019-03-19
>>>> OpenJDK Runtime Environment (build 12-ea+27)
>>>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
>>>> 
>>>> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/
>>>> 
>>>> Thanks
>>>> Norman
>>>> 
>>>> 
>>>> 
>>> 


From norman.maurer at googlemail.com  Wed Mar 13 12:56:50 2019
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Wed, 13 Mar 2019 13:56:50 +0100
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <2e8471f2-33b7-e01d-e1cd-e28fa38155a2@oracle.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
 <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
 <f77377c1-01ac-b958-087f-ad587f792646@oracle.com>
 <E1B0A48A-6E0E-41FB-ACE1-D748FBCF3740@googlemail.com>
 <2e8471f2-33b7-e01d-e1cd-e28fa38155a2@oracle.com>
Message-ID: <BAA6A992-368D-4FEE-A3E0-DB18C6C9D477@googlemail.com>

Here is the reproducer (just replace ?test.p12? with some valid file that contains the keymaterial), which does not throw on JDK11 but throws on JDK12:

import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLEngine;
import javax.net.ssl.SSLEngineResult;
import javax.net.ssl.SSLException;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import java.nio.ByteBuffer;
import java.security.KeyStore;
import java.security.cert.X509Certificate;

public class JDKSSLUnwrapReproducer {

    public static void main(String[] args) throws Exception {
        KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
        keyStore.load(JDKSSLUnwrapReproducer.class.getResourceAsStream("test.p12"), "test".toCharArray());
        KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
        kmf.init(keyStore, "test".toCharArray());
        SSLContext serverCtx = SSLContext.getInstance("TLS");
        serverCtx.init(kmf.getKeyManagers(), null, null);
        SSLEngine server = serverCtx.createSSLEngine();
        server.setUseClientMode(false);
        server.setEnabledProtocols(new String[] { "TLSv1.2" });


        SSLContext clientCtx = SSLContext.getInstance("TLS");
        clientCtx.init(null, new TrustManager[] {
                new X509TrustManager() {
                    @Override
                    public void checkClientTrusted(X509Certificate[] x509Certificates, String s) {
                        // NOOP
                    }

                    @Override
                    public void checkServerTrusted(X509Certificate[] x509Certificates, String s) {
                        // NOOP
                    }

                    @Override
                    public X509Certificate[] getAcceptedIssuers() {
                        return new X509Certificate[0];
                    }
                }
        }, null);

        SSLEngine client = clientCtx.createSSLEngine();
        client.setUseClientMode(true);
        client.setEnabledProtocols(new String[] { "TLSv1.2" });

        ByteBuffer plainClientOut = ByteBuffer.allocate(client.getSession().getApplicationBufferSize());
        ByteBuffer plainServerOut = ByteBuffer.allocate(server.getSession().getApplicationBufferSize());

        ByteBuffer encryptedClientToServer = ByteBuffer.allocate(client.getSession().getPacketBufferSize());
        ByteBuffer encryptedServerToClient = ByteBuffer.allocate(server.getSession().getPacketBufferSize());
        ByteBuffer empty = ByteBuffer.allocate(0);

        handshake(client, server);

        // This will produce a close_notify
        client.closeOutbound();

        // Something still pending in the outbound buffer.
        assertFalse(client.isOutboundDone());
        assertFalse(client.isInboundDone());

        // Now wrap and so drain the outbound buffer.
        SSLEngineResult result = client.wrap(empty, encryptedClientToServer);
        encryptedClientToServer.flip();

        assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus());
        // Need an UNWRAP to read the response of the close_notify
        //
        // This is NOT_HANDSHAKING for JDK 12+ !!!!
        assertEquals(SSLEngineResult.HandshakeStatus.NEED_UNWRAP, result.getHandshakeStatus());

        int produced = result.bytesProduced();
        int consumed = result.bytesConsumed();
        int closeNotifyLen = produced;

        assertTrue(produced > 0);
        assertEquals(0, consumed);
        assertEquals(produced, encryptedClientToServer.remaining());
        // Outbound buffer should be drained now.
        assertTrue(client.isOutboundDone());
        assertFalse(client.isInboundDone());

        assertFalse(server.isOutboundDone());
        assertFalse(server.isInboundDone());
        result = server.unwrap(encryptedClientToServer, plainServerOut);
        plainServerOut.flip();

        assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus());
        // Need a WRAP to respond to the close_notify
        assertEquals(SSLEngineResult.HandshakeStatus.NEED_WRAP, result.getHandshakeStatus());

        produced = result.bytesProduced();
        consumed = result.bytesConsumed();
        assertEquals(closeNotifyLen, consumed);
        assertEquals(0, produced);
        // Should have consumed the complete close_notify
        assertEquals(0, encryptedClientToServer.remaining());
        assertEquals(0, plainServerOut.remaining());

        assertFalse(server.isOutboundDone());
        assertTrue(server.isInboundDone());

        result = server.wrap(empty, encryptedServerToClient);
        encryptedServerToClient.flip();

        assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus());
        // UNWRAP/WRAP are not expected after this point
        assertEquals(SSLEngineResult.HandshakeStatus.NOT_HANDSHAKING, result.getHandshakeStatus());

        produced = result.bytesProduced();
        consumed = result.bytesConsumed();
        assertEquals(closeNotifyLen, produced);
        assertEquals(0, consumed);

        assertEquals(produced, encryptedServerToClient.remaining());
        assertTrue(server.isOutboundDone());
        assertTrue(server.isInboundDone());

        result = client.unwrap(encryptedServerToClient, plainClientOut);

        plainClientOut.flip();
        assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus());
        // UNWRAP/WRAP are not expected after this point
        assertEquals(SSLEngineResult.HandshakeStatus.NOT_HANDSHAKING, result.getHandshakeStatus());

        produced = result.bytesProduced();
        consumed = result.bytesConsumed();
        assertEquals(closeNotifyLen, consumed);
        assertEquals(0, produced);
        assertEquals(0, encryptedServerToClient.remaining());

        assertTrue(client.isOutboundDone());
        assertTrue(client.isInboundDone());

        // Ensure that calling wrap or unwrap again will not produce a SSLException
        encryptedServerToClient.clear();
        plainServerOut.clear();

        result = server.wrap(plainServerOut, encryptedServerToClient);
        assertEngineRemainsClosed(result);

        encryptedClientToServer.clear();
        plainServerOut.clear();

        result = server.unwrap(encryptedClientToServer, plainServerOut);
        assertEngineRemainsClosed(result);

        encryptedClientToServer.clear();
        plainClientOut.clear();

        result = client.wrap(plainClientOut, encryptedClientToServer);
        assertEngineRemainsClosed(result);

        encryptedServerToClient.clear();
        plainClientOut.clear();

        result = client.unwrap(encryptedServerToClient, plainClientOut);
        assertEngineRemainsClosed(result);
    }


    private static void assertEngineRemainsClosed(SSLEngineResult result) {
        assertEquals(SSLEngineResult.Status.CLOSED, result.getStatus());
        assertEquals(SSLEngineResult.HandshakeStatus.NOT_HANDSHAKING, result.getHandshakeStatus());
        assertEquals(0, result.bytesConsumed());
        assertEquals(0, result.bytesProduced());
    }

    private static void handshake(SSLEngine clientEngine, SSLEngine serverEngine) throws SSLException {
        ByteBuffer cTOs = ByteBuffer.allocate(clientEngine.getSession().getPacketBufferSize());
        ByteBuffer sTOc = ByteBuffer.allocate(serverEngine.getSession().getPacketBufferSize());

        ByteBuffer serverAppReadBuffer = ByteBuffer.allocate(
                serverEngine.getSession().getApplicationBufferSize());
        ByteBuffer clientAppReadBuffer = ByteBuffer.allocate(
                clientEngine.getSession().getApplicationBufferSize());

        clientEngine.beginHandshake();
        serverEngine.beginHandshake();

        ByteBuffer empty = ByteBuffer.allocate(0);

        SSLEngineResult clientResult;
        SSLEngineResult serverResult;

        boolean clientHandshakeFinished = false;
        boolean serverHandshakeFinished = false;

        do {
            if (!clientHandshakeFinished) {
                clientResult = clientEngine.wrap(empty, cTOs);
                runDelegatedTasks(clientResult, clientEngine);

                if (isHandshakeFinished(clientResult)) {
                    clientHandshakeFinished = true;
                }
            }

            if (!serverHandshakeFinished) {
                serverResult = serverEngine.wrap(empty, sTOc);
                runDelegatedTasks(serverResult, serverEngine);

                if (isHandshakeFinished(serverResult)) {
                    serverHandshakeFinished = true;
                }
            }

            cTOs.flip();
            sTOc.flip();

            if (!clientHandshakeFinished) {
                clientResult = clientEngine.unwrap(sTOc, clientAppReadBuffer);

                runDelegatedTasks(clientResult, clientEngine);

                if (isHandshakeFinished(clientResult)) {
                    clientHandshakeFinished = true;
                }
            }

            if (!serverHandshakeFinished) {
                serverResult = serverEngine.unwrap(cTOs, serverAppReadBuffer);
                runDelegatedTasks(serverResult, serverEngine);

                if (isHandshakeFinished(serverResult)) {
                    serverHandshakeFinished = true;
                }
            }

            sTOc.compact();
            cTOs.compact();
        } while (!clientHandshakeFinished || !serverHandshakeFinished);
    }

    private static boolean isHandshakeFinished(SSLEngineResult result) {
        return result.getHandshakeStatus() == SSLEngineResult.HandshakeStatus.FINISHED;
    }

    private static void runDelegatedTasks(SSLEngineResult result, SSLEngine engine) {
        if (result.getHandshakeStatus() == SSLEngineResult.HandshakeStatus.NEED_TASK) {
            for (;;) {
                Runnable task = engine.getDelegatedTask();
                if (task == null) {
                    break;
                }
                task.run();
            }
        }
    }


    private static void assertTrue(boolean result) {
        if (!result) {
            throw new AssertionError();
        }
    }

    private static void assertFalse(boolean result) {
        if (result) {
            throw new AssertionError();
        }
    }

    private static void assertEquals(Object o1, Object o2) {
        if (!o1.equals(o2)) {
            throw new AssertionError(o1 + " != " + o2);
        }
    }
}


> On 13. Mar 2019, at 10:04, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 13/03/2019 07:51, Norman Maurer wrote:
>> As it contains also keymaterial can I just tar it or will you be able to use your own keymaterial and fill in the missing pieces?
> If it's needed to demonstrate the issue then include but if it's just setup then it would be better to provide the instructions. I don't know file types are stripped by the mail servers but if you cc me then I can create an issue in JBS.
> 
> -Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190313/f3b1afa7/attachment-0001.html>

From daniel.fuchs at oracle.com  Wed Mar 13 13:05:12 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Mar 2019 13:05:12 +0000
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <274E72A5-CAB9-4956-851D-B9A05763A04E@googlemail.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <B4972CF5-931B-4C01-9314-422756DB88DD@googlemail.com>
 <8DAB02B7-79BC-400A-90DB-F53450880872@googlemail.com>
 <ec98abdb-5e2b-0291-c2d7-5e09ab609c6b@oracle.com>
 <274E72A5-CAB9-4956-851D-B9A05763A04E@googlemail.com>
Message-ID: <4771bd5c-b1af-6658-dadf-9ed1a4b4ef12@oracle.com>

Hi Norman,

On 13/03/2019 12:54, Norman Maurer wrote:
> Wasn?t it possible at some point to browse the bugs without a login ? When I try to look at the issue it asks me for a login :/

Sorry about that.

You should be able to find all the information about the
issue in the public review thread in the security-dev archive:

http://mail.openjdk.java.net/pipermail/security-dev/2018-December/019100.html
http://mail.openjdk.java.net/pipermail/security-dev/2019-January/019142.html

Hope this help,

-- daniel

From adam.petcher at oracle.com  Wed Mar 13 13:44:05 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 13 Mar 2019 09:44:05 -0400
Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance(
 algo_, provider_ ) ignores the provider argument.
In-Reply-To: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com>
References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com>
Message-ID: <b1e75b2b-bc20-53ef-f680-a9f25511521f@oracle.com>

On 3/12/2019 2:33 PM, Jamil Nimeh wrote:

> Hello all,
>
> Please review the CSR for the behavioral change to SunJCE's PBKDF2 
> implementaion.? This change will make the underlying Mac also come 
> from SunJCE.? This change only affects the SunJCE implementation of 
> PBKDF2, not any other implementation from any different provider.
>
> https://bugs.openjdk.java.net/browse/JDK-8220531

Looks pretty straightforward. I just have a couple of questions related 
to compatibility:

1) Is it possible that the requested Mac would not be available in 
SunJCE, but it would be available in some other provider? If so, then 
PBKDF2 would fail after this change. Should we fall back to the current 
behavior if we get a NoSuchAlgorithmException from SunJCE?

2) Do you (or anyone else on the mailing list) have any reason to be 
concerned that the Mac in SunJCE won't work as well in some cases where 
it could also come from another (higher-priority) provider? If so, then 
we should think about adding a system property or other toggle for this 
behavior. This is a question---not a suggestion. I don't think we should 
include this toggle unless we have some motivation to do so.

Also, if there is no change to any spec, then I think that means the 
scope is "Implementation" rather than "SE".



From xuelei.fan at oracle.com  Wed Mar 13 14:05:51 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 13 Mar 2019 07:05:51 -0700
Subject: SunJSSE and SunPKCS11 (NSS + FIPS)
In-Reply-To: <aad7a951-32dd-da32-125b-c6790cc16cb5@redhat.com>
References: <aad7a951-32dd-da32-125b-c6790cc16cb5@redhat.com>
Message-ID: <89013e89-be40-46f5-0432-2e5ab7ed7c07@oracle.com>

To use FIPS mode JCE provider, an application could:
1. implement the required algorithm in the FIPS mode JCE provider.
2. don't those algorithms that outside the scope of the FIPS mode JCE 
provider (restrict them).

Xuelei

On 3/12/2019 12:56 PM, Martin Balao wrote:
> Hi,
> 
> There is an issue that I'd like to bring here for discussion.
> 
> I've been trying to reproduce a purely-OpenJDK TLS 1.2 exchange between
> a client and server using SunPKCS11 crypto provider -with NSS software
> token configured in FIPS mode-, after JDK-8217835 change [1].
> 
> My 1st preference crypto provider is SunPKCS11 and my 2nd is SUN.
> 
> All my keys for this communication will then be non-extractable P11Key
> keys. This means that we cannot convert them to work with any other
> service from any other provider. Otherwise, FIPS constraints would be
> violated.
> 
> SignatureScheme considers multiple signing algorithms as available when
> there is at least one crypto provider that supports them. As an example,
> "RSASSA-PSS" is listed as available because I have "SUN" crypto provider
> enabled. SunPKCS11 does not currently support "RSASSA-PSS" algorithm.
> Even though it would be pretty easy to support it (CKM_RSA_PKCS_PSS
> mechanism), we may still be in a case in which the underlying SunPKCS11
> library does not implement it or where there is not a mechanism in the
> PKCS#11 latest standard.
> 
> Now, SignatureScheme.getSignature gets called with a P11Key [2]. Inside
> this method, Signature.getInstance(algorithm) will return a SUN service
> provider that cannot work with these P11Key keys.
> 
> Disabling SUN provider is not an option because we need support for
> X.509 certificates.
> 
> My understanding is that the previous experimental FIPS mode in SunJSSE
> provided consistency through a unique underlying crypto provider, used
> across the engine. I believe we still need to support the SunPKCS11 -
> FIPS case, as it's pretty common in enterprises.
> 
> In addition, I'm working towards re-introducing TestTLS12 to JDK. This
> test does not only reproduce this scenario, but has helped to find bugs
> such as JDK-8220513 [3].
> 
> Thoughts?
> 
> Kind regards,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8217835
> [2] -
> http://hg.openjdk.java.net/jdk/jdk/file/daec95ed6795/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l469
> [3] - https://bugs.openjdk.java.net/browse/JDK-8220513
> 

From xuelei.fan at oracle.com  Wed Mar 13 14:11:29 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 13 Mar 2019 07:11:29 -0700
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
Message-ID: <e4b8691b-2ccc-8514-4cd9-441b368057bf@oracle.com>

Hi Norman,

What's the problem in the application?  It is possible that status is 
NOT_HANDSHAKING even there are bytes left that should be consumed, for 
example alert or application data.  NOT_HANDSHAKING means that the 
handshaking is not in progress.

Thanks,
Xuelei

On 2/28/2019 12:24 AM, Norman Maurer wrote:
> Hi all,
> 
> I think I found a possible regression / bug in the latest JDK12 release 
> when trying to upgrade the Netty CI server to test with the latest JDK12 
> release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING 
> even when there are bytes left that should be consumed (the alert 
> itself). My understanding is that it should only return 
> ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if 
> I wrong tho.
> 
> I pushed a reproducer for this here:
> 
> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug
> 
> When running this on the latest JDK12 release (and later JDK versions) 
> it will fail with an AssertionError, while everything works as expected 
> when using earlier Java versions.
> 
> Here is the Java version I used to reproduce:
> 
> # java -version
> openjdk version "12" 2019-03-19
> OpenJDK Runtime Environment (build 12+33)
> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
> 
> 
> It seems like this was not always the case for Java12 tho, as I can not 
> reproduce it with this version:
> 
> #java -version
> openjdk version "12-ea" 2019-03-19
> OpenJDK Runtime Environment (build 12-ea+27)
> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
> 
> I don't have all the ?in between? releases on my machine atm so I can 
> not tell exactly on which release this ?broke? :/
> 
> Thanks
> Norman
> 
> 
> 

From norman.maurer at googlemail.com  Wed Mar 13 14:17:03 2019
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Wed, 13 Mar 2019 15:17:03 +0100
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <e4b8691b-2ccc-8514-4cd9-441b368057bf@oracle.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <e4b8691b-2ccc-8514-4cd9-441b368057bf@oracle.com>
Message-ID: <0E5D1537-1277-4B6F-B53E-C56410A9C9F0@googlemail.com>

I assumed that it should return NEED_UNWRAP if there is something left that needs to be consumed (that?s also what happened in JDK11 and before).

How should we know then that there is an alert to consume ?

Bye
Norman

> Am 13.03.2019 um 15:11 schrieb Xuelei Fan <xuelei.fan at oracle.com>:
> 
> Hi Norman,
> 
> What's the problem in the application?  It is possible that status is NOT_HANDSHAKING even there are bytes left that should be consumed, for example alert or application data.  NOT_HANDSHAKING means that the handshaking is not in progress.
> 
> Thanks,
> Xuelei
> 
>> On 2/28/2019 12:24 AM, Norman Maurer wrote:
>> Hi all,
>> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho.
>> I pushed a reproducer for this here:
>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug
>> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions.
>> Here is the Java version I used to reproduce:
>> # java -version
>> openjdk version "12" 2019-03-19
>> OpenJDK Runtime Environment (build 12+33)
>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
>> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version:
>> #java -version
>> openjdk version "12-ea" 2019-03-19
>> OpenJDK Runtime Environment (build 12-ea+27)
>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
>> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/
>> Thanks
>> Norman

From xuelei.fan at oracle.com  Wed Mar 13 14:39:15 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 13 Mar 2019 07:39:15 -0700
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert
 was not consumed yet in latest JDK12 release (possible regression).
In-Reply-To: <0E5D1537-1277-4B6F-B53E-C56410A9C9F0@googlemail.com>
References: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>
 <e4b8691b-2ccc-8514-4cd9-441b368057bf@oracle.com>
 <0E5D1537-1277-4B6F-B53E-C56410A9C9F0@googlemail.com>
Message-ID: <718db506-e75c-6454-1630-bd15a6dd6d2c@oracle.com>

Once TLS handshaking completed, the status would be NOT_HANDSHAKING.  It 
is unlikely to know the content type of the unconsumed data.  When the 
data get consumed, the status may be adjusted accordingly.

Xuelei

On 3/13/2019 7:17 AM, Norman Maurer wrote:
> I assumed that it should return NEED_UNWRAP if there is something left that needs to be consumed (that?s also what happened in JDK11 and before).
> 
> How should we know then that there is an alert to consume ?
> > Bye
> Norman
> 
>> Am 13.03.2019 um 15:11 schrieb Xuelei Fan <xuelei.fan at oracle.com>:
>>
>> Hi Norman,
>>
>> What's the problem in the application?  It is possible that status is NOT_HANDSHAKING even there are bytes left that should be consumed, for example alert or application data.  NOT_HANDSHAKING means that the handshaking is not in progress.
>>
>> Thanks,
>> Xuelei
>>
>>> On 2/28/2019 12:24 AM, Norman Maurer wrote:
>>> Hi all,
>>> I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho.
>>> I pushed a reproducer for this here:
>>> https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug
>>> When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions.
>>> Here is the Java version I used to reproduce:
>>> # java -version
>>> openjdk version "12" 2019-03-19
>>> OpenJDK Runtime Environment (build 12+33)
>>> OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)
>>> It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version:
>>> #java -version
>>> openjdk version "12-ea" 2019-03-19
>>> OpenJDK Runtime Environment (build 12-ea+27)
>>> OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)
>>> I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/
>>> Thanks
>>> Norman

From sean.mullan at oracle.com  Wed Mar 13 15:00:47 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 13 Mar 2019 11:00:47 -0400
Subject: [13] RFR JDK-8220016 "Clean up redundant RSA services in the
 SunJSSE provider"
In-Reply-To: <1f20f66b-5157-6180-4e7c-fbc15ab1444e@oracle.com>
References: <0f882665-ade7-dd50-e90f-30cf8a746d5a@oracle.com>
 <fa6062fb-a6a7-e841-d9ce-0e92ccd4be23@oracle.com>
 <c6d7d143-a788-e0d3-51b9-3b4b813cbccf@oracle.com>
 <3721ef42-2ce9-d35b-7ed6-cb1858efa4fa@oracle.com>
 <b9ce5943-dd56-b453-69cb-2836257cfa86@oracle.com>
 <dc3fa2cd-3647-261a-1daa-896cf1b78180@oracle.com>
 <1f20f66b-5157-6180-4e7c-fbc15ab1444e@oracle.com>
Message-ID: <e628f3ef-7a5f-fe01-ec0d-033687a66610@oracle.com>

There should also be a release note issue filed for this change.

--Sean

On 3/12/19 11:18 PM, Xuelei Fan wrote:
> On 3/12/2019 7:57 PM, Valerie Peng wrote:
>> Please review the CSR at: 
>> https://bugs.openjdk.java.net/browse/JDK-8220549
>>
> I added myself as reviewer.
> 
>> Webrev updated in place for this new approach: 
>> http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>
> It looks fine to me.
> 
> Xuelei
> 
>> I changed the synopsis to clarify that we are now removing these 
>> duplicated RSA support.
>>
>> Thanks,
>>
>> Valerie
>>
>>
>> On 3/11/2019 3:59 PM, Valerie Peng wrote:
>>> Thanks for the info, I'd prefer to completely remove the SunRsaSign 
>>> entries from SunJSSE provider as well.
>>>
>>> I will update the webrev and file a CSR then.
>>>
>>> Thanks,
>>>
>>> Valerie
>>>
>>>
>>> On 3/7/2019 7:30 PM, Xuelei Fan wrote:
>>>> On 3/7/2019 6:15 PM, Valerie Peng wrote:
>>>>> Do you mean removing the part about SunRsaSignEntries completely? 
>>>>> Or only remove the MD2/MD5withRSA signature algorithms?
>>>>>
>>>> I meant to remove the SunRsaSignEntries completely from the SunJSSE 
>>>> provider.
>>>>
>>>>> Do you know the history of including them in the first place? Since 
>>>>> SunRsaSign provider has been in early JDK releases, I wonder why 
>>>>> SunJSSE provider duplicated these RSA algorithms in the first place?
>>>> The JSSE provider was originally provided as an standalone library, 
>>>> and using the com.sun.net.ssl packet.? I think it was in JDK 1.4, 
>>>> the package became part of JDK, and start to using the javax.net.ssl 
>>>> package and the standard JCE providers. However, for compatibility, 
>>>> the old supported signature algorithms are still linked in the 
>>>> SunJSSE provider.
>>>>
>>>> In the JDK 9, a noted was added in the SunJSSE provider documentation:
>>>> ?? The SunJSSE provider is for backwards compatibility with
>>>> ?? older releases, and should no longer be used for Signature.
>>>>
>>>> The compatibility is mainly about coding with explicitly SunJSSE 
>>>> provider name.? For example,
>>>> ??? Signature.getInstance("SHA1withRSA",
>>>> ??????? "com.sun.net.ssl.internal.ssl.Provider");
>>>>
>>>> The use may not be common in practice.? And the JDK JCE providers 
>>>> support these algorithms, I was wondering the risk of removing them 
>>>> from the SunJSSE provider may be low now.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>>> I can file a CSR, knowing the history/reason would help.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Valerie
>>>>>
>>>>>
>>>>> On 3/7/2019 5:45 PM, Xuelei Fan wrote:
>>>>>> Hi Valerie,
>>>>>>
>>>>>> As you are already there, I may suggest to remove the old RSA 
>>>>>> crypto algorithms in the SunJSSE providers as well.? As may 
>>>>>> simplify the code a little bit, though a CSR is needed for the 
>>>>>> SunJSSE behavior change.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>> On 3/7/2019 4:56 PM, Valerie Peng wrote:
>>>>>>> Hi Brad,
>>>>>>>
>>>>>>> Do you have time to help review the changes for JDK-8220016? 
>>>>>>> Current changes are to register the same list of RSA-related 
>>>>>>> services as these prior to the fix for JDK-7092821. I am not sure 
>>>>>>> what are the old RSA impls for pre-JDK1.4 implementations. 
>>>>>>> Otherwise, I can remove them as well. Please let me know.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220016
>>>>>>>
>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8220016/webrev.00/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Valerie

From jamil.j.nimeh at oracle.com  Wed Mar 13 15:48:13 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 13 Mar 2019 08:48:13 -0700
Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance(
 algo_, provider_ ) ignores the provider argument.
In-Reply-To: <b1e75b2b-bc20-53ef-f680-a9f25511521f@oracle.com>
References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com>
 <b1e75b2b-bc20-53ef-f680-a9f25511521f@oracle.com>
Message-ID: <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com>

Hi Adam, thanks for the feedback.? I have some comments below:

On 3/13/2019 6:44 AM, Adam Petcher wrote:
> On 3/12/2019 2:33 PM, Jamil Nimeh wrote:
>
>> Hello all,
>>
>> Please review the CSR for the behavioral change to SunJCE's PBKDF2 
>> implementaion.? This change will make the underlying Mac also come 
>> from SunJCE.? This change only affects the SunJCE implementation of 
>> PBKDF2, not any other implementation from any different provider.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8220531
>
> Looks pretty straightforward. I just have a couple of questions 
> related to compatibility:
>
> 1) Is it possible that the requested Mac would not be available in 
> SunJCE, but it would be available in some other provider? If so, then 
> PBKDF2 would fail after this change. Should we fall back to the 
> current behavior if we get a NoSuchAlgorithmException from SunJCE?
JN: It seems unlikely that we would make a SunJCE implementation of a 
given PBKDF2With<prf> if we also don't support the PRF portion.? At 
least up to now we have always supported the PRFs (Hmacs mainly) on 
SunJCE as well.? It would concern me if we were trying to make a 
SecretKeyFactory PBKDF2With<PRF-We-Don't-Have> because, short of a 3rd 
party provider that has it, it would never work.
>
> 2) Do you (or anyone else on the mailing list) have any reason to be 
> concerned that the Mac in SunJCE won't work as well in some cases 
> where it could also come from another (higher-priority) provider? If 
> so, then we should think about adding a system property or other 
> toggle for this behavior. This is a question---not a suggestion. I 
> don't think we should include this toggle unless we have some 
> motivation to do so.
JN: I'd really prefer to not add yet another property to control 
something like this if we don't have to.? If you're selecting SunJCE to 
do PBKDF2 it seems (to me at least) that you're already willing to 
accept that the crypto operations happen in SunJCE software and the PRF 
is really the core of that operation.? Given that a higher priority 3rd 
party provider can hamstring (in admittedly rare cases) SunJCE's 
implementation, I'd much rather see SunJCE always work regardless of 3rd 
party provider configuration than see the underlying PRF move to another 
provider.
>
> Also, if there is no change to any spec, then I think that means the 
> scope is "Implementation" rather than "SE".
JN: I'll make that change.
>
>

From mbalao at redhat.com  Wed Mar 13 16:03:45 2019
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 13 Mar 2019 13:03:45 -0300
Subject: SunJSSE and SunPKCS11 (NSS + FIPS)
In-Reply-To: <89013e89-be40-46f5-0432-2e5ab7ed7c07@oracle.com>
References: <aad7a951-32dd-da32-125b-c6790cc16cb5@redhat.com>
 <89013e89-be40-46f5-0432-2e5ab7ed7c07@oracle.com>
Message-ID: <ea264548-d4ca-0a2f-0e28-254ebbac2f16@redhat.com>

Hi Xuelei,

On 3/13/19 11:05 AM, Xuelei Fan wrote:
> To use FIPS mode JCE provider, an application could:
> 1. implement the required algorithm in the FIPS mode JCE provider.
> 2. don't those algorithms that outside the scope of the FIPS mode JCE
> provider (restrict them).
> 

Yes, there could be a 3rd party JCE provider that implements all the
required algorithms and does not even need any other OpenJDK provider to
be enabled. When it comes to OpenJDK-only providers, the current way to
operate in FIPS is through SunPKCS11. SunPKCS11 alone is not enough for
a TLS engine because X.509 (CertificateFactory) is not supported. We
need SUN provider to be enabled too.

In regards to #2, yes: we can do that. My point, though, is that this is
not an easy and reliable user interface to provide FIPS mode in OpenJDK,
but a workaround. The list of algorithms wouldn't even be fixed. Despite
its drawbacks, the experimental SunJSSE FIPS mode provided a straight
path to this use-case.

I'm not advocating for re-introducing the whole SunJSSE FIPS feature but
wish we could discuss something for providing better support for this
use-case.

Kind regards,
Martin.-

From adam.petcher at oracle.com  Wed Mar 13 16:56:03 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 13 Mar 2019 12:56:03 -0400
Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance(
 algo_, provider_ ) ignores the provider argument.
In-Reply-To: <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com>
References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com>
 <b1e75b2b-bc20-53ef-f680-a9f25511521f@oracle.com>
 <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com>
Message-ID: <1ee9ac30-2925-2ae3-54fa-15f795c55d21@oracle.com>

Looks good. I added myself as a reviewer.

On the subject of PBKDF2With<PRF-We-Don't-Have>: your response makes 
sense. I was concerned about a situation in which we parse the algorithm 
name (similar to Cipher transforms), but it looks like that doesn't 
happen here.

On 3/13/2019 11:48 AM, Jamil Nimeh wrote:
> Hi Adam, thanks for the feedback.? I have some comments below:
>
> On 3/13/2019 6:44 AM, Adam Petcher wrote:
>> On 3/12/2019 2:33 PM, Jamil Nimeh wrote:
>>
>>> Hello all,
>>>
>>> Please review the CSR for the behavioral change to SunJCE's PBKDF2 
>>> implementaion.? This change will make the underlying Mac also come 
>>> from SunJCE.? This change only affects the SunJCE implementation of 
>>> PBKDF2, not any other implementation from any different provider.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8220531
>>
>> Looks pretty straightforward. I just have a couple of questions 
>> related to compatibility:
>>
>> 1) Is it possible that the requested Mac would not be available in 
>> SunJCE, but it would be available in some other provider? If so, then 
>> PBKDF2 would fail after this change. Should we fall back to the 
>> current behavior if we get a NoSuchAlgorithmException from SunJCE?
> JN: It seems unlikely that we would make a SunJCE implementation of a 
> given PBKDF2With<prf> if we also don't support the PRF portion.? At 
> least up to now we have always supported the PRFs (Hmacs mainly) on 
> SunJCE as well.? It would concern me if we were trying to make a 
> SecretKeyFactory PBKDF2With<PRF-We-Don't-Have> because, short of a 3rd 
> party provider that has it, it would never work.
>>
>> 2) Do you (or anyone else on the mailing list) have any reason to be 
>> concerned that the Mac in SunJCE won't work as well in some cases 
>> where it could also come from another (higher-priority) provider? If 
>> so, then we should think about adding a system property or other 
>> toggle for this behavior. This is a question---not a suggestion. I 
>> don't think we should include this toggle unless we have some 
>> motivation to do so.
> JN: I'd really prefer to not add yet another property to control 
> something like this if we don't have to.? If you're selecting SunJCE 
> to do PBKDF2 it seems (to me at least) that you're already willing to 
> accept that the crypto operations happen in SunJCE software and the 
> PRF is really the core of that operation.? Given that a higher 
> priority 3rd party provider can hamstring (in admittedly rare cases) 
> SunJCE's implementation, I'd much rather see SunJCE always work 
> regardless of 3rd party provider configuration than see the underlying 
> PRF move to another provider.
>>
>> Also, if there is no change to any spec, then I think that means the 
>> scope is "Implementation" rather than "SE".
> JN: I'll make that change.
>>
>>

From chris.hegarty at oracle.com  Wed Mar 13 17:04:57 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 13 Mar 2019 17:04:57 +0000
Subject: RFR 8220598: Malformed copyright year range in a few files in
 java.base
Message-ID: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>

Trivially, there should be a comma after the year. Just add it.


$ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
--- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
+++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
--- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
+++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2018, 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
diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java
--- a/src/java.base/share/classes/sun/security/util/IOUtils.java
+++ b/src/java.base/share/classes/sun/security/util/IOUtils.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2009, 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

-Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190313/13e3a176/attachment-0001.html>

From daniel.fuchs at oracle.com  Wed Mar 13 17:09:55 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 13 Mar 2019 17:09:55 +0000
Subject: RFR 8220598: Malformed copyright year range in a few files in
 java.base
In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
Message-ID: <c692e851-9307-5430-b03b-6999a24420fb@oracle.com>

Looks good to me Chris!

cheers,

-- daniel

On 13/03/2019 17:04, Chris Hegarty wrote:
> Trivially, there should be a comma after the year. Just add it.

From lance.andersen at oracle.com  Wed Mar 13 17:10:57 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 13 Mar 2019 13:10:57 -0400
Subject: RFR 8220598: Malformed copyright year range in a few files in
 java.base
In-Reply-To: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
Message-ID: <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com>

+1
> On Mar 13, 2019, at 1:04 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Trivially, there should be a comma after the year. Just add it.
> 
> 
> $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
> diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
> --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
> +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
> --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
> +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2018, 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
> diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java
> --- a/src/java.base/share/classes/sun/security/util/IOUtils.java
> +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2009, 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
> 
> -Chris.

 <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.java.net/pipermail/security-dev/attachments/20190313/99023c22/attachment.html>
-------------- 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.java.net/pipermail/security-dev/attachments/20190313/99023c22/oracle_sig_logo.gif>

From bruce.robb at j42.com  Tue Mar 12 13:54:58 2019
From: bruce.robb at j42.com (Bruce Robb)
Date: Tue, 12 Mar 2019 14:54:58 +0100
Subject: sspi_bridge We have implemented this code,
 here are the changes we had to make
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAOpmq8Cy38VMj/Vj1+s2u54BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAD+RhZrfO+PSYeO5SjtkD9ZAQAAAAA=@j42.com>

Hi Folks,

 

In November last year, one of our J42 for Application Access
<http://www.j42.com/products/j42aa.shtml>  customers suddenly announced that
they would start using Credential Guard.

 

Back in 2009 we worked with them to build an SSO solution using SPNEGO and
JGSS for their 10,000 Windows users.

 

Credential Guard breaks their existing SSO solution so we urgently needed a
way to get JGSS to use SSPI.

Your code from http://cr.openjdk.java.net/~weijun/6722928/webrev.02/
provided the answer.

We have implemented the solution for both Java 8 and Java 11.

We did however find a number of issues during development and testing so we
would like to feed these back to you.

We have written these up in a pdf:
https://portal.j42.com/sso/sspi_bridge_updates.pdf 

 

Let us know if you have any questions or need more information.

We would be happy to use our Active Directory test environment to test your
Open JDK implementation,

 

Regards,

Bruce Robb

 

****************************************************************************
**

J&B Computing Services bv

Celebrating over 30 years of innovative software products and solutions for
satisfied customers

Telephone: +31 343 596 070

Fax: +31 343 596 079

email  <mailto:support at j42.com> support at j42.com

Web Sites:  <http://www.j42.com> http://www.j42.com
<https://portal.j42.com> https://portal.j42.com 

Toll Free (USA): +1 866 580 0076 Registered in KvK Utrecht: 30196450

****************************************************************************
**

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190312/0ea49719/attachment-0001.html>

From shade at redhat.com  Wed Mar 13 16:28:38 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 13 Mar 2019 17:28:38 +0100
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
Message-ID: <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com>

On 3/12/19 11:54 AM, Severin Gehwolf wrote:
> On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/

This looks good, except the change in KdcPolicy.java. See below:
>> Original review:
>> https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html
>>
>> This is not a clean backport because the tests in 8u differ slightly
>> from those in OpenJDK 10:
>>
>> 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly".
>> That same change (adding a property to the @run line) also needs to be
>> applied to the new KdcPolicy.java test for it to succeed.

It looks to me that change to KdcPolicy.java does not relate to 8175120 (this one). It would be
confusing to backport that change under this bug ID? Maybe have a quick and separate 8u-specific fix?

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190313/12c6ae7c/signature-0001.asc>

From xuelei.fan at oracle.com  Wed Mar 13 19:00:19 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 13 Mar 2019 12:00:19 -0700
Subject: SunJSSE and SunPKCS11 (NSS + FIPS)
In-Reply-To: <ea264548-d4ca-0a2f-0e28-254ebbac2f16@redhat.com>
References: <aad7a951-32dd-da32-125b-c6790cc16cb5@redhat.com>
 <89013e89-be40-46f5-0432-2e5ab7ed7c07@oracle.com>
 <ea264548-d4ca-0a2f-0e28-254ebbac2f16@redhat.com>
Message-ID: <989f889a-577d-c076-cdb0-cea3635066c7@oracle.com>

I see your points.  Enabling both Sun and a FIPS mode JCE provider could 
be challenging.

I might be a solution to separate the X.509 services from the Sun provider.

Xuelei

On 3/13/2019 9:03 AM, Martin Balao wrote:
> Hi Xuelei,
> 
> On 3/13/19 11:05 AM, Xuelei Fan wrote:
>> To use FIPS mode JCE provider, an application could:
>> 1. implement the required algorithm in the FIPS mode JCE provider.
>> 2. don't those algorithms that outside the scope of the FIPS mode JCE
>> provider (restrict them).
>>
> 
> Yes, there could be a 3rd party JCE provider that implements all the
> required algorithms and does not even need any other OpenJDK provider to
> be enabled. When it comes to OpenJDK-only providers, the current way to
> operate in FIPS is through SunPKCS11. SunPKCS11 alone is not enough for
> a TLS engine because X.509 (CertificateFactory) is not supported. We
> need SUN provider to be enabled too.
> 
> In regards to #2, yes: we can do that. My point, though, is that this is
> not an easy and reliable user interface to provide FIPS mode in OpenJDK,
> but a workaround. The list of algorithms wouldn't even be fixed. Despite
> its drawbacks, the experimental SunJSSE FIPS mode provided a straight
> path to this use-case.
> 
> I'm not advocating for re-introducing the whole SunJSSE FIPS feature but
> wish we could discuss something for providing better support for this
> use-case.
> 
> Kind regards,
> Martin.-
> 

From sean.mullan at oracle.com  Wed Mar 13 20:03:58 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 13 Mar 2019 16:03:58 -0400
Subject: sspi_bridge We have implemented this code, here are the changes
 we had to make
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAOpmq8Cy38VMj/Vj1+s2u54BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAD+RhZrfO+PSYeO5SjtkD9ZAQAAAAA=@j42.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAOpmq8Cy38VMj/Vj1+s2u54BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAD+RhZrfO+PSYeO5SjtkD9ZAQAAAAA=@j42.com>
Message-ID: <8994dedb-43a8-05bb-d02b-633637b5d47f@oracle.com>

Hi Bruce,

First, thank you for your interest in JGSS and providing feedback. 
Unfortunately, we can't review or accept patches or bug fixes in this 
form from an external site.

I would suggest starting a discussion or summary of each of the issues 
on this alias (without a proposed patch). We can then file a bug (or 
bugs) for the issues that we agree on and when it comes time to submit a 
patch, you will need to first file an OCA (if you have not yet) in order 
for it to be considered for inclusion into the OpenJDK. See 
https://openjdk.java.net/contribute/ for more information on the OCA and 
the process for contributing to OpenJDK in general.

Although this may seem a bit onerous, it is a process that we all abide by.

Thanks,
Sean


On 3/12/19 9:54 AM, Bruce Robb wrote:
> Hi Folks,
> 
> In November last year, one of our J42 for Application Access 
> <http://www.j42.com/products/j42aa.shtml> customers suddenly announced 
> that they would start using Credential Guard.
> 
> Back in 2009 we worked with them to build an SSO solution using SPNEGO 
> and JGSS for their 10,000 Windows users.
> 
> Credential Guard breaks their existing SSO solution so we urgently 
> needed a way to get JGSS to use SSPI.
> 
> Your code from http://cr.openjdk.java.net/~weijun/6722928/webrev.02/ 
>  ?provided the answer.
> 
> We have implemented the solution for both Java 8 and Java 11.
> 
> We did however find a number of issues during development and testing so 
> we would like to feed these back to you.
> 
> We have written these up in a pdf: 
> https://portal.j42.com/sso/sspi_bridge_updates.pdf
> 
> Let us know if you have any questions or need more information.
> 
> We would be happy to use our Active Directory test environment to test 
> your Open JDK implementation,
> 
> Regards,
> 
> Bruce Robb
> 
> ******************************************************************************
> 
> J&B Computing Services bv
> 
> Celebrating over 30 years of innovative software products and solutions 
> for satisfied customers
> 
> Telephone: +31 343 596 070
> 
> Fax: +31 343 596 079
> 
> email support at j42.com <mailto:support at j42.com>
> 
> Web Sites: http://www.j42.com https://portal.j42.com
> 
> Toll Free (USA): +1 866 580 0076 Registered in KvK Utrecht: 30196450
> 
> ******************************************************************************
> 

From weijun.wang at oracle.com  Thu Mar 14 01:14:55 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 14 Mar 2019 09:14:55 +0800
Subject: RFR 8220598: Malformed copyright year range in a few files in
 java.base
In-Reply-To: <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com>
References: <9787F277-114D-415C-83B6-2813B4E51108@oracle.com>
 <839316E6-9ABA-4000-B3C8-A347E536740A@oracle.com>
Message-ID: <B9EBBD14-DE59-4F2C-8A0A-6DE5378491B6@oracle.com>

+1 (on the security class).

Thanks,
Max

> On Mar 14, 2019, at 1:10 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> +1
>> On Mar 13, 2019, at 1:04 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> Trivially, there should be a comma after the year. Just add it.
>> 
>> 
>> $ hg diff src/java.base/share/classes/jdk/ src/java.base/share/classes/sun
>> diff --git a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
>> --- a/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
>> +++ b/src/java.base/share/classes/jdk/internal/util/ArraysSupport.java
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2015, 2017 Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> diff --git a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
>> --- a/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
>> +++ b/src/java.base/share/classes/sun/net/spi/DefaultProxySelector.java
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2003, 2018 Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2003, 2018, 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
>> diff --git a/src/java.base/share/classes/sun/security/util/IOUtils.java b/src/java.base/share/classes/sun/security/util/IOUtils.java
>> --- a/src/java.base/share/classes/sun/security/util/IOUtils.java
>> +++ b/src/java.base/share/classes/sun/security/util/IOUtils.java
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2009, 2017 Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2009, 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
>> 
>> -Chris.
> 
> <oracle_sig_logo.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
> 
> 
> 


From weijun.wang at oracle.com  Thu Mar 14 01:52:55 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 14 Mar 2019 09:52:55 +0800
Subject: RFR[13] JDK-8220410:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with
 missing expected output
In-Reply-To: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>
References: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>
Message-ID: <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com>



> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote:
> 
> Hi,
> This fix just makes sure that specified timezone is not null,

Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop).

BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z.

--Max

> and the jar verifying and date formatting use the same different timezone.
> 
> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410
> 
> Best regards,
> John Jiang
> 


From gnu.andrew at redhat.com  Thu Mar 14 02:31:15 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 14 Mar 2019 02:31:15 +0000
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
 <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com>
Message-ID: <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com>

On 13/03/2019 16:28, Aleksey Shipilev wrote:
> On 3/12/19 11:54 AM, Severin Gehwolf wrote:
>> On Mon, 2019-03-11 at 07:50 +0000, Andrew John Hughes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8175120
>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.01/
> 
> This looks good, except the change in KdcPolicy.java. See below:
>>> Original review:
>>> https://mail.openjdk.java.net/pipermail/security-dev/2017-February/015625.html
>>>
>>> This is not a clean backport because the tests in 8u differ slightly
>>> from those in OpenJDK 10:
>>>
>>> 1. 8u has "JDK-8190690: Impact on krb5 test cases in the 8u nightly".
>>> That same change (adding a property to the @run line) also needs to be
>>> applied to the new KdcPolicy.java test for it to succeed.
> 
> It looks to me that change to KdcPolicy.java does not relate to 8175120 (this one). It would be
> confusing to backport that change under this bug ID? Maybe have a quick and separate 8u-specific fix?
> 

I guess. I didn't know about 8190690 until it came up as a diff between
the versions of the test in the backported patch and those in 8u. As
KdcPolicy.java was failing without it, it seemed logical to move it from
the files being removed to this new test so the replacement test was no
longer broken. But it does affect the clarity of the backport, you're right.

I've filed

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

for that issue and generated a new webrev for 8175120:

https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.02/


> Thanks,
> -Aleksey
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190314/2cf09c19/signature-0001.asc>

From weijun.wang at oracle.com  Thu Mar 14 04:42:02 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 14 Mar 2019 12:42:02 +0800
Subject: sspi_bridge We have implemented this code, here are the changes
 we had to make
In-Reply-To: <8994dedb-43a8-05bb-d02b-633637b5d47f@oracle.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAOpmq8Cy38VMj/Vj1+s2u54BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAD+RhZrfO+PSYeO5SjtkD9ZAQAAAAA=@j42.com>
 <8994dedb-43a8-05bb-d02b-633637b5d47f@oracle.com>
Message-ID: <C96C661E-22E3-4C41-A680-113F88A8FA98@oracle.com>

Hi, owner of 6722928 here, I'm glad my patch is useful for you and many thanks for improving it. As Sean says, please sign the OCA if your improvement is non trivial. Then you can always send the patch file as an attachment and I can convert it to webrev and post it to cr.openjdk.java.net. For other discussions, we can just start in this mail thread.

And can you see if https://cr.openjdk.java.net/~weijun/6722928/webrev.04/ is any more helpful? I've mainly made changes around the SPNEGO (Negotiate) mechanism in the last rounds of changes.

Thanks,
Weijun

> On Mar 14, 2019, at 4:03 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Hi Bruce,
> 
> First, thank you for your interest in JGSS and providing feedback. Unfortunately, we can't review or accept patches or bug fixes in this form from an external site.
> 
> I would suggest starting a discussion or summary of each of the issues on this alias (without a proposed patch). We can then file a bug (or bugs) for the issues that we agree on and when it comes time to submit a patch, you will need to first file an OCA (if you have not yet) in order for it to be considered for inclusion into the OpenJDK. See https://openjdk.java.net/contribute/ for more information on the OCA and the process for contributing to OpenJDK in general.
> 
> Although this may seem a bit onerous, it is a process that we all abide by.
> 
> Thanks,
> Sean
> 
> 
> On 3/12/19 9:54 AM, Bruce Robb wrote:
>> Hi Folks,
>> In November last year, one of our J42 for Application Access <http://www.j42.com/products/j42aa.shtml> customers suddenly announced that they would start using Credential Guard.
>> Back in 2009 we worked with them to build an SSO solution using SPNEGO and JGSS for their 10,000 Windows users.
>> Credential Guard breaks their existing SSO solution so we urgently needed a way to get JGSS to use SSPI.
>> Your code from http://cr.openjdk.java.net/~weijun/6722928/webrev.02/   provided the answer.
>> We have implemented the solution for both Java 8 and Java 11.
>> We did however find a number of issues during development and testing so we would like to feed these back to you.
>> We have written these up in a pdf: https://portal.j42.com/sso/sspi_bridge_updates.pdf
>> Let us know if you have any questions or need more information.
>> We would be happy to use our Active Directory test environment to test your Open JDK implementation,
>> Regards,
>> Bruce Robb
>> ******************************************************************************
>> J&B Computing Services bv
>> Celebrating over 30 years of innovative software products and solutions for satisfied customers
>> Telephone: +31 343 596 070
>> Fax: +31 343 596 079
>> email support at j42.com <mailto:support at j42.com>
>> Web Sites: http://www.j42.com https://portal.j42.com
>> Toll Free (USA): +1 866 580 0076 Registered in KvK Utrecht: 30196450
>> ******************************************************************************


From sean.mullan at oracle.com  Thu Mar 14 12:46:16 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 14 Mar 2019 08:46:16 -0400
Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance(
 algo_, provider_ ) ignores the provider argument.
In-Reply-To: <1ee9ac30-2925-2ae3-54fa-15f795c55d21@oracle.com>
References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com>
 <b1e75b2b-bc20-53ef-f680-a9f25511521f@oracle.com>
 <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com>
 <1ee9ac30-2925-2ae3-54fa-15f795c55d21@oracle.com>
Message-ID: <78bcf584-b923-b024-d803-0704d1b00168@oracle.com>

Jamil,

I think it might make sense to change the bug synopsis since it isn't 
really ignoring the provider argument.

Maybe "Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation".

Thanks,
Sean

On 3/13/19 12:56 PM, Adam Petcher wrote:
> Looks good. I added myself as a reviewer.
> 
> On the subject of PBKDF2With<PRF-We-Don't-Have>: your response makes 
> sense. I was concerned about a situation in which we parse the algorithm 
> name (similar to Cipher transforms), but it looks like that doesn't 
> happen here.
> 
> On 3/13/2019 11:48 AM, Jamil Nimeh wrote:
>> Hi Adam, thanks for the feedback.? I have some comments below:
>>
>> On 3/13/2019 6:44 AM, Adam Petcher wrote:
>>> On 3/12/2019 2:33 PM, Jamil Nimeh wrote:
>>>
>>>> Hello all,
>>>>
>>>> Please review the CSR for the behavioral change to SunJCE's PBKDF2 
>>>> implementaion.? This change will make the underlying Mac also come 
>>>> from SunJCE.? This change only affects the SunJCE implementation of 
>>>> PBKDF2, not any other implementation from any different provider.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8220531
>>>
>>> Looks pretty straightforward. I just have a couple of questions 
>>> related to compatibility:
>>>
>>> 1) Is it possible that the requested Mac would not be available in 
>>> SunJCE, but it would be available in some other provider? If so, then 
>>> PBKDF2 would fail after this change. Should we fall back to the 
>>> current behavior if we get a NoSuchAlgorithmException from SunJCE?
>> JN: It seems unlikely that we would make a SunJCE implementation of a 
>> given PBKDF2With<prf> if we also don't support the PRF portion.? At 
>> least up to now we have always supported the PRFs (Hmacs mainly) on 
>> SunJCE as well.? It would concern me if we were trying to make a 
>> SecretKeyFactory PBKDF2With<PRF-We-Don't-Have> because, short of a 3rd 
>> party provider that has it, it would never work.
>>>
>>> 2) Do you (or anyone else on the mailing list) have any reason to be 
>>> concerned that the Mac in SunJCE won't work as well in some cases 
>>> where it could also come from another (higher-priority) provider? If 
>>> so, then we should think about adding a system property or other 
>>> toggle for this behavior. This is a question---not a suggestion. I 
>>> don't think we should include this toggle unless we have some 
>>> motivation to do so.
>> JN: I'd really prefer to not add yet another property to control 
>> something like this if we don't have to.? If you're selecting SunJCE 
>> to do PBKDF2 it seems (to me at least) that you're already willing to 
>> accept that the crypto operations happen in SunJCE software and the 
>> PRF is really the core of that operation.? Given that a higher 
>> priority 3rd party provider can hamstring (in admittedly rare cases) 
>> SunJCE's implementation, I'd much rather see SunJCE always work 
>> regardless of 3rd party provider configuration than see the underlying 
>> PRF move to another provider.
>>>
>>> Also, if there is no change to any spec, then I think that means the 
>>> scope is "Implementation" rather than "SE".
>> JN: I'll make that change.
>>>
>>>

From jamil.j.nimeh at oracle.com  Thu Mar 14 13:34:54 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 14 Mar 2019 06:34:54 -0700
Subject: CSR Review Request: JDK-8220531, SecretKeyFactory.getInstance(
 algo_, provider_ ) ignores the provider argument.
In-Reply-To: <78bcf584-b923-b024-d803-0704d1b00168@oracle.com>
References: <46c84d59-c0c3-720a-ba09-1f93a603c213@oracle.com>
 <b1e75b2b-bc20-53ef-f680-a9f25511521f@oracle.com>
 <2b646bab-62a5-af4d-6ac5-e6acb53a33e4@oracle.com>
 <1ee9ac30-2925-2ae3-54fa-15f795c55d21@oracle.com>
 <78bcf584-b923-b024-d803-0704d1b00168@oracle.com>
Message-ID: <35af2b82-64d6-1eda-b85b-18d2a753eb19@oracle.com>

Yes, I was thinking that might be a good idea too.? I'll make that 
change shortly.

Thanks,

--Jamil

On 3/14/19 5:46 AM, Sean Mullan wrote:
> Jamil,
>
> I think it might make sense to change the bug synopsis since it isn't 
> really ignoring the provider argument.
>
> Maybe "Use SunJCE Mac in SecretKeyFactory PBKDF2 implementation".
>
> Thanks,
> Sean
>
> On 3/13/19 12:56 PM, Adam Petcher wrote:
>> Looks good. I added myself as a reviewer.
>>
>> On the subject of PBKDF2With<PRF-We-Don't-Have>: your response makes 
>> sense. I was concerned about a situation in which we parse the 
>> algorithm name (similar to Cipher transforms), but it looks like that 
>> doesn't happen here.
>>
>> On 3/13/2019 11:48 AM, Jamil Nimeh wrote:
>>> Hi Adam, thanks for the feedback.? I have some comments below:
>>>
>>> On 3/13/2019 6:44 AM, Adam Petcher wrote:
>>>> On 3/12/2019 2:33 PM, Jamil Nimeh wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> Please review the CSR for the behavioral change to SunJCE's PBKDF2 
>>>>> implementaion.? This change will make the underlying Mac also come 
>>>>> from SunJCE.? This change only affects the SunJCE implementation 
>>>>> of PBKDF2, not any other implementation from any different provider.
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8220531
>>>>
>>>> Looks pretty straightforward. I just have a couple of questions 
>>>> related to compatibility:
>>>>
>>>> 1) Is it possible that the requested Mac would not be available in 
>>>> SunJCE, but it would be available in some other provider? If so, 
>>>> then PBKDF2 would fail after this change. Should we fall back to 
>>>> the current behavior if we get a NoSuchAlgorithmException from SunJCE?
>>> JN: It seems unlikely that we would make a SunJCE implementation of 
>>> a given PBKDF2With<prf> if we also don't support the PRF portion.? 
>>> At least up to now we have always supported the PRFs (Hmacs mainly) 
>>> on SunJCE as well. It would concern me if we were trying to make a 
>>> SecretKeyFactory PBKDF2With<PRF-We-Don't-Have> because, short of a 
>>> 3rd party provider that has it, it would never work.
>>>>
>>>> 2) Do you (or anyone else on the mailing list) have any reason to 
>>>> be concerned that the Mac in SunJCE won't work as well in some 
>>>> cases where it could also come from another (higher-priority) 
>>>> provider? If so, then we should think about adding a system 
>>>> property or other toggle for this behavior. This is a 
>>>> question---not a suggestion. I don't think we should include this 
>>>> toggle unless we have some motivation to do so.
>>> JN: I'd really prefer to not add yet another property to control 
>>> something like this if we don't have to.? If you're selecting SunJCE 
>>> to do PBKDF2 it seems (to me at least) that you're already willing 
>>> to accept that the crypto operations happen in SunJCE software and 
>>> the PRF is really the core of that operation.? Given that a higher 
>>> priority 3rd party provider can hamstring (in admittedly rare cases) 
>>> SunJCE's implementation, I'd much rather see SunJCE always work 
>>> regardless of 3rd party provider configuration than see the 
>>> underlying PRF move to another provider.
>>>>
>>>> Also, if there is no change to any spec, then I think that means 
>>>> the scope is "Implementation" rather than "SE".
>>> JN: I'll make that change.
>>>>
>>>>

From jamil.j.nimeh at oracle.com  Thu Mar 14 13:34:05 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 14 Mar 2019 06:34:05 -0700
Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignores
 the provider argument.
Message-ID: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>

Hello all,

This review will change the SunJCE implementation of PBKDF2 so that it 
always uses the SunJCE version of the PRF algorithm internally.

Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/

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

CSR: https://bugs.openjdk.java.net/browse/JDK-8220531


From shade at redhat.com  Thu Mar 14 08:56:37 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 14 Mar 2019 09:56:37 +0100
Subject: [8u] [RFR] 8175120: Remove old tests on kdc timeout policy
In-Reply-To: <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com>
References: <a557d30d-3962-59e6-2ed5-3e165c92b775@redhat.com>
 <486c62c3ade3657e3c98203e27bfadc7a3d51f7c.camel@redhat.com>
 <871646f6-7646-18e6-6d22-8348e8e555be@redhat.com>
 <39dfbb3e-c5ff-b43c-767a-4664c76039f7@redhat.com>
Message-ID: <9e717b95-1b62-390c-9c25-ea63783668d0@redhat.com>

On 3/14/19 3:31 AM, Andrew John Hughes wrote:
> I've filed
> https://bugs.openjdk.java.net/browse/JDK-8220641

Yes, let's RFR and push that too.

> for that issue and generated a new webrev for 8175120:
> 
> https://cr.openjdk.java.net/~andrew/openjdk8/8175120/webrev.02/

Looks good!

-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190314/4065022b/signature.asc>

From adam.petcher at oracle.com  Thu Mar 14 14:53:05 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Thu, 14 Mar 2019 10:53:05 -0400
Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )
 ignores the provider argument.
In-Reply-To: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
Message-ID: <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com>

The change to PBKDF2KeyImpl.java looks fine. About the test:

*) Is it necessary to put the provider in a separate jar? It seems 
unnecessary because you are adding it with Security.insertProviderAt.

*) Line 54 of the test compares the result of a constructor to null. 
Unless I'm missing something, this reference will always be non-null.

*) At the end of the test, there are some methods that do conversion 
between hex strings and bytes. Can you use the methods in Convert (in 
the test list) instead? I think Convert.hexStringToByteArray is the same 
thing as hex2bin. You may also want to move dumpHexBytes to Convert, but 
it's fine either way.

*) It looks the evilprovider source files have the wrong copyright header.

*) There is a commented out line of code on line 16 of EvilProvider.java

On 3/14/2019 9:34 AM, Jamil Nimeh wrote:
> Hello all,
>
> This review will change the SunJCE implementation of PBKDF2 so that it 
> always uses the SunJCE version of the PRF algorithm internally.
>
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8220531
>

From jamil.j.nimeh at oracle.com  Thu Mar 14 15:18:12 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 14 Mar 2019 08:18:12 -0700
Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )
 ignores the provider argument.
In-Reply-To: <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
 <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com>
Message-ID: <db8a8ff7-41fd-60ea-38d1-51d9c3802c51@oracle.com>

Hi Adam, thanks for taking a look at this.? Comments are in-line:

On 3/14/19 7:53 AM, Adam Petcher wrote:
> The change to PBKDF2KeyImpl.java looks fine. About the test:
>
> *) Is it necessary to put the provider in a separate jar? It seems 
> unnecessary because you are adding it with Security.insertProviderAt.
JN: I'm honestly not sure.? I thought if I wanted this test to run on 
both Open and Oracle JDK I thought I'd need the provider to be signed 
(which the jar file is).? I can try bringing the provider code into the 
test body itself.? If it runs fine on Oracle JDK then it would be way 
better to do that and get rid of the makefile and all the attendant 
source for rebuilding the provider jar.
>
> *) Line 54 of the test compares the result of a constructor to null. 
> Unless I'm missing something, this reference will always be non-null.
JN: That was left over from an early rev of the test where I was doing 
Security.getProvider(String) where it can return null.? I'll take that out.
>
> *) At the end of the test, there are some methods that do conversion 
> between hex strings and bytes. Can you use the methods in Convert (in 
> the test list) instead? I think Convert.hexStringToByteArray is the 
> same thing as hex2bin. You may also want to move dumpHexBytes to 
> Convert, but it's fine either way.
JN: I had meant to fix that before I sent it to review, I'm in the 
process of making that change now.
>
> *) It looks the evilprovider source files have the wrong copyright 
> header.
JN: Easily fixed.
>
> *) There is a commented out line of code on line 16 of EvilProvider.java
JN: Good as gone.
>
> On 3/14/2019 9:34 AM, Jamil Nimeh wrote:
>> Hello all,
>>
>> This review will change the SunJCE implementation of PBKDF2 so that 
>> it always uses the SunJCE version of the PRF algorithm internally.
>>
>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8220531
>>

From ecki at zusammenkunft.net  Thu Mar 14 15:58:00 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 14 Mar 2019 16:58:00 +0100
Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )
 ignoresthe provider argument.
In-Reply-To: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
Message-ID: <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com>

Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval?

(I think the change is good in General but that case Needs to be decided).

Since this is relaed, using a whitebox prf would also allow to do precomputing of the first hmac block outside of the Iteration, thats an algorithmic speedup* which attackers implementations surely feature.

Gruss
Bernd

* OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf 
-- 
http://bernd.eckenfels.net

Von: Jamil Nimeh
Gesendet: Donnerstag, 14. M?rz 2019 16:36
An: OpenJDK Dev list
Betreff: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.

Hello all,

This review will change the SunJCE implementation of PBKDF2 so that it 
always uses the SunJCE version of the PRF algorithm internally.

Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/

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

CSR: https://bugs.openjdk.java.net/browse/JDK-8220531


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190314/66e6d29f/attachment.html>

From jamil.j.nimeh at oracle.com  Thu Mar 14 16:16:09 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 14 Mar 2019 09:16:09 -0700
Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )
 ignoresthe provider argument.
In-Reply-To: <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
 <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com>
Message-ID: <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com>

Hi Bernd, thanks for the feedback, comments below:

On 3/14/19 8:58 AM, Bernd Eckenfels wrote:
>
> Looking at the patch it seems obvious that this functionality was 
> intentional at least for having a PKCS11 MAC. Do we really want to 
> removbe that Option and if yes des it require some form of aproval?
>
> (I think the change is good in General but that case Needs to be decided).
>
JN: Yes, there is definitely an approval process which is in progress.? 
The CSR link in the original email is the approval process for a 
behavioral change like this.? The fix itself, even if it is good, won't 
go back until the CSR is approved.

As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: 
Ideally the underlying Mac should be able to come from 3rd party 
providers.? And for a long time this worked.? But now we're up against a 
case where a BC FIPS provider's HMAC implementation is causing the 
SunJCE PBKDF2 implementation to fail.? And it fails not because the PRF 
algorithm isn't found, it fails on init.? If we're requesting SunJCE by 
name (as it was in the case that caused the bug) the mere presence of BC 
FIPS as a higher priority provider shouldn't cause this kind of failure. 
There's nothing wrong with either provider in general, but the 
interaction between the two has had this unexpected consequence.

There's no easy way get the best of both worlds.? By the time we're down 
in the guts of the PBKDF2 key implementation where the PRF is 
instantiated, we know we're on the SunJCE provider, but we don't know 
*how* we got there (by automatic selection or by being chosen 
explicitly).? So it's hard to make an intelligent decision about whether 
to use the SunJCE version (which will always work) or risk going out to 
a 3rd party provider (which usually works, but not in this case).

Given the choice, I'm opting for "always working" since SunJCE was 
already selected (one way or the other) for PBKDF2.? The PRF is the key 
cryptographic piece of that operation so it's not outrageous that it too 
should come from SunJCE.

> Since this is relaed, using a whitebox prf would also allow to do 
> precomputing of the first hmac block outside of the Iteration, thats 
> an algorithmic speedup* which attackers implementations surely feature.
>
> Gruss
>
> Bernd
>
> * OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf
>
> -- 
> http://bernd.eckenfels.net
>
> *Von: *Jamil Nimeh <mailto:jamil.j.nimeh at oracle.com>
> *Gesendet: *Donnerstag, 14. M?rz 2019 16:36
> *An: *OpenJDK Dev list <mailto:security-dev at openjdk.java.net>
> *Betreff: *RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ 
> ) ignoresthe provider argument.
>
> Hello all,
>
> This review will change the SunJCE implementation of PBKDF2 so that it
>
> always uses the SunJCE version of the PRF algorithm internally.
>
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8220531
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190314/90f22847/attachment.html>

From ecki at zusammenkunft.net  Thu Mar 14 16:30:52 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 14 Mar 2019 17:30:52 +0100
Subject: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_
 )ignoresthe provider argument.
In-Reply-To: <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
 <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com>
 <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com>
Message-ID: <5c8a81bc.1c69fb81.632f5.56b9@mx.google.com>

Hello,

is there no case where the passed-in key cannot be used by the SunJCE provider? Isnt that a main reason to use an alternative Provider and PKCS11 especially? I think similiar could be said for MSCAPI (but I think they have no keyhandles for secret keys) or other FIPS Keystores which do not allow to Export key material.

One Option would be to make the Mac an Parameter, then at least new Code could specify different implementers. It still would break existing PKCS11 deployments (at least for those where the keymaterial is not exportable)

I would argue that the case when you use a JCE PBKDF2 on a JVM where BC FIPS has higher prio would be wrong anyway.

I thin I havent seen what the case for the init falure in BC MAC was, is this also key related?

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Jamil Nimeh
Gesendet: Donnerstag, 14. M?rz 2019 17:18
An: Bernd Eckenfels; OpenJDK Dev list
Betreff: Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument.

Hi Bernd, thanks for the feedback, comments below:
On 3/14/19 8:58 AM, Bernd Eckenfels wrote:
Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval?
?
(I think the change is good in General but that case Needs to be decided).
JN: Yes, there is definitely an approval process which is in progress.? The CSR link in the original email is the approval process for a behavioral change like this.? The fix itself, even if it is good, won't go back until the CSR is approved.
As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: Ideally the underlying Mac should be able to come from 3rd party providers.? And for a long time this worked.? But now we're up against a case where a BC FIPS provider's HMAC implementation is causing the SunJCE PBKDF2 implementation to fail.? And it fails not because the PRF algorithm isn't found, it fails on init.? If we're requesting SunJCE by name (as it was in the case that caused the bug) the mere presence of BC FIPS as a higher priority provider shouldn't cause this kind of failure.? There's nothing wrong with either provider in general, but the interaction between the two has had this unexpected consequence.
There's no easy way get the best of both worlds.? By the time we're down in the guts of the PBKDF2 key implementation where the PRF is instantiated, we know we're on the SunJCE provider, but we don't know *how* we got there (by automatic selection or by being chosen explicitly).? So it's hard to make an intelligent decision about whether to use the SunJCE version (which will always work) or risk going out to a 3rd party provider (which usually works, but not in this case).
Given the choice, I'm opting for "always working" since SunJCE was already selected (one way or the other) for PBKDF2.? The PRF is the key cryptographic piece of that operation so it's not outrageous that it too should come from SunJCE.
?
Since this is relaed, using a whitebox prf would also allow to do precomputing of the first hmac block outside of the Iteration, thats an algorithmic speedup* which attackers implementations surely feature.
?
Gruss
Bernd
?
* OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf 
-- 
http://bernd.eckenfels.net
?
Von: Jamil Nimeh
Gesendet: Donnerstag, 14. M?rz 2019 16:36
An: OpenJDK Dev list
Betreff: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.
?
Hello all,
?
This review will change the SunJCE implementation of PBKDF2 so that it 
always uses the SunJCE version of the PRF algorithm internally.
?
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
?
JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
?
CSR: https://bugs.openjdk.java.net/browse/JDK-8220531
?
?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190314/3c1f2fc3/attachment-0001.html>

From jamil.j.nimeh at oracle.com  Thu Mar 14 17:12:48 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 14 Mar 2019 10:12:48 -0700
Subject: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_
 )ignoresthe provider argument.
In-Reply-To: <5c8a81bc.1c69fb81.632f5.56b9@mx.google.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
 <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com>
 <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com>
 <5c8a81bc.1c69fb81.632f5.56b9@mx.google.com>
Message-ID: <97dca02b-a438-4a74-9596-68daf0dbdb73@oracle.com>

Hello Bernd, once again I appreciate your comments and have some of my 
own in-line,

On 3/14/2019 9:30 AM, Bernd Eckenfels wrote:
>
> Hello,
>
> is there no case where the passed-in key cannot be used by the SunJCE 
> provider? Isnt that a main reason to use an alternative Provider and 
> PKCS11 especially? I think similiar could be said for MSCAPI (but I 
> think they have no keyhandles for secret keys) or other FIPS Keystores 
> which do not allow to Export key material.
>
JN: Is there no case?? None that I'm aware of, none that have caused any 
bugs that I know of - the SecretKey object is made within SunJCE's 
PBKDF2KeyImpl code (looks like it is just a SecretKey wrapper around the 
password bytes).? It seems like it should work for pretty much any 
password handed in AFAICT.

If you were going to have a FIPS keystore come into play, why would you 
not use that 3rd party provider for the PBKDF2 SecretKeyFactory in its 
entirety?? That way the resulting SecretKey from a generation operation 
would hopefully live on the FIPS keystore serviced by that provider.? 
For SunJCE I think you'd end up having a SecretKey that lived in SunJCE 
since you're only going to a 3rd party provider for the HMAC 
calculations.? It just feels a little odd to hang a security argument on 
a 3rd party provider for HMAC, but be willing to do the encompassing 
PBKDF2 on SunJCE.

All that said, I think even if HMAC is obtained from SunJCE, the 
underlying MessageDigest probably would come from that 3rd party 
provider.? But of course there's no key involved, no init to be done, so 
it's less prone to going wonky.
>
> One Option would be to make the Mac an Parameter, then at least new 
> Code could specify different implementers. It still would break 
> existing PKCS11 deployments (at least for those where the keymaterial 
> is not exportable)
>
JN: An option, certainly, but one that would mean at least an API change 
to PBEKeySpec so the Mac could be passed into the SecretKeyFactory.? 
That would require much more careful consideration and it would prevent 
backporting this bugfix since PBEKeySpec is set in stone for any 
released JDK.

> I would argue that the case when you use a JCE PBKDF2 on a JVM where 
> BC FIPS has higher prio would be wrong anyway.
>
JN: Generally yes, but not for a case where you ask explicitly for 
PBKDF2 on SunJCE like SecretKeyFactory.getInstance(String algorithm, 
String provider).? That's what happened when the bug occurred. While I 
don't think it would happen otherwise on BC FIPS (I haven't checked but 
I assume it has PBKDF2WithHmacSHA1), it is possible for automatic 
selection to land on SunJCE for that SKF algorithm if some other higher 
priority provider doesn't have PBKDF2WithHmacSHA1, but does have 
HmacSHA1 with some FIPS-like key restrictions (which seems like a 
realistic possibility).
>
> I thin I havent seen what the case for the init falure in BC MAC was, 
> is this also key related?
>
JN: If you look at the original bug the stack trace is there.? In short 
BC is throwing org.bouncycastle.crypto.IllegalKeyException because the 
key that is being handed to it while running in FIPS mode is less than 
112 bits (according to the exception message).
>
> Gruss
>
> Bernd
>
> -- 
> http://bernd.eckenfels.net
>
> *Von: *Jamil Nimeh <mailto:jamil.j.nimeh at oracle.com>
> *Gesendet: *Donnerstag, 14. M?rz 2019 17:18
> *An: *Bernd Eckenfels <mailto:ecki at zusammenkunft.net>; OpenJDK Dev 
> list <mailto:security-dev at openjdk.java.net>
> *Betreff: *Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, 
> provider_ )ignoresthe provider argument.
>
> Hi Bernd, thanks for the feedback, comments below:
>
> On 3/14/19 8:58 AM, Bernd Eckenfels wrote:
>
>     Looking at the patch it seems obvious that this functionality was
>     intentional at least for having a PKCS11 MAC. Do we really want to
>     removbe that Option and if yes des it require some form of aproval?
>
>     (I think the change is good in General but that case Needs to be
>     decided).
>
> JN: Yes, there is definitely an approval process which is in 
> progress.? The CSR link in the original email is the approval process 
> for a behavioral change like this.? The fix itself, even if it is 
> good, won't go back until the CSR is approved.
>
> As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: 
> Ideally the underlying Mac should be able to come from 3rd party 
> providers.? And for a long time this worked. But now we're up against 
> a case where a BC FIPS provider's HMAC implementation is causing the 
> SunJCE PBKDF2 implementation to fail.? And it fails not because the 
> PRF algorithm isn't found, it fails on init.? If we're requesting 
> SunJCE by name (as it was in the case that caused the bug) the mere 
> presence of BC FIPS as a higher priority provider shouldn't cause this 
> kind of failure.? There's nothing wrong with either provider in 
> general, but the interaction between the two has had this unexpected 
> consequence.
>
> There's no easy way get the best of both worlds.? By the time we're 
> down in the guts of the PBKDF2 key implementation where the PRF is 
> instantiated, we know we're on the SunJCE provider, but we don't know 
> *how* we got there (by automatic selection or by being chosen 
> explicitly).? So it's hard to make an intelligent decision about 
> whether to use the SunJCE version (which will always work) or risk 
> going out to a 3rd party provider (which usually works, but not in 
> this case).
>
> Given the choice, I'm opting for "always working" since SunJCE was 
> already selected (one way or the other) for PBKDF2.? The PRF is the 
> key cryptographic piece of that operation so it's not outrageous that 
> it too should come from SunJCE.
>
>     Since this is relaed, using a whitebox prf would also allow to do
>     precomputing of the first hmac block outside of the Iteration,
>     thats an algorithmic speedup* which attackers implementations
>     surely feature.
>
>     Gruss
>
>     Bernd
>
>     * OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf
>
>     -- 
>     http://bernd.eckenfels.net
>
>     *Von: *Jamil Nimeh <mailto:jamil.j.nimeh at oracle.com>
>     *Gesendet: *Donnerstag, 14. M?rz 2019 16:36
>     *An: *OpenJDK Dev list <mailto:security-dev at openjdk.java.net>
>     *Betreff: *RFR 8218723: SecretKeyFactory.getInstance( algo_,
>     provider_ ) ignoresthe provider argument.
>
>     Hello all,
>
>     This review will change the SunJCE implementation of PBKDF2 so
>     that it
>
>     always uses the SunJCE version of the PRF algorithm internally.
>
>     Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
>
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
>
>     CSR: https://bugs.openjdk.java.net/browse/JDK-8220531
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190314/9e2e0e48/attachment.html>

From ecki at zusammenkunft.net  Thu Mar 14 17:23:37 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 14 Mar 2019 18:23:37 +0100
Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_,
 provider_)ignoresthe provider argument.
In-Reply-To: <97dca02b-a438-4a74-9596-68daf0dbdb73@oracle.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
 <5c8a7a08.1c69fb81.9e9af.57df@mx.google.com>
 <93414fe6-82b4-a386-6c35-6a9b2f706770@oracle.com>
 <5c8a81bc.1c69fb81.632f5.56b9@mx.google.com>
 <97dca02b-a438-4a74-9596-68daf0dbdb73@oracle.com>
Message-ID: <5c8a8e19.1c69fb81.8ffc3.5842@mx.google.com>

Hello,

yes you are right, in the PBKDF2 case there is no external key object which can hit the MAC, so this seems safe. Thanks for bearing with me ??

Ist BTW funny how many people want to use a FIPS compliant library and then not use the FIPS restrictions ??  (well actually it is not funny, the FIPS provisions are more sad in that case?)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Jamil Nimeh
Gesendet: Donnerstag, 14. M?rz 2019 18:16
An: Bernd Eckenfels; OpenJDK Dev list
Betreff: Re: AW: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_)ignoresthe provider argument.

Hello Bernd, once again I appreciate your comments and have some of my own in-line,
On 3/14/2019 9:30 AM, Bernd Eckenfels wrote:
Hello,
?
is there no case where the passed-in key cannot be used by the SunJCE provider? Isnt that a main reason to use an alternative Provider and PKCS11 especially? I think similiar could be said for MSCAPI (but I think they have no keyhandles for secret keys) or other FIPS Keystores which do not allow to Export key material.
JN: Is there no case?? None that I'm aware of, none that have caused any bugs that I know of - the SecretKey object is made within SunJCE's PBKDF2KeyImpl code (looks like it is just a SecretKey wrapper around the password bytes).? It seems like it should work for pretty much any password handed in AFAICT.

If you were going to have a FIPS keystore come into play, why would you not use that 3rd party provider for the PBKDF2 SecretKeyFactory in its entirety?? That way the resulting SecretKey from a generation operation would hopefully live on the FIPS keystore serviced by that provider.? For SunJCE I think you'd end up having a SecretKey that lived in SunJCE since you're only going to a 3rd party provider for the HMAC calculations.? It just feels a little odd to hang a security argument on a 3rd party provider for HMAC, but be willing to do the encompassing PBKDF2 on SunJCE.

All that said, I think even if HMAC is obtained from SunJCE, the underlying MessageDigest probably would come from that 3rd party provider.? But of course there's no key involved, no init to be done, so it's less prone to going wonky.

?
One Option would be to make the Mac an Parameter, then at least new Code could specify different implementers. It still would break existing PKCS11 deployments (at least for those where the keymaterial is not exportable)
JN: An option, certainly, but one that would mean at least an API change to PBEKeySpec so the Mac could be passed into the SecretKeyFactory.? That would require much more careful consideration and it would prevent backporting this bugfix since PBEKeySpec is set in stone for any released JDK.


?
I would argue that the case when you use a JCE PBKDF2 on a JVM where BC FIPS has higher prio would be wrong anyway.
JN: Generally yes, but not for a case where you ask explicitly for PBKDF2 on SunJCE like SecretKeyFactory.getInstance(String algorithm, String provider).? That's what happened when the bug occurred.? While I don't think it would happen otherwise on BC FIPS (I haven't checked but I assume it has PBKDF2WithHmacSHA1), it is possible for automatic selection to land on SunJCE for that SKF algorithm if some other higher priority provider doesn't have PBKDF2WithHmacSHA1, but does have HmacSHA1 with some FIPS-like key restrictions (which seems like a realistic possibility).

?
I thin I havent seen what the case for the init falure in BC MAC was, is this also key related?
JN: If you look at the original bug the stack trace is there.? In short BC is throwing org.bouncycastle.crypto.IllegalKeyException because the key that is being handed to it while running in FIPS mode is less than 112 bits (according to the exception message).

?
Gruss
Bernd
-- 
http://bernd.eckenfels.net
?
Von: Jamil Nimeh
Gesendet: Donnerstag, 14. M?rz 2019 17:18
An: Bernd Eckenfels; OpenJDK Dev list
Betreff: Re: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )ignoresthe provider argument.
?
Hi Bernd, thanks for the feedback, comments below:
On 3/14/19 8:58 AM, Bernd Eckenfels wrote:
Looking at the patch it seems obvious that this functionality was intentional at least for having a PKCS11 MAC. Do we really want to removbe that Option and if yes des it require some form of aproval?
?
(I think the change is good in General but that case Needs to be decided).
JN: Yes, there is definitely an approval process which is in progress.? The CSR link in the original email is the approval process for a behavioral change like this.? The fix itself, even if it is good, won't go back until the CSR is approved.
As far as a PKCS#11 Mac, or a Mac from any 3rd party is concerned: Ideally the underlying Mac should be able to come from 3rd party providers.? And for a long time this worked.? But now we're up against a case where a BC FIPS provider's HMAC implementation is causing the SunJCE PBKDF2 implementation to fail.? And it fails not because the PRF algorithm isn't found, it fails on init.? If we're requesting SunJCE by name (as it was in the case that caused the bug) the mere presence of BC FIPS as a higher priority provider shouldn't cause this kind of failure.? There's nothing wrong with either provider in general, but the interaction between the two has had this unexpected consequence.
There's no easy way get the best of both worlds.? By the time we're down in the guts of the PBKDF2 key implementation where the PRF is instantiated, we know we're on the SunJCE provider, but we don't know *how* we got there (by automatic selection or by being chosen explicitly).? So it's hard to make an intelligent decision about whether to use the SunJCE version (which will always work) or risk going out to a 3rd party provider (which usually works, but not in this case).
Given the choice, I'm opting for "always working" since SunJCE was already selected (one way or the other) for PBKDF2.? The PRF is the key cryptographic piece of that operation so it's not outrageous that it too should come from SunJCE.
?
Since this is relaed, using a whitebox prf would also allow to do precomputing of the first hmac block outside of the Iteration, thats an algorithmic speedup* which attackers implementations surely feature.
?
Gruss
Bernd
?
* OPT-02 in https://afiuorio.github.io/assets/thesis_afi_msc.pdf 
-- 
http://bernd.eckenfels.net
?
Von: Jamil Nimeh
Gesendet: Donnerstag, 14. M?rz 2019 16:36
An: OpenJDK Dev list
Betreff: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ ) ignoresthe provider argument.
?
Hello all,
?
This review will change the SunJCE implementation of PBKDF2 so that it 
always uses the SunJCE version of the PRF algorithm internally.
?
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
?
JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
?
CSR: https://bugs.openjdk.java.net/browse/JDK-8220531
?
?
?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190314/4a11fa04/attachment-0001.html>

From gnu.andrew at redhat.com  Fri Mar 15 04:55:45 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 15 Mar 2019 04:55:45 +0000
Subject: [RFR] [8u] 8220641, ,
 New test KdcPolicy.java introduced by JDK-8164656
 needs same change as JDK-8190690
Message-ID: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/

This is the patch we split out from my original post for 8175120. It
applies the same change to the @run command in KdcPolicy.java as was
applied to the tests deleted by 8175120 in JDK-8190690.

Without this fix, the test fails with a name lookup error. With it, it
passes.

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008846.html
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190315/66c71dc6/signature.asc>

From sgehwolf at redhat.com  Fri Mar 15 09:07:52 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 15 Mar 2019 10:07:52 +0100
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
Message-ID: <715a7ac719a9a1ef652fd12c8050ab1d80913e9a.camel@redhat.com>

Hi Andrew,

On Fri, 2019-03-15 at 04:55 +0000, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
> Webrev: 
> https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
> 
> This is the patch we split out from my original post for 8175120. It
> applies the same change to the @run command in KdcPolicy.java as was
> applied to the tests deleted by 8175120 in JDK-8190690.
> 
> Without this fix, the test fails with a name lookup error. With it, it
> passes.

This looks good to me. I'm not an 8u Reviewer, though.

Thanks,
Severin


> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008846.html


From GROEGES at uk.ibm.com  Fri Mar 15 09:46:33 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Fri, 15 Mar 2019 09:46:33 +0000
Subject: Use of OpenSSL as JCE security provider if available on system
Message-ID: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>

Hi all, 

Not sure whether something on this subject has been raised before but I 
was unable to see anything in the mailing lists.

We have been looking at adding support to Java to use the OpenSSL 
libraries as a JCE security provider if available on the system that a 
Java application is being run on (or to build and bundle the OpenSSL 
libraries with the JDK).

If not found then the security drops back to using the built in security 
that is part of the existing JDK.

The use of the OpenSSL libraries can be disabled entirely or specific 
algorithms can be disabled by use of command line options, 
i.e. Djdk.nativeCrypto=true | false  and  -Djdk.nativeDigest=true | false

Would this be something that might be useful to be contributed to OpenJDK.

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190315/7a5bda70/attachment.html>

From mbalao at redhat.com  Fri Mar 15 13:34:38 2019
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 15 Mar 2019 10:34:38 -0300
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
Message-ID: <a1a91ee3-71bb-dfdf-7be5-05ba322e8672@redhat.com>

Hi Steve,

This looks interesting.

I have a couple of questions:

1) Is this integrated to the JCE crypto providers framework or does it
work separately? The properties "jdk.nativeCrypto" and
"jdk.nativeDigest" made me think it's not.

2) Which algorithms are under scope?

Kind regards,
Martin.-

From mbalao at redhat.com  Fri Mar 15 13:34:46 2019
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 15 Mar 2019 10:34:46 -0300
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
Message-ID: <0d4ad6ce-d2f0-16c1-13ae-8a8e74315579@redhat.com>

Hi Steve,

This looks interesting.

I have a couple of questions:

1) Is this integrated to the JCE crypto providers framework or does it
work separately? The properties "jdk.nativeCrypto" and
"jdk.nativeDigest" made me think it's not.

2) Which algorithms are under scope?

Kind regards,
Martin.-

From darran.lofthouse at jboss.com  Fri Mar 15 14:26:58 2019
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Fri, 15 Mar 2019 14:26:58 +0000
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
Message-ID: <CAMxVf4OWWbEKUyesZJZeMTS4+rWetK7zc6W-RFw_DkJhxqoZSg@mail.gmail.com>

FYI if anyone is interested in using OpenSSL through a Java security
Provider we have this project available within the WildFly project: -

https://github.com/wildfly/wildfly-openssl

On Fri, Mar 15, 2019 at 9:48 AM Steve Groeger <GROEGES at uk.ibm.com> wrote:

> Hi all,
>
> Not sure whether something on this subject has been raised before but I
> was unable to see anything in the mailing lists.
>
> We have been looking at adding support to Java to use the OpenSSL
> libraries as a JCE security provider if available on the system that a Java
> application is being run on (or to build and bundle the OpenSSL libraries
> with the JDK).
>
> If not found then the security drops back to using the built in security
> that is part of the existing JDK.
>
> The use of the OpenSSL libraries can be disabled entirely or specific
> algorithms can be disabled by use of command line options,
> i.e. Djdk.nativeCrypto=true | false  and  -Djdk.nativeDigest=true | false
>
> Would this be something that might be useful to be contributed to OpenJDK.
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190315/183f7828/attachment.html>

From GROEGES at uk.ibm.com  Fri Mar 15 15:31:05 2019
From: GROEGES at uk.ibm.com (Steve Groeger)
Date: Fri, 15 Mar 2019 15:31:05 +0000
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <a1a91ee3-71bb-dfdf-7be5-05ba322e8672@redhat.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
 <a1a91ee3-71bb-dfdf-7be5-05ba322e8672@redhat.com>
Message-ID: <OF8DB66D39.949C5EEF-ON802583BE.0053EF14-802583BE.00553E40@notes.na.collabserv.com>

Martin, 

> 1) Is this integrated to the JCE crypto providers framework or does it 
work separately?
No, this is not currently integrated into the JCE crypto providers 
framework. 
The implementation we currently have integrates into the existing JCE 
providers and it defaults to using the OpenSSL libraries, if they are 
found and can be used, otherwise it drops back to the existing 
implementation provided with the JDK. As I stated previously the entire 
use of the the OpenSSL library can be enabled / disabled as well as the 
use of specific OpenSSL algorithms using java runtime options.

> 2) Which algorithms are under scope?
The OpenSSL algorithms we have currently done this work for are RSA, CMC, 
GCM and Digest. 

Thanks
Steve Groeger
IBM Runtime Technologies
Hursley, Winchester
Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
Fax (44) 1962 816800
Lotus Notes: Steve Groeger/UK/IBM
Internet: groeges at uk.ibm.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



From:   Martin Balao <mbalao at redhat.com>
To:     security-dev at openjdk.java.net
Date:   15/03/2019 13:35
Subject:        Re: Use of OpenSSL as JCE security provider if available 
on system
Sent by:        "security-dev" <security-dev-bounces at openjdk.java.net>



Hi Steve,

This looks interesting.

I have a couple of questions:

1) Is this integrated to the JCE crypto providers framework or does it
work separately? The properties "jdk.nativeCrypto" and
"jdk.nativeDigest" made me think it's not.

2) Which algorithms are under scope?

Kind regards,
Martin.-




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190315/b988f786/attachment.html>

From simone.bordet at gmail.com  Fri Mar 15 16:37:20 2019
From: simone.bordet at gmail.com (Simone Bordet)
Date: Fri, 15 Mar 2019 17:37:20 +0100
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <CAMxVf4OWWbEKUyesZJZeMTS4+rWetK7zc6W-RFw_DkJhxqoZSg@mail.gmail.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
 <CAMxVf4OWWbEKUyesZJZeMTS4+rWetK7zc6W-RFw_DkJhxqoZSg@mail.gmail.com>
Message-ID: <CAFWmRJ0PT2k=7=J5BiSt1VVtisO7BV2ShXL5ZMDGvLs66Kitqg@mail.gmail.com>

Hi,

On Fri, Mar 15, 2019 at 3:28 PM Darran Lofthouse
<darran.lofthouse at jboss.com> wrote:
> FYI if anyone is interested in using OpenSSL through a Java security Provider we have this project available within the WildFly project: -
>
> https://github.com/wildfly/wildfly-openssl

There is also the effort from Google, Conscrypt:
https://github.com/google/conscrypt

It's a full blown JCE and JSSE implementation based on OpenSSL, so it
can easily be used in this way;

java.security.Security.addProvider(new org.conscrypt.OpenSSLProvider());

To my knowledge, Conscrypt is what's being used in Android and we
optionally use it in Jetty too.

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From norman.maurer at googlemail.com  Fri Mar 15 17:10:14 2019
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Fri, 15 Mar 2019 18:10:14 +0100
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <CAFWmRJ0PT2k=7=J5BiSt1VVtisO7BV2ShXL5ZMDGvLs66Kitqg@mail.gmail.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
 <CAMxVf4OWWbEKUyesZJZeMTS4+rWetK7zc6W-RFw_DkJhxqoZSg@mail.gmail.com>
 <CAFWmRJ0PT2k=7=J5BiSt1VVtisO7BV2ShXL5ZMDGvLs66Kitqg@mail.gmail.com>
Message-ID: <BE2B7AA3-CC30-45DD-8C13-87B07B3F1E6E@googlemail.com>

Actually this is not based on OpenSSL but it uses BoringSSL (which provides an OpenSSL API + some extra stuff), just in case it matters for anyone.

Bye
Norman


> On 15. Mar 2019, at 17:37, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Hi,
> 
> On Fri, Mar 15, 2019 at 3:28 PM Darran Lofthouse
> <darran.lofthouse at jboss.com> wrote:
>> FYI if anyone is interested in using OpenSSL through a Java security Provider we have this project available within the WildFly project: -
>> 
>> https://github.com/wildfly/wildfly-openssl
> 
> There is also the effort from Google, Conscrypt:
> https://github.com/google/conscrypt
> 
> It's a full blown JCE and JSSE implementation based on OpenSSL, so it
> can easily be used in this way;
> 
> java.security.Security.addProvider(new org.conscrypt.OpenSSLProvider());
> 
> To my knowledge, Conscrypt is what's being used in Android and we
> optionally use it in Jetty too.
> 
> -- 
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz


From grajmanu at outlook.com  Fri Mar 15 08:50:41 2019
From: grajmanu at outlook.com (Manu G Raj)
Date: Fri, 15 Mar 2019 08:50:41 +0000
Subject: [SSL Config] Pull certificate from Window's certificate store
Message-ID: <BM1PR0101MB133259E68A11D926096BF1FEE8440@BM1PR0101MB1332.INDPRD01.PROD.OUTLOOK.COM>

Hi,


We were trying to simplify the certificate and SSL configuration during our java app deployment in Windows. As part of this, we were trying to pull certificates from Windows-ROOT or Windows-MY by setting

      System.setProperty("javax.net.ssl.trustStoreType","Windows-ROOT");

       System.setProperty("javax.net.ssl.trustStore", "NUL");

There are several claims that only user certificates are available from Windows-ROOT, local machine certificates are not actually read. We have even encountered https://bugs.openjdk.java.net/browse/JDK-6782021 and its subsequent mails. Would just like to know, if the above properties are set, then will the machine certificates be resolved.

Java version: Java8u201

Regards,
Manu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190315/35519e16/attachment-0001.html>

From shade at redhat.com  Fri Mar 15 10:57:53 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 15 Mar 2019 11:57:53 +0100
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
Message-ID: <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>

On 3/15/19 5:55 AM, Andrew John Hughes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/

Looks good, ship it.

-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190315/eb223d71/signature-0001.asc>

From darran.lofthouse at redhat.com  Fri Mar 15 14:24:43 2019
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Fri, 15 Mar 2019 14:24:43 +0000
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
Message-ID: <CAMxVf4Oux=26_J5odwNzmQQwZ3kgi50MfH2jGxg=yjKTA-EpLw@mail.gmail.com>

FYI if anyone is interested in using OpenSSL through a Java security
Provider we have this project available within the WildFly project: -

https://github.com/wildfly/wildfly-openssl


On Fri, Mar 15, 2019 at 9:48 AM Steve Groeger <GROEGES at uk.ibm.com> wrote:

> Hi all,
>
> Not sure whether something on this subject has been raised before but I
> was unable to see anything in the mailing lists.
>
> We have been looking at adding support to Java to use the OpenSSL
> libraries as a JCE security provider if available on the system that a Java
> application is being run on (or to build and bundle the OpenSSL libraries
> with the JDK).
>
> If not found then the security drops back to using the built in security
> that is part of the existing JDK.
>
> The use of the OpenSSL libraries can be disabled entirely or specific
> algorithms can be disabled by use of command line options,
> i.e. Djdk.nativeCrypto=true | false  and  -Djdk.nativeDigest=true | false
>
> Would this be something that might be useful to be contributed to OpenJDK.
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911  Mobex: 279990  Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190315/581aaebb/attachment-0001.html>

From hohensee at amazon.com  Fri Mar 15 17:58:59 2019
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 15 Mar 2019 17:58:59 +0000
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
 <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>
Message-ID: <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com>

+1

Paul

?On 3/15/19, 4:00 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:

    On 3/15/19 5:55 AM, Andrew John Hughes wrote:
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
    > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
    
    Looks good, ship it.
    
    -Aleksey
    
    


From gnu.andrew at redhat.com  Fri Mar 15 18:58:00 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 15 Mar 2019 18:58:00 +0000
Subject: [RFR] [8u] 8220641, , New test KdcPolicy.java introduced by
 JDK-8164656 needs same change as JDK-8190690
In-Reply-To: <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com>
References: <865c8f6a-a3aa-e5b8-5614-9889e66d4078@redhat.com>
 <6cfb6cd3-c460-2dd5-da2d-8002dc102fad@redhat.com>
 <9390BF16-7FC9-4E1E-BAA4-A6B9E8D0AEF6@amazon.com>
Message-ID: <ce79090a-2f15-1a79-213e-00f2f0e466cb@redhat.com>

On 15/03/2019 17:58, Hohensee, Paul wrote:
> +1
> 
> Paul
> 
> ?On 3/15/19, 4:00 AM, "jdk8u-dev on behalf of Aleksey Shipilev" <jdk8u-dev-bounces at openjdk.java.net on behalf of shade at redhat.com> wrote:
> 
>     On 3/15/19 5:55 AM, Andrew John Hughes wrote:
>     > Bug: https://bugs.openjdk.java.net/browse/JDK-8220641
>     > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220641/webrev.01/
>     
>     Looks good, ship it.
>     
>     -Aleksey
>     
>     
> 

Thanks, guys. Just waiting on aph to set jdk8u-fix-yes on it now.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190315/9aceb56c/signature.asc>

From jamil.j.nimeh at oracle.com  Fri Mar 15 22:05:22 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 15 Mar 2019 15:05:22 -0700
Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )
 ignores the provider argument.
In-Reply-To: <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
 <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com>
Message-ID: <0f658960-4bf8-ba51-93a7-898d9fd3431b@oracle.com>

Hello all,

I've updated the webrev with all of Adam's findings with one exception.? 
I did try bringing the crypto provider code in-line. That approach will 
work for OpenJDK where there is no 3rd party signing requirement, but on 
Oracle JDK it will not and the provider needs to be in the form of a 
signed jar file.? I would like this to run on both JDKs, especially 
since the provider selection codepaths are a bit different between 
Oracle and Open JDKs.? Also the original bug came in against Oracle JDK 
so it would be nice to have the test run there.

http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.02

Thanks,

--Jamil

On 3/14/19 7:53 AM, Adam Petcher wrote:
> The change to PBKDF2KeyImpl.java looks fine. About the test:
>
> *) Is it necessary to put the provider in a separate jar? It seems 
> unnecessary because you are adding it with Security.insertProviderAt.
>
> *) Line 54 of the test compares the result of a constructor to null. 
> Unless I'm missing something, this reference will always be non-null.
>
> *) At the end of the test, there are some methods that do conversion 
> between hex strings and bytes. Can you use the methods in Convert (in 
> the test list) instead? I think Convert.hexStringToByteArray is the 
> same thing as hex2bin. You may also want to move dumpHexBytes to 
> Convert, but it's fine either way.
>
> *) It looks the evilprovider source files have the wrong copyright 
> header.
>
> *) There is a commented out line of code on line 16 of EvilProvider.java
>
> On 3/14/2019 9:34 AM, Jamil Nimeh wrote:
>> Hello all,
>>
>> This review will change the SunJCE implementation of PBKDF2 so that 
>> it always uses the SunJCE version of the PRF algorithm internally.
>>
>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8220531
>>

From mbalao at redhat.com  Sat Mar 16 19:52:09 2019
From: mbalao at redhat.com (Martin Balao)
Date: Sat, 16 Mar 2019 16:52:09 -0300
Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in
 SunPKCS11 crypto provider
Message-ID: <baa81e60-bde8-933e-3195-736c9a3408a2@redhat.com>

Hi,

Can I have a review for JDK-8220753 [1]?

 * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.00/

The test is almost identical to the previous one [2], with a few changes
in the "initialize" function (so it does not depend on the removed
SunJSSE FIPS feature anymore).

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8220753
[2] -
http://hg.openjdk.java.net/jdk/jdk/file/bccd9966f1ed/test/jdk/sun/security/pkcs11/fips/TestTLS12.java

From sha.jiang at oracle.com  Mon Mar 18 12:28:49 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 18 Mar 2019 20:28:49 +0800
Subject: RFR[13] JDK-8220410:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with
 missing expected output
In-Reply-To: <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com>
References: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>
 <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com>
Message-ID: <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com>

Hi Max,
If using "-J-Duser.timezone=null", it looks jarsigner always uses 
timezone GMT-8/PST, but not the local timezone.
Currently, the testing machines should use GMT-7/PDT.
If no user.timezone is specified, jarsigner just uses local timezone.

Please review the updated webrev: 
http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/
It doesn't specify user.timezone for jarsigner if this property is null, 
and still makes sure jarsigner and date formatter use the same timezone.

Best regards,
John Jiang

On 2019/3/14 09:52, Weijun Wang wrote:
>
>> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote:
>>
>> Hi,
>> This fix just makes sure that specified timezone is not null,
> Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop).
>
> BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z.
>
> --Max
>
>> and the jar verifying and date formatting use the same different timezone.
>>
>> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410
>>
>> Best regards,
>> John Jiang
>>
>

From adam.petcher at oracle.com  Mon Mar 18 13:43:19 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Mon, 18 Mar 2019 09:43:19 -0400
Subject: RFR 8218723: SecretKeyFactory.getInstance( algo_, provider_ )
 ignores the provider argument.
In-Reply-To: <0f658960-4bf8-ba51-93a7-898d9fd3431b@oracle.com>
References: <381cb261-5f6c-7da0-1d7c-098fca2083be@oracle.com>
 <2c8228ca-779e-671d-8157-7a13f82d312b@oracle.com>
 <0f658960-4bf8-ba51-93a7-898d9fd3431b@oracle.com>
Message-ID: <70135120-3a26-0a6b-d579-9e535a670ec5@oracle.com>

Hi Jamil,

This looks good to me.

I read through the discussion about running the Mac in hardware, and I 
think it is fine if this is not supported by SunJCE. It doesn't look 
like the current API for Mac fully allows this, and even if it did, it 
would be simpler to stay in SunJCE once that provider is selected. If 
running the PRF in hardware is desired, then the way to accomplish that 
is for all of PBKDF2 to happen in the hardware provider.

On 3/15/2019 6:05 PM, Jamil Nimeh wrote:
> Hello all,
>
> I've updated the webrev with all of Adam's findings with one 
> exception.? I did try bringing the crypto provider code in-line. That 
> approach will work for OpenJDK where there is no 3rd party signing 
> requirement, but on Oracle JDK it will not and the provider needs to 
> be in the form of a signed jar file.? I would like this to run on both 
> JDKs, especially since the provider selection codepaths are a bit 
> different between Oracle and Open JDKs.? Also the original bug came in 
> against Oracle JDK so it would be nice to have the test run there.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.02
>
> Thanks,
>
> --Jamil
>
> On 3/14/19 7:53 AM, Adam Petcher wrote:
>> The change to PBKDF2KeyImpl.java looks fine. About the test:
>>
>> *) Is it necessary to put the provider in a separate jar? It seems 
>> unnecessary because you are adding it with Security.insertProviderAt.
>>
>> *) Line 54 of the test compares the result of a constructor to null. 
>> Unless I'm missing something, this reference will always be non-null.
>>
>> *) At the end of the test, there are some methods that do conversion 
>> between hex strings and bytes. Can you use the methods in Convert (in 
>> the test list) instead? I think Convert.hexStringToByteArray is the 
>> same thing as hex2bin. You may also want to move dumpHexBytes to 
>> Convert, but it's fine either way.
>>
>> *) It looks the evilprovider source files have the wrong copyright 
>> header.
>>
>> *) There is a commented out line of code on line 16 of EvilProvider.java
>>
>> On 3/14/2019 9:34 AM, Jamil Nimeh wrote:
>>> Hello all,
>>>
>>> This review will change the SunJCE implementation of PBKDF2 so that 
>>> it always uses the SunJCE version of the PRF algorithm internally.
>>>
>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8218723/webrev.01/
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8218723
>>>
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8220531
>>>

From weijun.wang at oracle.com  Mon Mar 18 14:04:24 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 18 Mar 2019 22:04:24 +0800
Subject: RFR[13] JDK-8220410:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with
 missing expected output
In-Reply-To: <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com>
References: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>
 <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com>
 <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com>
Message-ID: <08957627-8517-48FC-8F20-E18EF3AD68F7@oracle.com>

Hi John,

The new webrev looks mostly fine, except that I don't like the new lambda in Test.java. But I'll leave it to you to decide if that style is good.

Have you been able to reproduce the original test failure and make sure your updated test passes in the same environment? Otherwise, I cannot be sure if the fix is at the right spot.

Thanks,
Max

> On Mar 18, 2019, at 8:28 PM, sha.jiang at oracle.com wrote:
> 
> Hi Max,
> If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone GMT-8/PST, but not the local timezone.
> Currently, the testing machines should use GMT-7/PDT.
> If no user.timezone is specified, jarsigner just uses local timezone.
> 
> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/
> It doesn't specify user.timezone for jarsigner if this property is null, and still makes sure jarsigner and date formatter use the same timezone.
> 
> Best regards,
> John Jiang
> 
> On 2019/3/14 09:52, Weijun Wang wrote:
>> 
>>> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote:
>>> 
>>> Hi,
>>> This fix just makes sure that specified timezone is not null,
>> Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop).
>> 
>> BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z.
>> 
>> --Max
>> 
>>> and the jar verifying and date formatting use the same different timezone.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410
>>> 
>>> Best regards,
>>> John Jiang
>>> 
>> 


From jamil.j.nimeh at oracle.com  Mon Mar 18 16:26:47 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 18 Mar 2019 09:26:47 -0700
Subject: RFR 8147502: Digest is incorrectly truncated for ECDSA
 signatures...
In-Reply-To: <89a71a98-52a1-dcdb-f4f4-85e1c5c065dd@oracle.com>
References: <89a71a98-52a1-dcdb-f4f4-85e1c5c065dd@oracle.com>
Message-ID: <585a6af3-738a-33d0-cd41-f1181b6afc3e@oracle.com>

Hi Adam, this looks good.? For your test it seems perfectly reasonable 
to make a mock SecureRandom that lets you control the bits since you're 
trying to run a known-answer test for a function that would normally be 
non-deterministic.? Just one really tiny nit, update the copyright on ec.c.

--Jamil

On 3/4/19 11:40 AM, Adam Petcher wrote:
> webrev: https://cr.openjdk.java.net/~apetcher/8147502/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8147502
>
> Please review this fix to a bug that causes ECDSA signatures to be 
> incorrect in some cases. The fix is simple, but testing this issue is 
> difficult because the API doesn't give access to the raw signing 
> operation so we can check it using known answer tests. I got around 
> this difficulty in the regression test by using a modified 
> SecureRandom that supplies specific bits in order to produce the 
> correct nonce. The test is a bit complicated and brittle, so if anyone 
> has any other suggestions on how to do this, please share.
>

From jamil.j.nimeh at oracle.com  Mon Mar 18 16:48:33 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 18 Mar 2019 09:48:33 -0700
Subject: RFR: release note for JDK-8218723
Message-ID: <3fa434cb-6116-f239-87fd-e8727fd5febd@oracle.com>

Hi guys,

Can someone give a quick review for the release note for JDK-8218723 
(the fix for SunJCE PBKDF2 SecretKeyFactories using SunJCE for the 
underlying PRF)?? Should be really quick.? I have it here:

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

Thanks,

--Jamil


From adam.petcher at oracle.com  Mon Mar 18 17:35:45 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Mon, 18 Mar 2019 13:35:45 -0400
Subject: RFR: release note for JDK-8218723
In-Reply-To: <3fa434cb-6116-f239-87fd-e8727fd5febd@oracle.com>
References: <3fa434cb-6116-f239-87fd-e8727fd5febd@oracle.com>
Message-ID: <2eaf48bb-2756-880f-9c4d-75b45de86418@oracle.com>

A couple of comments:

*) I think it would be helpful to also describe the change using API 
terms, so it is more clear to programmers who may not recognize all the 
crypto terminology. Perhaps: "... will now exclusively use the SunJCE 
Mac service for the underlying pseudorandom function (PRF)."

*) It's labeled RN-IssueFixed, but the text describes a change in 
behavior, not an issue. Maybe add a sentence like: "This change fixes an 
issue where..." Or perhaps use RN-Change, if the purpose of the note is 
to describe the change in behavior.

On 3/18/2019 12:48 PM, Jamil Nimeh wrote:
> Hi guys,
>
> Can someone give a quick review for the release note for JDK-8218723 
> (the fix for SunJCE PBKDF2 SecretKeyFactories using SunJCE for the 
> underlying PRF)?? Should be really quick.? I have it here:
>
> https://bugs.openjdk.java.net/browse/JDK-8220791
>
> Thanks,
>
> --Jamil
>

From jamil.j.nimeh at oracle.com  Mon Mar 18 17:49:44 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 18 Mar 2019 10:49:44 -0700
Subject: RFR: release note for JDK-8218723
In-Reply-To: <2eaf48bb-2756-880f-9c4d-75b45de86418@oracle.com>
References: <3fa434cb-6116-f239-87fd-e8727fd5febd@oracle.com>
 <2eaf48bb-2756-880f-9c4d-75b45de86418@oracle.com>
Message-ID: <8c8e9db2-2840-1bc0-5b88-b02aacffa726@oracle.com>

Thanks, I didn't see RN-Change on the guidance page I was looking at for 
the notes.? Underlying this change in behavior is an actual issue (that 
a BC FIPS provider was causing SunJCE's PBKDF SecKeyFac from working due 
to the interaction between the SKF and the underlying Mac from the two 
different providers).? I'll make the text changes you suggest and we'll 
see how it reads.

Thanks for the feedback,

--Jamil

On 3/18/19 10:35 AM, Adam Petcher wrote:
> A couple of comments:
>
> *) I think it would be helpful to also describe the change using API 
> terms, so it is more clear to programmers who may not recognize all 
> the crypto terminology. Perhaps: "... will now exclusively use the 
> SunJCE Mac service for the underlying pseudorandom function (PRF)."
>
> *) It's labeled RN-IssueFixed, but the text describes a change in 
> behavior, not an issue. Maybe add a sentence like: "This change fixes 
> an issue where..." Or perhaps use RN-Change, if the purpose of the 
> note is to describe the change in behavior.
>
> On 3/18/2019 12:48 PM, Jamil Nimeh wrote:
>> Hi guys,
>>
>> Can someone give a quick review for the release note for JDK-8218723 
>> (the fix for SunJCE PBKDF2 SecretKeyFactories using SunJCE for the 
>> underlying PRF)?? Should be really quick.? I have it here:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8220791
>>
>> Thanks,
>>
>> --Jamil
>>

From sha.jiang at oracle.com  Mon Mar 18 23:19:14 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Tue, 19 Mar 2019 07:19:14 +0800
Subject: RFR[13] JDK-8220410:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with
 missing expected output
In-Reply-To: <08957627-8517-48FC-8F20-E18EF3AD68F7@oracle.com>
References: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>
 <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com>
 <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com>
 <08957627-8517-48FC-8F20-E18EF3AD68F7@oracle.com>
Message-ID: <4cdb32c4-bc67-0ef3-4b0a-9d889c1b46eb@oracle.com>

Hi Max,

On 2019/3/18 22:04, Weijun Wang wrote:
> Hi John,
>
> The new webrev looks mostly fine, except that I don't like the new lambda in Test.java. But I'll leave it to you to decide if that style is good.
>
> Have you been able to reproduce the original test failure and make sure your updated test passes in the same environment? Otherwise, I cannot be sure if the fix is at the right spot.

I had reproduced this issue. It only raised at the midnight.
The cause is what I mentioned on "-J-Duser.timezone=null".
The test passed with my fix.

Best regards,
John Jiang

>
> Thanks,
> Max
>
>> On Mar 18, 2019, at 8:28 PM, sha.jiang at oracle.com wrote:
>>
>> Hi Max,
>> If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone GMT-8/PST, but not the local timezone.
>> Currently, the testing machines should use GMT-7/PDT.
>> If no user.timezone is specified, jarsigner just uses local timezone.
>>
>> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/
>> It doesn't specify user.timezone for jarsigner if this property is null, and still makes sure jarsigner and date formatter use the same timezone.
>>
>> Best regards,
>> John Jiang
>>
>> On 2019/3/14 09:52, Weijun Wang wrote:
>>>> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote:
>>>>
>>>> Hi,
>>>> This fix just makes sure that specified timezone is not null,
>>> Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop).
>>>
>>> BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z.
>>>
>>> --Max
>>>
>>>> and the jar verifying and date formatting use the same different timezone.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410
>>>>
>>>> Best regards,
>>>> John Jiang
>>>>
>

From weijun.wang at oracle.com  Tue Mar 19 00:39:34 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 19 Mar 2019 08:39:34 +0800
Subject: RFR[13] JDK-8220410:
 sun/security/tools/jarsigner/warnings/NoTimestampTest.java failed with
 missing expected output
In-Reply-To: <4cdb32c4-bc67-0ef3-4b0a-9d889c1b46eb@oracle.com>
References: <a6febbfe-cb2c-b71e-6b7f-66384ea95aae@oracle.com>
 <455305C7-53EB-4F86-9FA6-B1A7CD2B9D1A@oracle.com>
 <27cc6766-ece5-951b-9a7a-35c016aae7c3@oracle.com>
 <08957627-8517-48FC-8F20-E18EF3AD68F7@oracle.com>
 <4cdb32c4-bc67-0ef3-4b0a-9d889c1b46eb@oracle.com>
Message-ID: <D9AAEAEB-6A1C-4738-BF41-EF0C19D3EAB3@oracle.com>



> On Mar 19, 2019, at 7:19 AM, sha.jiang at oracle.com wrote:
> 
> Hi Max,
> 
> On 2019/3/18 22:04, Weijun Wang wrote:
>> Hi John,
>> 
>> The new webrev looks mostly fine, except that I don't like the new lambda in Test.java. But I'll leave it to you to decide if that style is good.
>> 
>> Have you been able to reproduce the original test failure and make sure your updated test passes in the same environment? Otherwise, I cannot be sure if the fix is at the right spot.
> 
> I had reproduced this issue. It only raised at the midnight.
> The cause is what I mentioned on "-J-Duser.timezone=null".
> The test passed with my fix.

Great!

--Max

> 
> Best regards,
> John Jiang
> 
>> 
>> Thanks,
>> Max
>> 
>>> On Mar 18, 2019, at 8:28 PM, sha.jiang at oracle.com wrote:
>>> 
>>> Hi Max,
>>> If using "-J-Duser.timezone=null", it looks jarsigner always uses timezone GMT-8/PST, but not the local timezone.
>>> Currently, the testing machines should use GMT-7/PDT.
>>> If no user.timezone is specified, jarsigner just uses local timezone.
>>> 
>>> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.01/
>>> It doesn't specify user.timezone for jarsigner if this property is null, and still makes sure jarsigner and date formatter use the same timezone.
>>> 
>>> Best regards,
>>> John Jiang
>>> 
>>> On 2019/3/14 09:52, Weijun Wang wrote:
>>>>> On Mar 13, 2019, at 4:58 PM, sha.jiang at oracle.com wrote:
>>>>> 
>>>>> Hi,
>>>>> This fix just makes sure that specified timezone is not null,
>>>> Or maybe if it's null then shall we also not pass it to the tools? If I understand correctly, by doing this we also test the default timezone case, which I believe is more common. (At least I don't see it in "java -XshowSettings:properties" on my laptop).
>>>> 
>>>> BTW, are you able to reproduce the failure by faking the time? All failures happened from 2019-03-11T07:23:34Z to 2019-03-11T07:32:36Z.
>>>> 
>>>> --Max
>>>> 
>>>>> and the jar verifying and date formatting use the same different timezone.
>>>>> 
>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8220410/webrev.00/
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8220410
>>>>> 
>>>>> Best regards,
>>>>> John Jiang
>>>>> 
>> 


From xuelei.fan at oracle.com  Tue Mar 19 15:51:58 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 19 Mar 2019 08:51:58 -0700
Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in
 SunPKCS11 crypto provider
In-Reply-To: <baa81e60-bde8-933e-3195-736c9a3408a2@redhat.com>
References: <baa81e60-bde8-933e-3195-736c9a3408a2@redhat.com>
Message-ID: <f84d61a0-ce13-afa9-548e-6113cd906c3e@oracle.com>

Hi Martin,

In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS" 
should be disabled in the test case?  It may help for further update if 
RSASSA-PSS get supported in the SunPKCS11 provider in the future.

Otherwise, looks fine to me.

Thanks,
Xuelei

On 3/16/2019 12:52 PM, Martin Balao wrote:
> Hi,
> 
> Can I have a review for JDK-8220753 [1]?
> 
>   * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.00/
> 
> The test is almost identical to the previous one [2], with a few changes
> in the "initialize" function (so it does not depend on the removed
> SunJSSE FIPS feature anymore).
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8220753
> [2] -
> http://hg.openjdk.java.net/jdk/jdk/file/bccd9966f1ed/test/jdk/sun/security/pkcs11/fips/TestTLS12.java
> 

From adam.petcher at oracle.com  Tue Mar 19 19:22:15 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Tue, 19 Mar 2019 15:22:15 -0400
Subject: RFR 8147502: Digest is incorrectly truncated for ECDSA
 signatures...
In-Reply-To: <585a6af3-738a-33d0-cd41-f1181b6afc3e@oracle.com>
References: <89a71a98-52a1-dcdb-f4f4-85e1c5c065dd@oracle.com>
 <585a6af3-738a-33d0-cd41-f1181b6afc3e@oracle.com>
Message-ID: <15db61b6-c1b4-1cfd-937a-946b6bc1318f@oracle.com>

Thanks! I updated the copyright in the push.

On 3/18/2019 12:26 PM, Jamil Nimeh wrote:
> Hi Adam, this looks good.? For your test it seems perfectly reasonable 
> to make a mock SecureRandom that lets you control the bits since 
> you're trying to run a known-answer test for a function that would 
> normally be non-deterministic.? Just one really tiny nit, update the 
> copyright on ec.c.
>
> --Jamil
>
> On 3/4/19 11:40 AM, Adam Petcher wrote:
>> webrev: https://cr.openjdk.java.net/~apetcher/8147502/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8147502
>>
>> Please review this fix to a bug that causes ECDSA signatures to be 
>> incorrect in some cases. The fix is simple, but testing this issue is 
>> difficult because the API doesn't give access to the raw signing 
>> operation so we can check it using known answer tests. I got around 
>> this difficulty in the regression test by using a modified 
>> SecureRandom that supplies specific bits in order to produce the 
>> correct nonce. The test is a bit complicated and brittle, so if 
>> anyone has any other suggestions on how to do this, please share.
>>

From valerie.peng at oracle.com  Tue Mar 19 22:17:14 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 19 Mar 2019 15:17:14 -0700
Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in
 SunPKCS11 crypto provider
In-Reply-To: <a03d6a49-5811-faad-e6ba-0e6c668d614a@redhat.com>
References: <a03d6a49-5811-faad-e6ba-0e6c668d614a@redhat.com>
Message-ID: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com>


How about another potential problem - wrapper key may never get deleted?
If we don't have a good solution to addressing it, at least add a 
comment about it?
Rest looks fine.

Thanks,

Valerie


On 3/12/2019 3:34 PM, Martin Balao wrote:
> Hi,
>
> I'd like to propose a fix for JDK-8220513 [1]:
>
>   * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.00/
>
> Testing:
>
>   * No regressions found in sun/security/pkcs11
>
>   * This bug was exposed by TestTLS12 test, in jdk11u [2]. I'm working in
> re-introducing this test to JDK (after JDK-8217835 deleted it). An issue
> [4] has to be worked out first though. I'll followup on this.
>
> Thanks,
> Martin.-
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8220513
> [2] -
> http://hg.openjdk.java.net/jdk-updates/jdk11u/file/d17a1764a0f3/test/jdk/sun/security/pkcs11/fips/TestTLS12.java
> [3] - https://bugs.openjdk.java.net/browse/JDK-8217835
> [4] -
> https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html

From weijun.wang at oracle.com  Wed Mar 20 02:20:28 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 20 Mar 2019 10:20:28 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190215214502.GB4046@twosigma.com>
References: <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>
 <B696ED17-9B7D-4ED4-BA7F-FAB49E455E89@oracle.com>
 <20181204203436.GA22527@twosigma.com>
 <EA6A3F91-8001-4317-8513-6EDE65EC6E79@oracle.com>
 <20181206184824.GB22527@twosigma.com>
 <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com>
 <20181212004054.GG22527@twosigma.com>
 <D265F857-2EE9-43B0-9259-CCB9F1C83028@oracle.com>
 <20190117190436.GD27060@twosigma.com>
 <EF109C45-C842-47B5-B14E-4A76DF6826D0@oracle.com>
 <20190215214502.GB4046@twosigma.com>
Message-ID: <D1C4A9D2-CF70-4B60-9AA5-1AD3A763F9BC@oracle.com>

New webrev at https://cr.openjdk.java.net/~weijun/6722928/webrev.05, and interdiff at

   https://cr.openjdk.java.net/~weijun/6722928/webrev.05/interdiff.patch.html

I'll think more about secondsUntil() and getTGTEndTime(). Other comments below.

> - sspi.cpp:61
> 
>   61 #define SEC_SUCCESS(status) (*minor_status = status, (status) >= SEC_E_OK)
>                                   ^^^^^^^^^^^^^^^^^^^^^^
> 
>   Please add parenthesis around the whole assignment expression.

OK, but what kind of bad things could happen?

> 
> - sspi.cpp:129
> 
>   129 static long
>   130 secondsUntil(int inputIsUTC, TimeStamp *time)
> 
>   There's no need to return a signed number, and you assign it to OM_uint32
>   variables anyways, and we don't care if some credential expired in the past.
> 
>   So just make this return an unsigned integral type, preferably just
>   OM_uint32.
> 
>   So just rewrite as:
> 
>    static OM_uint32
>    secondsUntil(int inputIsUTC, TimeStamp *time)
>    {
>        // time is local time
>        ULARGE_INTEGER uiLocal;
>        FILETIME now;
>        GetSystemTimeAsFileTime(&now);
>        if (!inputIsUTC) {
>            FILETIME nowLocal;
>            if (FileTimeToLocalFileTime(&now, &nowLocal) == 0) {
>                return -1;
>            }
>            now = nowLocal;
>        }
>        uiLocal.HighPart = now.dwHighDateTime;
>        uiLocal.LowPart = now.dwLowDateTime;
>        long diff = (long)((time->QuadPart - uiLocal.QuadPart) / 10000000);
>        if (diff < 0)
>            return 0;
>        if (sizeof(long) > sizeof(OM_uint32) && diff > (long)~(OM_uint32)0)
>            return GSS_C_INDEFINITE;
>        return diff;
>    }

OK.

> 
> - sspi.cpp:NewContext()
> 
>   Please fully-initialize all fields of the allocated context structure before
>   returning it.

Some of them are of struct types, do I need to go inside and set each to zero? Or ZeroMemory the whole struct?

For example:

typedef struct _SecHandle {

  ULONG_PTR       dwLower;
  ULONG_PTR       dwUpper;
} SecHandle, * PSecHandle;


> 
>   Or else use new gss_ctx_id_struct() syntax, or specify a constructor.
> 
> - sspi.cpp:169
> 
>   -->165     out->phCred = NULL;
>      166     out->cbMaxMessage = pkgInfo->cbMaxToken;
>      167     PP("pkgInfo->cbMaxToken: %ld", pkgInfo->cbMaxToken);
>      168     FreeContextBuffer(pkgInfo);
>   -->169     out->phCred = NULL;
> 
>   Dup code.

Ah yes.

> 
> - sspi.cpp:flagSspi2Gss() and flagGss2Sspi()
> 
>   I realize that this would be a change to the Java bindings, so this is just
>   a note, but, we should add support for GSS_C_DELEG_POLICY_FLAG.

How? Always set it with GSS_C_DELEG_FLAG?

> 
> - sspi.cpp:getTGTEndTime()
> 
>   Please immediately write to the `endTime' output parameter upon entry.

Are you afraid of garbages for "return 1"s? But I won't touch the parameter at all in this case.

> 
> - sspi.cpp:getTGTEndTime()
> 
>   You leak the logonHandle.  You have to close it with
>   LsaDeregisterLogonProcess() before returning after LsaConnectUntrusted()
>   returns successfully.

OK.

> 
> - sspi.cpp:getTGTEndTime()
> 
>   Maybe just make this return OM_uint32 and simplify the one call site, making
>   it return 86400 seconds (1 day) or whatever for the error case, else the
>   secondsUntil() the time indicated by the LSA in response to the
>   KerbRetrieveTicketMessage request.

I'll think about it.

> 
> - sspi.cpp:316,355
> 
>   It is rather concerning that get_full_name() can return its input or a
>   modified copy of its input.  At the call sites there's no check to see if
>   the returned value is allocated, and it's hard to analyze if you're
>   ultimately leaking or double-freeing.
> 
>   This isn't performance-critical code, so just always allocate a copy.

OK.

> 
> - sspi.cpp:315
> 
>   314     // input has realm, no need to add one
>   315     if (wcschr(input, '@')) {
> 
>   This is not going to work with UPNs.  

Why not? I just want to find out if there is already a realm.

> You should probably implement proper
>   RFC1864 name format support, including backslash-quoting.

Ahh...

> 
> - sspi.cpp:315
> 
>   315     if (wcschr(input, '@')) {
>                             ^
> 
>   I don't know if it is necessary that this be L'@' or if the compiler will do
>   the right thing because the `wc' argument of `wcschr()' is a `wchar_t'.
> 
>   Elsewhere you do use wide character literals, so I assume even if type
>   promotion works correctly for char->WCHAR (does it?) you might want to be
>   consistent.

I'll made them all L'@'.

> 
> - sspi.cpp:328
> 
>   328         // Solution #2: Or just use an empty string (and hope referral works).
>   329         // This does not work now because ServicePermission check is based on
>   330         // the exported name. Unless we update ServicePermission check to
>   331         // be friendly with referral we need a realm.
>   332         //realm = L"";
> 
>   Yes, ServicePermission is a bit of a disaster.  I hope after we integrate
>   our contribution we can clean it up somewhat.
> 
> - sspi.cpp:337
> 
>   337         realm = _wgetenv(L"USERDNSDOMAIN");
> 
>   This is actually probably the best thing to do.  Referrals should get chased
>   from there.
> 
>   Or we could get the realm from the user's principal name and use that.
> 
> - sspi.cpp:344
> 
>   There's no wide string version of strdup()??  Ugh.

There is _wcsdup() but I need to make it longer here.

> 
>   wchar_t/WCHAR is cancer.
> 
>   I worry that adding any more wchar_t-using code makes worse the legacy
>   cleanup as Windows starts to prefer UTF-8.  But whatever.
> 
> - sspi.cpp:351
> 
>   351     wcscpy_s(fullname + oldlen + 1, wcslen(realm) + 1, realm);
> 
>   It would be safer to use wcscat_s().

How is this unsafe? If using wcscat_s(), I'll need to add a '\0' after the '@' first.

> 
> - sspi.cpp:362
> 
>   362 #define CHECK_OUTPUT(x)  if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE;
> 
>   I would much prefer the more standard and safer do { ... } while (0)
>   construction:
> 
>    362 #define CHECK_OUTPUT(x)  \
>        do { if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE; } while (0)

I can do that, but why is this safer?

> 
>   I would do this for all your macros.
> 
>   I'm also not sure it's worth having these macros.

You mean there is actually no need to check the arguments?

> 
> - sspi.cpp:398-405
> 
>   I don't believe there's an exported name token format for SPNEGO MNs.  In
>   principle any MNs produced by SPNEGO should be for the negotiated mechanism.
>   What you should do here instead is check that the exported name token is for
>   Kerberos, and if not return an error immediately.

OK.

> 
>   And your gss_export_name() correctly always puts the Kerberos mechanism OID
>   in exported name tokens.
> 
> - sspi.cpp:412
> 
>   412     len = MultiByteToWideChar(CP_ACP, 0, input, len, value, len+1);
>                                     ^^^^^^
> 
>   Please use CP_UTF8 when en-widening the string in an exported Kerberos name
>   token.

OK.

> 
> - sspi.cpp:465
> 
>   465     // Initialized as different
>   466     *name_equal = 0;
> 
>   No need to comment the obvious :)

Oh.

> 
> - sspi.cpp:gss_compare_name()
> 
>   Just a note: your `struct gss_name_struct' doesn't keep track of import name
>   type, so you can't check that here.  That's OK.  It's not worth trying to
>   keep track of it -- I'm just pointing this out.
> 
> - sspi.cpp:527
> 
>   527     int len = (int)wcslen(fullname);
> 
>   You don't need that cast.  

There was a warning.

> But you should check first that `wcslen()' did
>   not return a value larger than `INT_MAX'.
> 
>   You only even need an `int len' because `WideCharToMultiByte()' returns
>   `int'...
> 
>   I'd write this like:
> 
>    527     int len;
>            size_t namelen = wcslen(fullname);
>            if (namelen > 255)
>                goto err;
>            // 04 01 00 ** 06 ** OID len:int32 name
>            // ...
>            //
> 
> - sspi.cpp:545
> 
>   545         len = WideCharToMultiByte(CP_ACP, 0, fullname, len,
>                                         ^^^^^^
> 
>   s/CP_ACP/CP_UTF8/
> 
>   It's clear that the intent of RFC2743 was to have name strings be in some
>   standard encoding, not the locale's, though RFC2743 says "Latin-1", which
>   isn't precise enough, and useless anyways.  Otherwise, if we needed to use
>   the codepage being used by the application we'd have to first determine what
>   that is.  The application here is Java, which will be using UTF-8 anyways,
>   no? so just do that.  Definitely not ANSI.
> 
> - sspi.cpp:532,574
> 
>   You can't assume the length of a multi-byte string will be the same number
>   of `char' as the number of `wchar_t' in the wide-char version of the string.
> 
>   Determinining the correct length is a bit tricky, though since we should be
>   converting to UTF-8 (see above), you can assume that 4x is enough, use
>   4*len for the buffer allocation, then take the correct length from
>   WideCharToMultiByte().

OK.

> 
> - sspi.cpp:630-644
> 
>   This should be done after successfully acquiring a credential.  Before that,
>   if actual_mechs != NULL then set *actual_mechs = GSS_C_NO_OID_SET.

OK.

> 
> - sspi.cpp:gss_acquire_cred()
> 
>   It would be good to set *minor_status in more cases.
> 
> - sspi.cpp:607
> 
>   606     TimeStamp ts;
>   607     ts.QuadPart = 0;
> 
>   Huh?  TimeStamp is a typedef of SECURITY_INTEGER, and SECURITY_INTEGER is a
>   struct of the same shape and size as FILETIME, and has no QuadPart field.
> 
>   What am I missing?

It compiles. I think it's a union of one Quad or two DWORD.

> 
> - sspi.cpp:651
> 
>   651     ts.QuadPart = 0;
> 
>   You've already initialized this at 607.

Oops.

> 
> - sspi.cpp:704-711
> 
>   As mentioned above, you could move this all into a utility function.  And
>   there's no need to support anything other than unsigned expiration times.
>   GSS only uses OM_uint32 for those.  If a credential is expired you'll get
>   GSS_S_NO_CRED, not a negative expiration time.  (You might get
>   GSS_S_COMPLETE and a zero lifetime_rec, but that would be a race condition.)

See above.

> 
> - sspi.cpp:767
> 
>   I would prefer that all output parameters be initialized early (to zero,
>   GSS_C_NO_NAME, etc.) before any work is done that might cause failure.

OK.

> 
> - sspi.cpp:813
> 
>   I would prefer that *minor_status is always set to something, even zero.
> 
>   Meaningful minor status values would be nice, but that can come later.

OK.

> 
> - sspi.cpp:871
> 
>   s/CP_ACP/CP_UTF8/

OK.

> 
> - sspi.cpp:870-872
> 
>   Check errors here:
> 
>   870     gss_display_name(&minor, target_name, &tn, NULL);
> 
>   Wrong buffer length here:
> 
>   871     int len = MultiByteToWideChar(CP_ACP, 0, (LPCCH)tn.value, (int)tn.length,
>   872             outName, (int)tn.length);
>                            ^^^^^^^^^^^^^^
> 
>   Replace that with with `sizeof(outName) - 1' please (the `- 1' is
>   important).

Yes.

> 
>   873     if (len == 0) {
>   874         return GSS_S_FAILURE;
>   875     }
> 
> - sspi.cpp:897-898
> 
>   897     } else {
>   898         if (!pc->phCred) {
>   ...
>   932         }
>   933     }
> 
>   You can de-indent all of of 899-931 by re-writing as:
> 
>   897     } else if (!pc->phCred) {
>   ...
>   931     }

Good.

> 
> - sspi.cpp:844
> 
>   844     if (input_token->length == 0) {
> 
>   Technically-speaking input_token can be NULL here.  Maybe the Java JNI
>   bindings for GSS always pass in a token?  But I'd still change this to
>   `input_token == NULL || input_token->length == 0'.
> 
>   Similarly at 889.  And 936.  ...

Yes.

> 
> - sspi.cpp:596
> 
>   596                  const gss_OID_set desired_mech,
> 
>   Nit: since it's an OID set, the name for this argument is `desired_mechs'.

OK.

> 
> - sspi.cpp:841
> 
>   841     BOOLEAN isSPNEGO = isSameOID(mech_type, &SPNEGO_OID);
> 
>   Watch out!  mech_type can be GSS_C_NO_OID (NULL)!
> 
>   isSameOid() will dereference that.
> 
>   If the Java JNI bindings for GSS just happen to always pass in a mech_type,
>   that's OK, but I think you should not assume this and be safe.

I'll fix isSameOID().

> 
> - sspi.cpp:954
> 
>   Should you check if there's an output token before doing this:
> 
>   954         ss = CompleteAuthToken(&pc->hCtxt, &outBuffDesc);
> 
>   ?

Does this matter? Do you think CompleteAuthToken cannot deal with no token?

> 
> - sspi.cpp:874 and others
> 
>   delete `output_token->value' and set it to NULL (and the length to 0) before
>   returning errors after 865.

OK. Is this just a good habit or do you know someone using it even at a failure?

> 
> - sspi.cpp:878,962-963
> 
>   The local variable `pfDone' is set but not used.  Drop it.

OK,

> 
>   (The compiler should have warned about this, no?)

No.

> 
> - sspi.cpp:964-966
> 
>   Change this:
> 
>   964     outFlag = flagSspi2Gss(outFlag);
>   965 
>   966     *ret_flags = (OM_uint32)outFlag;
> 
>   to:
> 
>   964     *ret_flags = flagSspi2Gss(outFlag);
> 
>   You don't use outFlag again.  Setting it to a different kind of set of flags
>   seems like a trap for someone to fall into in the future.

Good.

> 
> - sspi.cpp:948
> 
>   948     if (!SEC_SUCCESS(ss)) {
>   949         return GSS_S_FAILURE;
>   950     }
>   951 
>   952     if ((SEC_I_COMPLETE_NEEDED == ss)
>   953             || (SEC_I_COMPLETE_AND_CONTINUE == ss)) {
> 
>   I can't find documentation on SEC_SUCCES().  I don't know if it treats
>   SEC_I_COMPLETE_NEEDED as an error or not...  I gues it must not.  Can you
>   confirm?

Not an error. I defined SEC_SUCCESS in this file.

> 
> - sspi.cpp:967-970
> 
>   Does QueryContextAttributes() initialize its output parameter if it fails:
> 
>   967     // Ignore the result of the next call. Might fail before context established.
>   968     QueryContextAttributes(
>   969             &pc->hCtxt, SECPKG_ATTR_SIZES, &pc->SecPkgContextSizes);
> 
>   ?
> 
>   If not then you'll print garbage at 970:
> 
>   970     PP("cbMaxToken: %ld. cbMaxSignature: %ld. cbBlockSize: %ld. cbSecurityTrailer: %ld",
>   971             pc->SecPkgContextSizes.cbMaxToken,
>   972             pc->SecPkgContextSizes.cbMaxSignature,
>   973             pc->SecPkgContextSizes.cbBlockSize,
>   974             pc->SecPkgContextSizes.cbSecurityTrailer);
> 
>   Though if you properly initialize the context, then these should all be
>   zeroes.
> 
>   Similarly at 979 and 980.

I see. Now I initialize them at newContext().

> 
> - sspi.cpp:979-983
> 
>   Move 980:
> 
>       979         ss = QueryContextAttributes(&pc->hCtxt, SECPKG_ATTR_NATIVE_NAMES, &pc->nnames);
>   --->980         PP("Names. %ls %ls", pc->nnames.sClientName, pc->nnames.sServerName);
>       981         if (!SEC_SUCCESS(ss)) {
>       982             return GSS_S_FAILURE;
>       983         }
> 
>   to after the SEC_SUCCESS():
> 
>   979         ss = QueryContextAttributes(&pc->hCtxt, SECPKG_ATTR_NATIVE_NAMES, &pc->nnames);
>   980         if (!SEC_SUCCESS(ss)) {
>   981             return GSS_S_FAILURE;
>   982         }
>   983         PP("Names. %ls %ls", pc->nnames.sClientName, pc->nnames.sServerName);

OK.

> 
> - sspi.cpp:1067
> 
>   Since you don't initialize output parameters early in this function, you
>   might goto err and delete garbage:
> 
>   1067 err:
>   1068     if (n1 != NULL) {
>   1069         if (n1->name != NULL) {
>   1070             delete[] n1->name;
>   1071         }
>   1072         delete n1;
>   1073         n1 = NULL;
>   1074     }
>   1075     if (n2 != NULL) {
>   1076         if (n2->name != NULL) {
> 
>   Just initialize all output parameters early.

Yes.

> 
> - sspi.cpp:1002
> 
>   It should be simple now to implement this...
> 
>   1002     PP(">>>> Calling UNIMPLEMENTED gss_accept_sec_context...");
>   1003     return GSS_S_FAILURE;

Not our goal this time, and I don't know how to test. Does server on Windows only run as services?

> 
> - gssapi.h:gss_acquire_cred()
> 
>        @@ -387,13 +399,13 @@
> 
>         /* Function Prototypes */
> 
>         GSS_DLLIMP OM_uint32 gss_acquire_cred(
>                 OM_uint32 *,            /* minor_status */
>        -        gss_name_t,             /* desired_name */
>        +        gss_const_name_t,       /* desired_name */
>                 OM_uint32,              /* time_req */
>        -        gss_OID_set,            /* desired_mechs */
>   ---->+        const gss_OID_set,      /* desired_mechs */
>                 gss_cred_usage_t,       /* cred_usage */
>                 gss_cred_id_t *,        /* output_cred_handle */
>                 gss_OID_set *,          /* actual_mechs */
>                 OM_uint32 *             /* time_rec */
>         );
> 
>   That needs to be `gss_const_OID_set', not `const gss_OID_set'.
> 
>   There's a number of these.  Just search for "const gss_" -- any time you see
>   that in a function prototype, it's wrong.

I think I copied all of them from Heimdal. Do you mean Heimdal is not complete at using the types?

Same below.

Thanks,
Max

> 
> - gssapi.h:gss_init_sec_context()
> 
>        @@ -403,100 +415,100 @@
>                 gss_cred_id_t *         /* cred_handle */
>         );
> 
>         GSS_DLLIMP OM_uint32 gss_init_sec_context(
>                 OM_uint32 *,            /* minor_status */
>        -        gss_cred_id_t,          /* claimant_cred_handle */
>        +        gss_const_cred_id_t,    /* claimant_cred_handle */
>                 gss_ctx_id_t *,         /* context_handle */
>        -        gss_name_t,             /* target_name */
>        -        gss_OID,                /* mech_type (used to be const) */
>        +        gss_const_name_t,       /* target_name */
>   ---->+        const gss_OID,          /* mech_type (used to be const) */
>                 OM_uint32,              /* req_flags */
>                 OM_uint32,              /* time_req */
>        -        gss_channel_bindings_t, /* input_chan_bindings */
>        -        gss_buffer_t,           /* input_token */
>   ---->+        const gss_channel_bindings_t, /* input_chan_bindings */
>   ---->+        const gss_buffer_t,           /* input_token */
>                 gss_OID *,              /* actual_mech_type */
>                 gss_buffer_t,           /* output_token */
>                 OM_uint32 *,            /* ret_flags */
>                 OM_uint32 *             /* time_rec */
>         );
> 
>   These too need to be the correct gss_const_* types.
> 
>   I won't list all of these...
> 
> - NativeFunc.h
> 
>   Same issues here.  E.g.,
> 
>        @@ -55,42 +55,42 @@
>                                         (OM_uint32 *minor_status,
>                                         gss_name_t *name);
> 
>         typedef OM_uint32 (*IMPORT_NAME_FN_PTR)
>                                         (OM_uint32 *minor_status,
>        -                                gss_buffer_t input_name_buffer,
>        -                                gss_OID input_name_type,
>   ---->+                                const gss_buffer_t input_name_buffer,
>   ---->+                                const gss_OID input_name_type,
>                                         gss_name_t *output_name);
> 
>   Though you got many right too:
> 
>         typedef OM_uint32 (*COMPARE_NAME_FN_PTR)
>                                         (OM_uint32 *minor_status,
>        -                                gss_name_t name1,
>        -                                gss_name_t name2,
>        +                                gss_const_name_t name1,
>        +                                gss_const_name_t name2,
>                                         int *name_equal);
> 
> Done.
> 
> This looks much better.  Just a bit more work!
> 
> Nico
> -- 


From xuelei.fan at oracle.com  Wed Mar 20 03:47:04 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 19 Mar 2019 20:47:04 -0700
Subject: CSR Review Request, JDK-8163326, The default enabled cipher
 suites should prefer forward secrecy
In-Reply-To: <DB7PR08MB3307B541FB88E30ECEA81792FF730@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com>
 <ad81eda1-e411-cd8f-0c0d-eab7efa8a1d4@oracle.com>
 <DB7PR08MB3307B541FB88E30ECEA81792FF730@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <db6ff710-9a9f-a887-c81f-80dbcfb548c2@oracle.com>

Hi,

I extended this CSR to cover more update, and update per the comments. 
Please let me know your concerns by the end of March 21, 2019.

Thanks,
Xuelei

On 3/6/2019 3:41 PM, Bernd Eckenfels wrote:
> I am not clear on what would ?preferred in current default context? 
> mean. Does that mean it preferred the PFS ciphers anyway.. for suggested 
> order in client handshake? as server? And what would be the non-Default 
> context. Is this ?TLS? context?
> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* security-dev <security-dev-bounces at openjdk.java.net> im Auftrag 
> von Sean Mullan <sean.mullan at oracle.com>
> *Gesendet:* Mittwoch, M?rz 6, 2019 9:12 PM
> *An:* security-dev at openjdk.java.net
> *Betreff:* Re: CSR Review Request, JDK-8163326, The default enabled 
> cipher suites should prefer forward secrecy
> Hi Xuelei,
> 
> In the Specification section, I think it would be useful to note which
> cipher suites are forward secret and which are not. Otherwise, it is
> difficult to see what has changed, since there are so many supported
> suites. Perhaps in parentheses, ex:
> 
> TLS_AES_128_GCM_SHA256 (forward secret)
> ...
> 
> I also think you should summarize what has changed or what is roughly
> the new order, for example:
> 
> - The TLS_RSA suites have moved down ...
> - The TLS_ECDH suites have moved
> - The SSL_RSA suites have moved down ...
> etc...
> 
> --Sean
> 
> On 2/21/19 4:45 PM, Xuelei Fan wrote:
>  > Hi,
>  >
>  > Could I get the CSR reviewed?
>  > ??? https://bugs.openjdk.java.net/browse/JDK-8219545
>  >
>  > It is proposed to increase the priority of forward secrecy cipher
>  > suites, and decrease the priority of RSA key exchange based cipher
>  > suites for the default enabled cipher suites in the SunJSSE provider.
>  >
>  > Thanks,
>  > Xuelei

From ecki at zusammenkunft.net  Wed Mar 20 07:34:22 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 20 Mar 2019 07:34:22 +0000
Subject: CSR Review Request, JDK-8163326, The default enabled cipher
 suites should prefer forward secrecy
In-Reply-To: <db6ff710-9a9f-a887-c81f-80dbcfb548c2@oracle.com>
References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com>
 <ad81eda1-e411-cd8f-0c0d-eab7efa8a1d4@oracle.com>
 <DB7PR08MB3307B541FB88E30ECEA81792FF730@DB7PR08MB3307.eurprd08.prod.outlook.com>,
 <db6ff710-9a9f-a887-c81f-80dbcfb548c2@oracle.com>
Message-ID: <DB7PR08MB33076D7927B8EA0F59B7A862FF410@DB7PR08MB3307.eurprd08.prod.outlook.com>

Good to understand now.

Do you want to add a sentence how devs&ops can change the order (I.e. enabling the ciphers in a different order?)

Just to be clear, In the Risk Evaluation the ?should have been used? does mean JDK should have done this before, it does not mean it has used the preference before, right? (Although in practice I guess especially DHE have been prefered over RSA by peers often)

The main risk of the change to me seems to be: priotizing DHE over plain DSS/RSA. As this increases the likelyhood for DHE related interop problems (due to lack of negotiation of ?group? sizes).

I suspect two aspects reduce the risk, but maybe it should be mentioned explicitely:

?Preference of DHE_RSA over RSA could increase group/size related interoperability problems. However it is expected that this is mitigated by the additional DHE parameters (FFDHE) in group announcement and also the fact that existing implementations have been confronted with bigger DHE keys for some time now. Besides many existing servers prefer ECDHE or would have picked DHE over RSA anyway.?

I would expect no performance impact as most modern/perfcritical systems would use ECDHE already (and the perf impact of preferring GCM over CBC is a different discussion)


Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: security-dev <security-dev-bounces at openjdk.java.net> im Auftrag von Xuelei Fan <xuelei.fan at oracle.com>
Gesendet: Mittwoch, M?rz 20, 2019 6:19 AM
An: security-dev at openjdk.java.net
Betreff: Re: CSR Review Request, JDK-8163326, The default enabled cipher suites should prefer forward secrecy

Hi,

I extended this CSR to cover more update, and update per the comments.
Please let me know your concerns by the end of March 21, 2019.

Thanks,
Xuelei

On 3/6/2019 3:41 PM, Bernd Eckenfels wrote:
> I am not clear on what would ?preferred in current default context?
> mean. Does that mean it preferred the PFS ciphers anyway.. for suggested
> order in client handshake? as server? And what would be the non-Default
> context. Is this ?TLS? context?
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* security-dev <security-dev-bounces at openjdk.java.net> im Auftrag
> von Sean Mullan <sean.mullan at oracle.com>
> *Gesendet:* Mittwoch, M?rz 6, 2019 9:12 PM
> *An:* security-dev at openjdk.java.net
> *Betreff:* Re: CSR Review Request, JDK-8163326, The default enabled
> cipher suites should prefer forward secrecy
> Hi Xuelei,
>
> In the Specification section, I think it would be useful to note which
> cipher suites are forward secret and which are not. Otherwise, it is
> difficult to see what has changed, since there are so many supported
> suites. Perhaps in parentheses, ex:
>
> TLS_AES_128_GCM_SHA256 (forward secret)
> ...
>
> I also think you should summarize what has changed or what is roughly
> the new order, for example:
>
> - The TLS_RSA suites have moved down ...
> - The TLS_ECDH suites have moved
> - The SSL_RSA suites have moved down ...
> etc...
>
> --Sean
>
> On 2/21/19 4:45 PM, Xuelei Fan wrote:
> > Hi,
> >
> > Could I get the CSR reviewed?
> >     https://bugs.openjdk.java.net/browse/JDK-8219545
> >
> > It is proposed to increase the priority of forward secrecy cipher
> > suites, and decrease the priority of RSA key exchange based cipher
> > suites for the default enabled cipher suites in the SunJSSE provider.
> >
> > Thanks,
> > Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190320/78dbce4e/attachment.html>

From xuelei.fan at oracle.com  Wed Mar 20 15:38:03 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 20 Mar 2019 08:38:03 -0700
Subject: CSR Review Request, JDK-8163326, The default enabled cipher
 suites should prefer forward secrecy
In-Reply-To: <DB7PR08MB33076D7927B8EA0F59B7A862FF410@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com>
 <ad81eda1-e411-cd8f-0c0d-eab7efa8a1d4@oracle.com>
 <DB7PR08MB3307B541FB88E30ECEA81792FF730@DB7PR08MB3307.eurprd08.prod.outlook.com>
 <db6ff710-9a9f-a887-c81f-80dbcfb548c2@oracle.com>
 <DB7PR08MB33076D7927B8EA0F59B7A862FF410@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <b9190fb9-db04-61a2-76d0-5c89c8334010@oracle.com>

H Bernd,

Thank you for the quick review.  All good points!

On 3/20/2019 12:34 AM, Bernd Eckenfels wrote:
> Good to understand now.
> 
> Do you want to add a sentence how devs&ops can change the order (I.e. 
> enabling the ciphers in a different order?)
> 
In the JSSE Reference Guide, there are sections talking about cipher 
suite preference.  I will add a note in the release-note about how to 
customize the preference.

> Just to be clear, In the Risk Evaluation the ?should have been used? 
> does mean JDK should have done this before, it does not mean it has used 
> the preference before, right? (Although in practice I guess especially 
> DHE have been prefered over RSA by peers often)
> 
Right.

> The main risk of the change to me seems to be: priotizing DHE over plain 
> DSS/RSA. As this increases the likelyhood for DHE related interop 
> problems (due to lack of negotiation of ?group? sizes).
> 
> I suspect two aspects reduce the risk, but maybe it should be mentioned 
> explicitely:
> 
> ?Preference of DHE_RSA over RSA could increase group/size related 
> interoperability problems. However it is expected that this is mitigated 
> by the additional DHE parameters (FFDHE) in group announcement and also 
> the fact that existing implementations have been confronted with bigger 
> DHE keys for some time now. Besides many existing servers prefer ECDHE 
> or would have picked DHE over RSA anyway.?
> 
It makes sense to me. I added to the "Compatibility Risk Description" field.

Considering the existing DHE problems, it may be nice to decrease the 
priority of DHE cipher suites as well.  I update the CSR accordingly.

> I would expect no performance impact as most modern/perfcritical systems 
> would use ECDHE already (and the perf impact of preferring GCM over CBC 
> is a different discussion)
>
Agreed, I think the performance impact is minimal as well.

Thanks,
Xuelei

> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* security-dev <security-dev-bounces at openjdk.java.net> im Auftrag 
> von Xuelei Fan <xuelei.fan at oracle.com>
> *Gesendet:* Mittwoch, M?rz 20, 2019 6:19 AM
> *An:* security-dev at openjdk.java.net
> *Betreff:* Re: CSR Review Request, JDK-8163326, The default enabled 
> cipher suites should prefer forward secrecy
> Hi,
> 
> I extended this CSR to cover more update, and update per the comments.
> Please let me know your concerns by the end of March 21, 2019.
> 
> Thanks,
> Xuelei
> 
> On 3/6/2019 3:41 PM, Bernd Eckenfels wrote:
>  > I am not clear on what would ?preferred in current default context?
>  > mean. Does that mean it preferred the PFS ciphers anyway.. for suggested
>  > order in client handshake? as server? And what would be the non-Default
>  > context. Is this ?TLS? context?
>  >
>  > Gruss
>  > Bernd
>  > --
>  > http://bernd.eckenfels.net
>  > ------------------------------------------------------------------------
>  > *Von:* security-dev <security-dev-bounces at openjdk.java.net> im Auftrag
>  > von Sean Mullan <sean.mullan at oracle.com>
>  > *Gesendet:* Mittwoch, M?rz 6, 2019 9:12 PM
>  > *An:* security-dev at openjdk.java.net
>  > *Betreff:* Re: CSR Review Request, JDK-8163326, The default enabled
>  > cipher suites should prefer forward secrecy
>  > Hi Xuelei,
>  >
>  > In the Specification section, I think it would be useful to note which
>  > cipher suites are forward secret and which are not. Otherwise, it is
>  > difficult to see what has changed, since there are so many supported
>  > suites. Perhaps in parentheses, ex:
>  >
>  > TLS_AES_128_GCM_SHA256 (forward secret)
>  > ...
>  >
>  > I also think you should summarize what has changed or what is roughly
>  > the new order, for example:
>  >
>  > - The TLS_RSA suites have moved down ...
>  > - The TLS_ECDH suites have moved
>  > - The SSL_RSA suites have moved down ...
>  > etc...
>  >
>  > --Sean
>  >
>  > On 2/21/19 4:45 PM, Xuelei Fan wrote:
>  > > Hi,
>  > >
>  > > Could I get the CSR reviewed?
>  > > ??? https://bugs.openjdk.java.net/browse/JDK-8219545
>  > >
>  > > It is proposed to increase the priority of forward secrecy cipher
>  > > suites, and decrease the priority of RSA key exchange based cipher
>  > > suites for the default enabled cipher suites in the SunJSSE provider.
>  > >
>  > > Thanks,
>  > > Xuelei

From Nico.Williams at twosigma.com  Wed Mar 20 16:10:23 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Wed, 20 Mar 2019 16:10:23 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <D1C4A9D2-CF70-4B60-9AA5-1AD3A763F9BC@oracle.com>
References: <20181204203436.GA22527@twosigma.com>
 <EA6A3F91-8001-4317-8513-6EDE65EC6E79@oracle.com>
 <20181206184824.GB22527@twosigma.com>
 <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com>
 <20181212004054.GG22527@twosigma.com>
 <D265F857-2EE9-43B0-9259-CCB9F1C83028@oracle.com>
 <20190117190436.GD27060@twosigma.com>
 <EF109C45-C842-47B5-B14E-4A76DF6826D0@oracle.com>
 <20190215214502.GB4046@twosigma.com>
 <D1C4A9D2-CF70-4B60-9AA5-1AD3A763F9BC@oracle.com>
Message-ID: <20190320161023.GD9177@twosigma.com>

On Wed, Mar 20, 2019 at 10:20:28AM +0800, Weijun Wang wrote:
> New webrev at https://cr.openjdk.java.net/~weijun/6722928/webrev.05, and interdiff at
> 
>    https://cr.openjdk.java.net/~weijun/6722928/webrev.05/interdiff.patch.html

Thanks.  I'll take a look.

> I'll think more about secondsUntil() and getTGTEndTime(). Other comments below.
> 
> > - sspi.cpp:61
> > 
> >   61 #define SEC_SUCCESS(status) (*minor_status = status, (status) >= SEC_E_OK)
> >                                   ^^^^^^^^^^^^^^^^^^^^^^
> > 
> >   Please add parenthesis around the whole assignment expression.
> 
> OK, but what kind of bad things could happen?

First, there's a matter of hygiene: you need to parenthesize `status`,
and you do in the second part but not the first.  Second, assignments in
if statements need to be parenthesized to avoid compiler warnings -- and
this one is parenthesized, but who knows if a compiler might be confused
by the comma operator and emit a warning anyways.

> > - sspi.cpp:NewContext()
> > 
> >   Please fully-initialize all fields of the allocated context structure before
> >   returning it.
> 
> Some of them are of struct types, do I need to go inside and set each to zero? Or ZeroMemory the whole struct?

C does not guarantee that (void*)0 is an all-bits-zero pattern, but I
imagine all the supported Windows platforms do (certainly x86 and
x86_64).  So ZeroMemory will do.  For more portable code you should
ZeroMemory the struct then manually assign all the pointer values.

> > - sspi.cpp:flagSspi2Gss() and flagGss2Sspi()
> > 
> >   I realize that this would be a change to the Java bindings, so this is just
> >   a note, but, we should add support for GSS_C_DELEG_POLICY_FLAG.
> 
> How? Always set it with GSS_C_DELEG_FLAG?

No, we'd have to add the Java bindings too.  Forget this request.

> > - sspi.cpp:getTGTEndTime()
> > 
> >   Please immediately write to the `endTime' output parameter upon entry.
> 
> Are you afraid of garbages for "return 1"s? But I won't touch the parameter at all in this case.

Yes.  It's just defensive programming.

> > - sspi.cpp:315
> > 
> >   314     // input has realm, no need to add one
> >   315     if (wcschr(input, '@')) {
> > 
> >   This is not going to work with UPNs.  
> 
> Why not? I just want to find out if there is already a realm.

UPNs are of the form name\@domain at REALM.  You're not checking for `\@`.

You can't search for `@` backwards either because realm names can
actually have `\@` as well in them.

> > You should probably implement proper
> >   RFC1864 name format support, including backslash-quoting.
> 
> Ahh...

Right :)

> > - sspi.cpp:315
> > 
> >   315     if (wcschr(input, '@')) {
> >                             ^
> > 
> >   I don't know if it is necessary that this be L'@' or if the compiler will do
> >   the right thing because the `wc' argument of `wcschr()' is a `wchar_t'.
> > 
> >   Elsewhere you do use wide character literals, so I assume even if type
> >   promotion works correctly for char->WCHAR (does it?) you might want to be
> >   consistent.
> 
> I'll made them all L'@'.

Or stop using wchar_t...  :)

> >   wchar_t/WCHAR is cancer.
> > 
> >   I worry that adding any more wchar_t-using code makes worse the legacy
> >   cleanup as Windows starts to prefer UTF-8.  But whatever.
> > 
> > - sspi.cpp:351
> > 
> >   351     wcscpy_s(fullname + oldlen + 1, wcslen(realm) + 1, realm);
> > 
> >   It would be safer to use wcscat_s().
> 
> How is this unsafe? If using wcscat_s(), I'll need to add a '\0' after the '@' first.

You wouldn't have to compute the offset to copy at.  I call that safer.

> > - sspi.cpp:362
> > 
> >   362 #define CHECK_OUTPUT(x)  if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE;
> > 
> >   I would much prefer the more standard and safer do { ... } while (0)
> >   construction:
> > 
> >    362 #define CHECK_OUTPUT(x)  \
> >        do { if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE; } while (0)
> 
> I can do that, but why is this safer?

You don't have to worry about this

    if (something)
        CHECK_OUTPUT(out_arg);
--->else
        other stuff

That `else` will bind to the `if` that `CHECK_OUTPUT()` expands into.

> You mean there is actually no need to check the arguments?

No, I mean that they don't save that much work.

> > - sspi.cpp:527
> > 
> >   527     int len = (int)wcslen(fullname);
> > 
> >   You don't need that cast.  
> 
> There was a warning.

Yes, but see the comments that followed:

> >   But you should check first that `wcslen()' did
> >   not return a value larger than `INT_MAX'.
> > 
> >   You only even need an `int len' because `WideCharToMultiByte()' returns
> >   `int'...
> > 
> >   I'd write this like:
> > 
> >    527     int len;
> >            size_t namelen = wcslen(fullname);
> >            if (namelen > 255)
> >                goto err;
> >            // 04 01 00 ** 06 ** OID len:int32 name
> >            // ...
> >            //

> > - sspi.cpp:532,574
> > 
> >   You can't assume the length of a multi-byte string will be the same number
> >   of `char' as the number of `wchar_t' in the wide-char version of the string.
> > 
> >   Determinining the correct length is a bit tricky, though since we should be
> >   converting to UTF-8 (see above), you can assume that 4x is enough, use
> >   4*len for the buffer allocation, then take the correct length from
> >   WideCharToMultiByte().
> 
> OK.

(And even this assumes that we Windows won't do normalization on the
string, though if they normalize to NFC, I think the number of
codepoints can't go up.)

> > - sspi.cpp:607
> > 
> >   606     TimeStamp ts;
> >   607     ts.QuadPart = 0;
> > 
> >   Huh?  TimeStamp is a typedef of SECURITY_INTEGER, and SECURITY_INTEGER is a
> >   struct of the same shape and size as FILETIME, and has no QuadPart field.
> > 
> >   What am I missing?
> 
> It compiles. I think it's a union of one Quad or two DWORD.

Ok.

> > - sspi.cpp:954
> > 
> >   Should you check if there's an output token before doing this:
> > 
> >   954         ss = CompleteAuthToken(&pc->hCtxt, &outBuffDesc);
> > 
> >   ?
> 
> Does this matter? Do you think CompleteAuthToken cannot deal with no token?

Hmm, probably not.

> > - sspi.cpp:874 and others
> > 
> >   delete `output_token->value' and set it to NULL (and the length to 0) before
> >   returning errors after 865.
> 
> OK. Is this just a good habit or do you know someone using it even at a failure?

It's perfectly safe to gss_release_buffer() after a failure.  After all,
the failure might involve an error token.

> > - sspi.cpp:878,962-963
> > 
> >   The local variable `pfDone' is set but not used.  Drop it.
> 
> OK,
> 
> > 
> >   (The compiler should have warned about this, no?)
> 
> No.

Why not.

> > - sspi.cpp:964-966
> > 
> >   Change this:
> > 
> >   964     outFlag = flagSspi2Gss(outFlag);
> >   965 
> >   966     *ret_flags = (OM_uint32)outFlag;
> > 
> >   to:
> > 
> >   964     *ret_flags = flagSspi2Gss(outFlag);
> > 
> >   You don't use outFlag again.  Setting it to a different kind of set of flags
> >   seems like a trap for someone to fall into in the future.
> 
> Good.

Huh?

> > - sspi.cpp:948
> > 
> >   948     if (!SEC_SUCCESS(ss)) {
> >   949         return GSS_S_FAILURE;
> >   950     }
> >   951 
> >   952     if ((SEC_I_COMPLETE_NEEDED == ss)
> >   953             || (SEC_I_COMPLETE_AND_CONTINUE == ss)) {
> > 
> >   I can't find documentation on SEC_SUCCES().  I don't know if it treats
> >   SEC_I_COMPLETE_NEEDED as an error or not...  I gues it must not.  Can you
> >   confirm?
> 
> Not an error. I defined SEC_SUCCESS in this file.

Oy, sorry!

> > - sspi.cpp:1002
> > 
> >   It should be simple now to implement this...
> > 
> >   1002     PP(">>>> Calling UNIMPLEMENTED gss_accept_sec_context...");
> >   1003     return GSS_S_FAILURE;
> 
> Not our goal this time, and I don't know how to test. Does server on Windows only run as services?

Do we have servers that run on Windows?  I think we do.  Our shim
(forked from SAP's) works for us.

> > - gssapi.h:gss_acquire_cred()
> > 
> >        @@ -387,13 +399,13 @@
> > 
> >         /* Function Prototypes */
> > 
> >         GSS_DLLIMP OM_uint32 gss_acquire_cred(
> >                 OM_uint32 *,            /* minor_status */
> >        -        gss_name_t,             /* desired_name */
> >        +        gss_const_name_t,       /* desired_name */
> >                 OM_uint32,              /* time_req */
> >        -        gss_OID_set,            /* desired_mechs */
> >   ---->+        const gss_OID_set,      /* desired_mechs */
> >                 gss_cred_usage_t,       /* cred_usage */
> >                 gss_cred_id_t *,        /* output_cred_handle */
> >                 gss_OID_set *,          /* actual_mechs */
> >                 OM_uint32 *             /* time_rec */
> >         );
> > 
> >   That needs to be `gss_const_OID_set', not `const gss_OID_set'.
> > 
> >   There's a number of these.  Just search for "const gss_" -- any time you see
> >   that in a function prototype, it's wrong.
> 
> I think I copied all of them from Heimdal. Do you mean Heimdal is not complete at using the types?

Yes.  Thanks for noticing.  I'll fix it.

Nico
-- 

From adam.petcher at oracle.com  Wed Mar 20 18:32:49 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 20 Mar 2019 11:32:49 -0700 (PDT)
Subject: RFR 8221172: SunEC specific test is not limited to SunEC
Message-ID: <3fa09d8e-a9e1-a6f6-f28b-d77d7f9999d2@oracle.com>

The regression test I added for JDK-8147502[1] has a minor bug. The test 
only works for SunEC, so the calls to getInstance should specify SunEC 
as the provider. Please review the fix for this test bug---it should 
only take a moment.

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

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


From sean.mullan at oracle.com  Wed Mar 20 19:45:24 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 20 Mar 2019 15:45:24 -0400
Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in
 SunPKCS11 crypto provider
In-Reply-To: <f84d61a0-ce13-afa9-548e-6113cd906c3e@oracle.com>
References: <baa81e60-bde8-933e-3195-736c9a3408a2@redhat.com>
 <f84d61a0-ce13-afa9-548e-6113cd906c3e@oracle.com>
Message-ID: <a06a7747-6764-777f-dcf6-09878ff58515@oracle.com>

Please add a noreg-self label to the bug since it is a test only fix.

--Sean

On 3/19/19 11:51 AM, Xuelei Fan wrote:
> Hi Martin,
> 
> In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS" 
> should be disabled in the test case?? It may help for further update if 
> RSASSA-PSS get supported in the SunPKCS11 provider in the future.
> 
> Otherwise, looks fine to me.
> 
> Thanks,
> Xuelei
> 
> On 3/16/2019 12:52 PM, Martin Balao wrote:
>> Hi,
>>
>> Can I have a review for JDK-8220753 [1]?
>>
>> ? * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.00/
>>
>> The test is almost identical to the previous one [2], with a few changes
>> in the "initialize" function (so it does not depend on the removed
>> SunJSSE FIPS feature anymore).
>>
>> Thanks,
>> Martin.-
>>
>> -- 
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8220753
>> [2] -
>> http://hg.openjdk.java.net/jdk/jdk/file/bccd9966f1ed/test/jdk/sun/security/pkcs11/fips/TestTLS12.java 
>>
>>

From sean.mullan at oracle.com  Wed Mar 20 19:59:49 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 20 Mar 2019 15:59:49 -0400
Subject: RFR 8221172: SunEC specific test is not limited to SunEC
In-Reply-To: <3fa09d8e-a9e1-a6f6-f28b-d77d7f9999d2@oracle.com>
References: <3fa09d8e-a9e1-a6f6-f28b-d77d7f9999d2@oracle.com>
Message-ID: <2d16464c-d5ff-7e0f-59ed-2942d2a857d7@oracle.com>

Looks fine to me.

--Sean

On 3/20/19 2:32 PM, Adam Petcher wrote:
> The regression test I added for JDK-8147502[1] has a minor bug. The test 
> only works for SunEC, so the calls to getInstance should specify SunEC 
> as the provider. Please review the fix for this test bug---it should 
> only take a moment.
> 
> Webrev: http://cr.openjdk.java.net/~apetcher/8221172/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8221172
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8147502
> 

From sean.mullan at oracle.com  Wed Mar 20 20:00:32 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 20 Mar 2019 16:00:32 -0400
Subject: RFR 8221172: SunEC specific test is not limited to SunEC
In-Reply-To: <2d16464c-d5ff-7e0f-59ed-2942d2a857d7@oracle.com>
References: <3fa09d8e-a9e1-a6f6-f28b-d77d7f9999d2@oracle.com>
 <2d16464c-d5ff-7e0f-59ed-2942d2a857d7@oracle.com>
Message-ID: <09985a80-6e38-6d39-dfe6-be8c21ea38e0@oracle.com>

Just don't forget to add a noreg-self label to the bug...

--Sean

On 3/20/19 3:59 PM, Sean Mullan wrote:
> Looks fine to me.
> 
> --Sean
> 
> On 3/20/19 2:32 PM, Adam Petcher wrote:
>> The regression test I added for JDK-8147502[1] has a minor bug. The 
>> test only works for SunEC, so the calls to getInstance should specify 
>> SunEC as the provider. Please review the fix for this test bug---it 
>> should only take a moment.
>>
>> Webrev: http://cr.openjdk.java.net/~apetcher/8221172/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8221172
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8147502
>>

From Nico.Williams at twosigma.com  Wed Mar 20 21:26:26 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Wed, 20 Mar 2019 21:26:26 +0000
Subject: JGSS Enhancements (contribution by Two Sigma Open Source)
In-Reply-To: <B6B0E4D2-CE46-4EC2-AFDC-B4695ECF375E@oracle.com>
References: <20181003204928.GA26310@twosigma.com>
 <fcf57680-2197-d413-5c87-ce57a5fd79a5@oracle.com>
 <20181004171547.GE26310@twosigma.com>
 <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com>
 <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com>
 <20190305185743.GA9177@twosigma.com>
 <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com>
 <D0562FC5-3B69-44CF-9BB8-F533D3F1E66D@oracle.com>
 <20190306020946.GC9177@twosigma.com>
 <B6B0E4D2-CE46-4EC2-AFDC-B4695ECF375E@oracle.com>
Message-ID: <20190320212626.GE9177@twosigma.com>

On Wed, Mar 06, 2019 at 10:24:50AM +0800, Weijun Wang wrote:
> Tell me the title and description of the bug/RFE, and I'll create one like
> https://bugs.openjdk.java.net/browse/JDK-8212217.

Thanks.  All the commit subject lines work as bug synopses (when they
differ, the commit subject is in parenthesis below proposed synopsis):

 - (bug) Add missing dbgsysGetLastErrorString()

   dbgsys*() are wrappers around dlopen() (Unix) / LoadLibrary()
   (Windows).  A binding for dlerror() was missing.

 - (bug) cut/paste error in NativeUtil.c
   (Fix cut/paste error in NativeUtil.c)

 - (RFE) Cleanup error handling in GSSLibStub
   (Fix error handling in GSSLibStub)

 - (RFE) Need a String to gss_buffer_t conversion utility
   (Implement String to gss_buffer_t import)

 - (bug) GSS_S_FAILURE major status lost in importContext
   (Fix loss of GSS_S_FAILURE major status in importContext)

 - (bug) GSSNameElement constructor needs actual mechanism input
   (Add actual mechanism to native GSSNameElement state)

 - (RFE) Add getLocalName() GSSName method

 - (RFE) Add createCredential() with password

 - JDK-8212217 (exists)

 - (bug) SpNego multi-round-trip bug
   (Fix SpNego multi-round-trip bug)

 - (RFE) ServicePermission empty realm support

 - (bug) GSSCredentialSpineeds isDefaultCredential() method
   (Add isDefaultCredential() method to GSSCredentialSpi)

 - (bug) Prefer default cred handles if possible
   (JGSS: Prefer default cred handles if possible)

 - (bug) GSSName should extend Principal
   (Make GSSName implement Principal (add getName()))

   This is the key bug.  Without this a GSSName backed by the native C
   GSS-API library cannot be used with JAAS.

   Note that GSS name objects conceptually *are* principals.  The base
   RFCs, 2743 and 2744, both refer to them as such.

   A GSSName is notionally no different that a Krb5Principal, except as
   to implementation details.

 - (bug/RFE) Add GssLoginModule

   Naturally, Krb5LoginModule is not appropriate when using the native C
   GSS-API library.  That makes the non-existence of GssLoginModule a
   bug when using the native C GSS-API library.

   Arguably, JAAS's continued existence in a world without applets is a
   bug!  I would prefer JAAS be removed, but there is a great deal of
   cargo-culted JAAS-using application code out there that will not go
   away anytime soon, so at the very least stub classes and methods
   would have to stay behind.

   This commit adds a GssLoginModule that is almost a complete
   replacement for Krb5LoginModule.

   Missing functionality to make it a complete replacement of
   Krb5LoginModule:

    - kinit with key    (maps to gss_acquire_cred_from())
    - kinit with keytab (maps to gss_acquire_cred_from())

 - (RFE) Krb5LoginModule cleanup

 - (bug) Output actual mechanism
   (fixup SEAM bug uncomments)

 - (bug) Memory leak in exception cases in getJavaOID()
   (Fix leak in exception cases in getJavaOID())

 - (RFE) Simplify Krb5 context permissions checks
   (JGSS: Simplify context permissions checks)

 - (bug) Dispose of delegated cred handles early

   Like JDK-8212217.

   When a Java object has an associated C object, it's important to
   dispose() of the C object as soon as possible.  The GC does not know
   there there is more memory pressure due to that C object.  Java
   objects with unknown-to-the-GC C objects are icebergs.


> You're an author now, right? You can post one yourself, webrev is at https://hg.openjdk.java.net/code-tools/webrev.

OK, I'll figure that out.

> > So Peter, for example, doesn't need to be a contributor?
> 
> Anyone can reply, but to push the change, a formal openjdk reviewer is needed.

OK, thanks.

> If Peter rewrite the patch in total then he might need to sign the OCA.

That will not be the case.

> > Right, GitHub is sure a lot more convenient than webrevs.
> 
> Hope so, but I do switch between the udiff, sdiff, frames and new
> views of webrev a lot. It's not very friendly to comment of course.

This could be fixed though.  I'm surprised that webrev still doesn't
have a comment facility all these years later.  I left Sun (Oracle) in
2011 -- that webrev has hardly changed since it was created (when was
that?  I want to say it was around 2003) is a testament to its utility,
but it is also surprising because writing code review comments in e-mail
takes a lot more time than on a web page.

Nico
-- 

From weijun.wang at oracle.com  Thu Mar 21 03:01:32 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 21 Mar 2019 11:01:32 +0800
Subject: JGSS Enhancements (contribution by Two Sigma Open Source)
In-Reply-To: <20190320212626.GE9177@twosigma.com>
References: <20181003204928.GA26310@twosigma.com>
 <fcf57680-2197-d413-5c87-ce57a5fd79a5@oracle.com>
 <20181004171547.GE26310@twosigma.com>
 <90DCB9B4-B31C-4650-8415-F0C98A0B3C34@oracle.com>
 <36F21DBA-2BE8-45B7-9326-6BF3295CC391@oracle.com>
 <20190305185743.GA9177@twosigma.com>
 <70a81f1c-d783-b5ea-a8a1-ecc82af4ddc9@oracle.com>
 <D0562FC5-3B69-44CF-9BB8-F533D3F1E66D@oracle.com>
 <20190306020946.GC9177@twosigma.com>
 <B6B0E4D2-CE46-4EC2-AFDC-B4695ECF375E@oracle.com>
 <20190320212626.GE9177@twosigma.com>
Message-ID: <EC0072D4-D53F-47F0-A510-0F1F95CE5B5E@oracle.com>

All of them at

   https://bugs.openjdk.java.net/issues/?jql=assignee%20%3D%20nwilliams

You might want to add more descriptions.

Thanks,
Max


From mbalao at redhat.com  Thu Mar 21 04:24:13 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Mar 2019 01:24:13 -0300
Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in
 SunPKCS11 crypto provider
In-Reply-To: <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com>
References: <a03d6a49-5811-faad-e6ba-0e6c668d614a@redhat.com>
 <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com>
Message-ID: <acf11db3-b06e-9703-0a94-d0198fb7335f@redhat.com>

Hi Valerie,

On 3/19/19 7:17 PM, Valerie Peng wrote:
> 
> How about another potential problem - wrapper key may never get deleted?
> If we don't have a good solution to addressing it, at least add a
> comment about it?
> Rest looks fine.
> 

Thanks for your feedback.

The Wrapper Key was never meant to be destroyed. However, it's a good
idea and we should do it, in addition to fixing this bug.

Here it's my proposal for getting rid of the Wrapper Key when it's no
longer needed:

Webrev 01:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.01/

Please note that a few changes were required in SessionKeyRef objects
lifetime. SessionKeyRef objects will live as long as their corresponding
P11Key object lives -a similar scheme was implemented in the original
patch-. This allows us to decrement Wrapper Key references -and
eventually destroy it- while P11Key objects which don't have a native
key created are deleted. In other words, objects that have wrapped
native key information but don't have a native key alive can also
decrement the Wrapper Key reference counter when deleted.

Testing:

 * No regressions found in sun/security/pkcs11.

 * I've verified with the debugger all the new execution flows,
including the deletion of a Wrapper Key. It would be a bit difficult to
assert this from an automated test though.

Kind regards,
Martin.-

From mbalao at redhat.com  Thu Mar 21 05:16:40 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 21 Mar 2019 02:16:40 -0300
Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in
 SunPKCS11 crypto provider
In-Reply-To: <f84d61a0-ce13-afa9-548e-6113cd906c3e@oracle.com>
References: <baa81e60-bde8-933e-3195-736c9a3408a2@redhat.com>
 <f84d61a0-ce13-afa9-548e-6113cd906c3e@oracle.com>
Message-ID: <e3bec68f-7efd-15d9-fdd3-d2cbc6857085@redhat.com>

Hi Xuelei,

Thanks for your feedback.

On 3/19/19 12:51 PM, Xuelei Fan wrote:
> 
> In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS"
> should be disabled in the test case?? It may help for further update if
> RSASSA-PSS get supported in the SunPKCS11 provider in the future.

Sure. I've also added a similar comment explaining why we disable
Extended Master Secret for this test.

Webrev.01:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.01/

Are we good to go?

Thanks,
Martin.-

From xuelei.fan at oracle.com  Thu Mar 21 05:33:08 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 20 Mar 2019 22:33:08 -0700
Subject: RFR 8220753: Re-introduce the test case for TLS 1.2 algorithms in
 SunPKCS11 crypto provider
In-Reply-To: <e3bec68f-7efd-15d9-fdd3-d2cbc6857085@redhat.com>
References: <baa81e60-bde8-933e-3195-736c9a3408a2@redhat.com>
 <f84d61a0-ce13-afa9-548e-6113cd906c3e@oracle.com>
 <e3bec68f-7efd-15d9-fdd3-d2cbc6857085@redhat.com>
Message-ID: <9e8d87a9-0e12-2b94-8804-3f7a5e4c23c1@oracle.com>

Looks good to me.

Thanks for adding the comments..

Thanks,
Xuelei

On 3/20/2019 10:16 PM, Martin Balao wrote:
> Hi Xuelei,
> 
> Thanks for your feedback.
> 
> On 3/19/19 12:51 PM, Xuelei Fan wrote:
>>
>> In TestTLS12.java, would you mind add a comment about why "RSASSA-PSS"
>> should be disabled in the test case?? It may help for further update if
>> RSASSA-PSS get supported in the SunPKCS11 provider in the future.
> 
> Sure. I've also added a similar comment explaining why we disable
> Extended Master Secret for this test.
> 
> Webrev.01:
> 
>   * http://cr.openjdk.java.net/~mbalao/webrevs/8220753/8220753.webrev.01/
> 
> Are we good to go?
> 
> Thanks,
> Martin.-
> 

From christoph.langer at sap.com  Thu Mar 21 10:20:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 21 Mar 2019 10:20:34 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ?
Message-ID: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi,

I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update?

With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests.

Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all?

Just trying to start a discussion? ??

Best regards
Christoph

[0] http://openjdk.java.net/jeps/319
[1] https://bugs.openjdk.java.net/browse/JDK-8189131

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190321/753018b6/attachment.html>

From sean.mullan at oracle.com  Thu Mar 21 14:43:41 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 21 Mar 2019 10:43:41 -0400
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
Message-ID: <ac37cbac-c33a-7949-96c2-6d4a1b049402@oracle.com>

On 3/15/19 5:46 AM, Steve Groeger wrote:
> Hi all,
> 
> Not sure whether something on this subject has been raised before but I 
> was unable to see anything in the mailing lists.

I don't think it has been discussed in any detail on this alias.

However, there are some other libraries and toolkits that allow OpenSSL 
to be used for the crypto or TLS/SSL with Java applications, so it is 
something that is not unreasonable to inquire about - i.e., whether it 
would be useful to include something like this in the JDK.

> We have been looking at adding support to Java to use the OpenSSL 
> libraries as a JCE security provider if available on the system that a 
> Java application is being run on (or to build and bundle the OpenSSL 
> libraries with the JDK).
> 
> If not found then the security drops back to using the built in security 
> that is part of the existing JDK.
> 
> The use of the OpenSSL libraries can be disabled entirely or specific 
> algorithms can be disabled by use of command line options,
> i.e. Djdk.nativeCrypto=true | false ?and ?-Djdk.nativeDigest=true | false
> 
> Would this be something that might be useful to be contributed to OpenJDK.

Not sure w/o more information, but from a followup reply, it doesn't 
seem to be a proper fit for the JDK since it is not a separate JCE provider.

But, if we want to explore this further, I think it first makes sense to 
take a step back and focus more on what benefits an OpenSSL provider or 
"native bridge" would provide. I think you would have to make a strong 
case that the benefits outweigh the cost of maintaining a separate 
provider with additional code, etc. There are probably licensing issues 
as well that would need to be explored.

Anyway, happy to explore that in more detail if you like. One suggestion 
is to use the JEP template [1] to provide more detail as it contains the 
type of information that would be useful to start this type of discussion.

Thanks,
Sean

[1] https://openjdk.java.net/jeps/2

> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911 ?Mobex: 279990 ?Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From simone.bordet at gmail.com  Thu Mar 21 15:42:25 2019
From: simone.bordet at gmail.com (Simone Bordet)
Date: Thu, 21 Mar 2019 16:42:25 +0100
Subject: Use of OpenSSL as JCE security provider if available on system
In-Reply-To: <ac37cbac-c33a-7949-96c2-6d4a1b049402@oracle.com>
References: <OF97F366DD.CE3D8D9D-ON802583BE.003571B4-802583BE.0035B343@notes.na.collabserv.com>
 <ac37cbac-c33a-7949-96c2-6d4a1b049402@oracle.com>
Message-ID: <CAFWmRJ3Cih=0-H8Nk3QXjn_mN=YeWDv9Y8jQBLAgLBHowzzzLQ@mail.gmail.com>

Hi,

On Thu, Mar 21, 2019 at 3:43 PM Sean Mullan <sean.mullan at oracle.com> wrote:
> But, if we want to explore this further, I think it first makes sense to
> take a step back and focus more on what benefits an OpenSSL provider or
> "native bridge" would provide.

Benchmarked 3x-10x performance improvements.
https://nbsoftsolutions.com/blog/dropwizard-1-3-upcoming-tls-improvements

I guess the memory allocation/footprint has similar improvements, with
the JDK insisting at requiring ~17 KiB buffers to read HTTP requests
in the order of <1 KiB.

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From xuelei.fan at oracle.com  Thu Mar 21 18:49:11 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 21 Mar 2019 11:49:11 -0700
Subject: RFR [13] JDK-8221270: Duplicated synchronized keywords in
 SSLSocketImpl
Message-ID: <1fa53339-1b7d-b074-603f-31161ea4b784@oracle.com>

Hi,

Could I have the following update reviewed?

    http://cr.openjdk.java.net/~xuelei/8221270/webrev.00/

The implementation of SSLSocketImpl.getHandshakeSession() uses two 
synchronized over the same object.  One should be sufficient.

Code cleanup, no new regression test.

Thanks,
Xuelei

From sean.mullan at oracle.com  Thu Mar 21 19:18:24 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 21 Mar 2019 15:18:24 -0400
Subject: RFR [13] JDK-8221270: Duplicated synchronized keywords in
 SSLSocketImpl
In-Reply-To: <1fa53339-1b7d-b074-603f-31161ea4b784@oracle.com>
References: <1fa53339-1b7d-b074-603f-31161ea4b784@oracle.com>
Message-ID: <6533c2a2-0de3-243b-dc3a-47d23b5ee375@oracle.com>

Looks good.

--Sean

On 3/21/19 2:49 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I have the following update reviewed?
> 
>  ?? http://cr.openjdk.java.net/~xuelei/8221270/webrev.00/
> 
> The implementation of SSLSocketImpl.getHandshakeSession() uses two 
> synchronized over the same object.? One should be sufficient.
> 
> Code cleanup, no new regression test.
> 
> Thanks,
> Xuelei

From xuelei.fan at oracle.com  Thu Mar 21 19:27:22 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 21 Mar 2019 12:27:22 -0700
Subject: RFR [13] JDK-8221273, sun/security/pkcs11/tls/tls12/TestTLS12.java on
 ProblemList.txt
Message-ID: <ffabb678-4c25-89de-6f89-13503b585bf0@oracle.com>

Hi,

Please review this update to problem list 
sun/security/pkcs11/tls/tls12/TestTLS12.java, which is failing on 
windows.  The issue will be addressed in JDK-8221271.

Thanks,
Xuelei

$ hg diff test/jdk/ProblemList.txt
diff -r f10ca228b22f test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt  Thu Mar 21 17:38:41 2019 +0000
+++ b/test/jdk/ProblemList.txt  Thu Mar 21 12:24:51 2019 -0700
@@ -683,6 +683,7 @@
  sun/security/pkcs11/tls/TestMasterSecret.java 
8204203 windows-all
  sun/security/pkcs11/tls/TestPRF.java 
8204203 windows-all
  sun/security/pkcs11/tls/TestPremaster.java 
8204203 windows-all
+sun/security/pkcs11/tls/tls12/TestTLS12.java                    8221271 
windows-all
  sun/security/tools/keytool/NssTest.java 
8204203 windows-all

From sean.mullan at oracle.com  Thu Mar 21 19:32:24 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 21 Mar 2019 15:32:24 -0400
Subject: RFR [13] JDK-8221273,
 sun/security/pkcs11/tls/tls12/TestTLS12.java on ProblemList.txt
In-Reply-To: <ffabb678-4c25-89de-6f89-13503b585bf0@oracle.com>
References: <ffabb678-4c25-89de-6f89-13503b585bf0@oracle.com>
Message-ID: <384d3d5e-b4ae-703c-a1ce-03e0fc00f0dc@oracle.com>

Looks good.

--Sean

On 3/21/19 3:27 PM, Xuelei Fan wrote:
> Hi,
> 
> Please review this update to problem list 
> sun/security/pkcs11/tls/tls12/TestTLS12.java, which is failing on 
> windows.? The issue will be addressed in JDK-8221271.
> 
> Thanks,
> Xuelei
> 
> $ hg diff test/jdk/ProblemList.txt
> diff -r f10ca228b22f test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt? Thu Mar 21 17:38:41 2019 +0000
> +++ b/test/jdk/ProblemList.txt? Thu Mar 21 12:24:51 2019 -0700
> @@ -683,6 +683,7 @@
>  ?sun/security/pkcs11/tls/TestMasterSecret.java 8204203 windows-all
>  ?sun/security/pkcs11/tls/TestPRF.java 8204203 windows-all
>  ?sun/security/pkcs11/tls/TestPremaster.java 8204203 windows-all
> +sun/security/pkcs11/tls/tls12/TestTLS12.java??????????????????? 8221271 
> windows-all
>  ?sun/security/tools/keytool/NssTest.java 8204203 windows-all

From 1983-01-06 at gmx.net  Thu Mar 21 21:17:36 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Thu, 21 Mar 2019 22:17:36 +0100
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
Message-ID: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>

Hi Max,

here is my review based on webrev.04. Some of the statements might not 
be correct due to my little C/C++ knowledge, just correct me if I am wrong.

I am really looking to test this, especially as a SASL provider for my 
extended LDAP communication with Active Directory.

gssapi.h:
* There are several unnecessary formatting (whitespace) changes in the 
prototypes
sspi.cpp:
* I don't like the inconsistent naming of functions: PascalCase, 
camelCase, snake_case. Is that on purpose?
* header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI 
work as it is intended to work. Means less code you have to maintain
* Why do you redefine SEC_SUCCESS macro from sspi.h?
* OID defs: shouldn't the char * be casted to void *?
* Don't change the semantics of KRB5_TRACE. MIT Kerberos users are used 
to it, either write to the supplied file path or use a different name.
* showTime(): please use a readable format akin to %FT%T
* NewContext():
** why don't you just pass the package name as WCHAR pointer? There is 
no clear definition what happens if it is not SPNEGO w/o looking into 
the code
** If you log the token size you should also log if SecurityStatus isn't 
positive, just in case
* flagSspi2Gss() and complement: please document that ANON_FLAG is not 
supported by SSPI
* displayOID(): The function name is misleading. It claims to display an 
OID, but it doesn't. It displays a custom name It should be somewhat 
similar to gss_oid_to_str() shouldn't it?
* getTGTEndTime(): Wouldn't it be easier to call 
AcquireCredentialsHandle() and inspect ptsExpiry field?
* get_full_name():
** wcschr() doesn't it expect a L"string" as a second arg?
** What is the purpose of this function? It will not work reliably if 
you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN 
HTTP/travel.siemens.com
* gss_import_name():
** BOOLEAN isNegotiate isn't really readable code
** I am a bit confused, Kerberos/GSS names should be UTF-8 encoded, but 
you do "new SEC_WCHAR[len + 1];" where len denotes the length of bytes 
and not chars.
    This might a minor one, but may allocate more memory than necessary
** CP_ACP: I'd expect CP_UTF8 here
** "    value[len] = 0;" rather '\0'?
** "if (value[len-1] == '@') {" rather L"@"? This continues in the function
** "if (value[len-1] == '@') {" you should comment this block and 
explain why you are doing this. Is this because of "@ignore_me_rfcXXX"?
** SPN conversion, why do you replace the '@' with '/' explicitly for 
SSPI? A non-mech specific hostbased service is always neutral with '@'
* gss_canonicalize_name(): something is fishy consider the following case:
   gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to 
receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but 
get_full_name() doesn't do this
* gss_export_name(): probably the same issues as with gss_import_name()
* gss_display_name():
** "char* buffer = new char[len+1];" you are changing sematics again. 
len is length of wide chars. If you have L"J?rg.Bj?rn at EXAMPLE.COM" it 
won't fit into buffer.
** CP_ACP: UTF8?
* gss_acquire_cred():
** Why again duplicate code, but only package name differs?
** Doesn't pAuthData accept SEC_WINNT_AUTH_IDENTITY and why do you 
populate it at all if we need default credentials only?!
** TGT time from CredHandle is huge, true. I believe it is that huge 
because LSA retains your password in memory so you will ALWAYS have a 
valid TGT compared to the MIT Kerberos approach.
    Shall we really care for that value?
** Can someone explain me for the stupid why there is pszPrincipal in 
AcquireCredentialsHandle if a user principal cannot have anything else 
and machine principals do not retain any local SPN longterm keys?!
* gss_inquire_cred():
** Why do you ignore cred_usage? You do support all three values in 
gss_acquire_cred()
* gss_init_sec_conent():
** Why don't you probe for GSS_C_NO_CONTEXT instead of zero input_token 
for NewContext?
** Why do you already assign output_token length and value of nothing 
has yet happened and test for a NULL value?
** Same here with SEC_WINNT_AUTH_IDENTITY_EX

Michael


From weijun.wang at oracle.com  Fri Mar 22 01:10:00 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 22 Mar 2019 09:10:00 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
Message-ID: <37B67E0B-AF5E-4FA3-B95D-FD52C5563F8C@oracle.com>

Hi Michael,

Many thanks to your review. Sorry I'm new to the C side of GSS-API and SSPI and I write very little C code these days.

> On Mar 22, 2019, at 5:17 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> 
> Hi Max,
> 
> here is my review based on webrev.04. Some of the statements might not be correct due to my little C/C++ knowledge, just correct me if I am wrong.
> 
> I am really looking to test this, especially as a SASL provider for my extended LDAP communication with Active Directory.
> 
> gssapi.h:
> * There are several unnecessary formatting (whitespace) changes in the prototypes

I'll go thru all changes again.

> sspi.cpp:
> * I don't like the inconsistent naming of functions: PascalCase, camelCase, snake_case. Is that on purpose?

The PascalCase should not exist. Now all GSS-API implementations use snake_case and other helper functions use camelCase. I assume that's because I've written too many Java methods.

> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as it is intended to work. Means less code you have to maintain

Java's GSS codes are not very good at using NTLM as a mechanism (the header, multi-round...).

> * Why do you redefine SEC_SUCCESS macro from sspi.h?

Oops, I didn't realized it's a redefinition. I'll change the name. Or, do you know if my definition is too different from the original one?

> * OID defs: shouldn't the char * be casted to void *?

No compiler warning, so I haven't added any cast.

> * Don't change the semantics of KRB5_TRACE. MIT Kerberos users are used to it, either write to the supplied file path or use a different name.

How about only support "set KRB5_TRACE=/dev/stdout" now and be silent otherwise?

> * showTime(): please use a readable format akin to %FT%T

Sure.

> * NewContext():
> ** why don't you just pass the package name as WCHAR pointer? There is no clear definition what happens if it is not SPNEGO w/o looking into the code

OK I can do that. Only Negotiate and Kerberos are supported now...

> ** If you log the token size you should also log if SecurityStatus isn't positive, just in case

Many logs are actually used by myself while debugging. I don't have a list of what to show and what not. I'll see if this can be embedded into the SEC_SUCCESS macro.

> * flagSspi2Gss() and complement: please document that ANON_FLAG is not supported by SSPI

OK.

> * displayOID(): The function name is misleading. It claims to display an OID, but it doesn't. It displays a custom name It should be somewhat similar to gss_oid_to_str() shouldn't it?

The method is enough for my debugging purpose now. Unless there is a Windows function for that, I don't want to spend many time implementing that. I'm also afraid of C programming.

> * getTGTEndTime(): Wouldn't it be easier to call AcquireCredentialsHandle() and inspect ptsExpiry field?

The field has a strange value. See

   https://stackoverflow.com/questions/11028798/how-do-i-interpret-the-expiry-returned-by-acquirecredentialshandle-kerberos

> * get_full_name():
> ** wcschr() doesn't it expect a L"string" as a second arg?

Will fix it. But currently seems the compiler does a i8 -> i16 promotion.

> ** What is the purpose of this function? It will not work reliably if you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN HTTP/travel.siemens.com

Java does not support realm-less service name so I'll have to add one to make ServicePermission check working. In your case, is this a stopper? Can windows find out the correct realm even if I provide a false one? Or maybe I can give Java back the (possibly wrong) full name and remove it when passing to the windows API.

> * gss_import_name():

I'll make quite some changes in this function. I'll also reject non-Kerberos exports.

> ** BOOLEAN isNegotiate isn't really readable code
> ** I am a bit confused, Kerberos/GSS names should be UTF-8 encoded, but you do "new SEC_WCHAR[len + 1];" where len denotes the length of bytes and not chars.
>   This might a minor one, but may allocate more memory than necessary
> ** CP_ACP: I'd expect CP_UTF8 here

Yes.

> ** "    value[len] = 0;" rather '\0'?
> ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function
> ** "if (value[len-1] == '@') {" you should comment this block and explain why you are doing this. Is this because of "@ignore_me_rfcXXX"?
> ** SPN conversion, why do you replace the '@' with '/' explicitly for SSPI? A non-mech specific hostbased service is always neutral with '@'
> * gss_canonicalize_name(): something is fishy consider the following case:
>  gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but get_full_name() doesn't do this

Ideally it should be realm-less, but... See above.

> * gss_export_name(): probably the same issues as with gss_import_name()
> * gss_display_name():
> ** "char* buffer = new char[len+1];" you are changing sematics again. len is length of wide chars. If you have L"J?rg.Bj?rn at EXAMPLE.COM" it won't fit into buffer.

I'll x4 to be safe.

> ** CP_ACP: UTF8?
> * gss_acquire_cred():
> ** Why again duplicate code, but only package name differs?

To produce different tokens I'll need different CredHandle. Since I only want to support 2 mechs here it's easy to just hardcode them.

> ** Doesn't pAuthData accept SEC_WINNT_AUTH_IDENTITY and why do you populate it at all if we need default credentials only?!

Please give me more detail. I only want to exclude NTLM here.

> ** TGT time from CredHandle is huge, true. I believe it is that huge because LSA retains your password in memory so you will ALWAYS have a valid TGT compared to the MIT Kerberos approach.
>   Shall we really care for that value?

What's your suggestion?

> ** Can someone explain me for the stupid why there is pszPrincipal in AcquireCredentialsHandle if a user principal cannot have anything else and machine principals do not retain any local SPN longterm keys?!

Maybe someone will call this function with a non-null name, and then I'll reject the one which is not myself.

> * gss_inquire_cred():
> ** Why do you ignore cred_usage? You do support all three values in gss_acquire_cred()

This first version of sspi.cpp only support the client side.

> * gss_init_sec_conent():
> ** Why don't you probe for GSS_C_NO_CONTEXT instead of zero input_token for NewContext?

Is that more RFC compliant?

> ** Why do you already assign output_token length and value of nothing has yet happened and test for a NULL value?

Is there a way to let windows allocating it?

> ** Same here with SEC_WINNT_AUTH_IDENTITY_EX

To exclude NTLM.

Thanks,
Max

> 
> Michael
> 


From xuelei.fan at oracle.com  Fri Mar 22 03:24:25 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 21 Mar 2019 20:24:25 -0700
Subject: RFR [13] JDK-8168261: Use server cipher suites preference by default
Message-ID: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com>

Hi,

Could I get the update reviewed?
    http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/

With this update, server cipher suite preference will be used by default 
for TLS handshaking in the SunJSSE provider.  For more details, please 
refer to CSR:
    https://bugs.openjdk.java.net/browse/JDK-8219657

Thanks,
Xuelei

From 1983-01-06 at gmx.net  Fri Mar 22 09:28:24 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Fri, 22 Mar 2019 10:28:24 +0100
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <37B67E0B-AF5E-4FA3-B95D-FD52C5563F8C@oracle.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <37B67E0B-AF5E-4FA3-B95D-FD52C5563F8C@oracle.com>
Message-ID: <07ec0ae4-c5e6-266a-e149-faa5868b4b45@gmx.net>

Hi Max,

Am 2019-03-22 um 02:10 schrieb Weijun Wang:
> Hi Michael,
>
> Many thanks to your review. Sorry I'm new to the C side of GSS-API and SSPI and I write very little C code these days.
>
>> On Mar 22, 2019, at 5:17 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
>>
>> Hi Max,
>>
>> here is my review based on webrev.04. Some of the statements might not be correct due to my little C/C++ knowledge, just correct me if I am wrong.
>>
>> I am really looking to test this, especially as a SASL provider for my extended LDAP communication with Active Directory.
>

>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as it is intended to work. Means less code you have to maintain
>
> Java's GSS codes are not very good at using NTLM as a mechanism (the header, multi-round...).

Can you please elaborate why? The token content is opaque to the API and
isEstablished() will fail unless type 3 token has been received. I'd use
this as a change to improve JGSS regardless of NTLM.

>> * Why do you redefine SEC_SUCCESS macro from sspi.h?
>
> Oops, I didn't realized it's a redefinition. I'll change the name. Or, do you know if my definition is too different from the original one?

Here is sample code from Microsoft:
https://docs.microsoft.com/en-us/windows/desktop/secauthn/using-sspi-with-a-windows-sockets-server
I would not even bother adding it myself. What is the reason for this?

>> * OID defs: shouldn't the char * be casted to void *?
>
> No compiler warning, so I haven't added any cast.

Don't expect cl be a decent compiler. clang will give you one. Have a
look at this const array:
https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/gssapi_generic.c#L38

Code hygiene.

>> * Don't change the semantics of KRB5_TRACE. MIT Kerberos users are used to it, either write to the supplied file path or use a different name.
>
> How about only support "set KRB5_TRACE=/dev/stdout" now and be silent otherwise?

Hmm, I'd still insist on somthing else, it just doesn't feel right.
Maybe JGSS_KRB5_TRACE with fprintf(stderr,...)? And later one you can
imrpove/replace it?

>> * NewContext():
>> ** why don't you just pass the package name as WCHAR pointer? There is no clear definition what happens if it is not SPNEGO w/o looking into the code
>
> OK I can do that. Only Negotiate and Kerberos are supported now...

That is ok, if you signal unsupported mech.

>> * displayOID(): The function name is misleading. It claims to display an OID, but it doesn't. It displays a custom name It should be somewhat similar to gss_oid_to_str() shouldn't it?
>
> The method is enough for my debugging purpose now. Unless there is a Windows function for that, I don't want to spend many time implementing that. I'm also afraid of C programming.

I see. I am not aware of any Windows function because SSPI is at a
higher level than GSS-API. The user does not interact with OIDs. Why not
statically reserve a char array with OID strings?

>> * getTGTEndTime(): Wouldn't it be easier to call AcquireCredentialsHandle() and inspect ptsExpiry field?
>
> The field has a strange value. See
>
>     https://stackoverflow.com/questions/11028798/how-do-i-interpret-the-expiry-returned-by-acquirecredentialshandle-kerberos


Please see the third comment, it is from me. I have exprienced the same.
To be frank, I would accept it as-is because that is the way LSA works.
the way you do it now is as if you would use the internal KRB5 functions
from MIT Kerberos. It doesn't feel right.

>> * get_full_name():
>> ** wcschr() doesn't it expect a L"string" as a second arg?
>
> Will fix it. But currently seems the compiler does a i8 -> i16 promotion.

I wouldn't really rely on that. Otherwise you should always work with
_("string").

>> ** What is the purpose of this function? It will not work reliably if you have this case (solution 2?): Realm AD001.SIEMENS.NET, SPN HTTP/travel.siemens.com
>
> Java does not support realm-less service name so I'll have to add one to make ServicePermission check working. In your case, is this a stopper? Can windows find out the correct realm even if I provide a false one? Or maybe I can give Java back the (possibly wrong) full name and remove it when passing to the windows API.

Wait a second, don't you deduce the realm from the krb5.conf? I have
been using JGSS for the past 10 years now and since referrals don't
really work, I have used the domain_realm setion to solve that problem,
e.g, blnn719x.ww004.siemens.net = AD001.SIEMENS.NET. If you are talking
about domainbased services ldap at dc1.ad001.siemens.net@ad001.siemens.net
Windows does support them, but there is no OID for, it uses UKNOWN or
hostbased with three components.

Windows does *not* require the realm with the SPN, unless for the
usecase about specified, it will apply proper routing by itself if the
namespaces are properly configured. We moved two years ago from one
forest to another with a bidirectional trust and everything just work
with referrals with MIT Kerberos and MS Kerberos.

Maybe you need to provide an example to me to understand the JGSS
shortcomings.

>> * gss_import_name():
>
> I'll make quite some changes in this function. I'll also reject non-Kerberos exports.

OK, I will wait for the change.

>> ** "    value[len] = 0;" rather '\0'?
>> ** "if (value[len-1] == '@') {" rather L"@"? This continues in the function
>> ** "if (value[len-1] == '@') {" you should comment this block and explain why you are doing this. Is this because of "@ignore_me_rfcXXX"?
>> ** SPN conversion, why do you replace the '@' with '/' explicitly for SSPI? A non-mech specific hostbased service is always neutral with '@'
>> * gss_canonicalize_name(): something is fishy consider the following case:
>>   gss_name HTTP at server.example.com , gss_oid = KRB5. I'd expect to receive HTTP/server.example.com at EXAMPLE.COM (or w/o realm), but get_full_name() doesn't do this
>
> Ideally it should be realm-less, but... See above.

Same as above, it probably needs some example for me.

>> ** CP_ACP: UTF8?
>> * gss_acquire_cred():
>> ** Why again duplicate code, but only package name differs?
>
> To produce different tokens I'll need different CredHandle. Since I only want to support 2 mechs here it's easy to just hardcode them.

I concur, all you need is the package name, the code remains the same.
The out handle will have the appropriate dwLower, dwUpper to LSA to the
mech.

>> ** Doesn't pAuthData accept SEC_WINNT_AUTH_IDENTITY and why do you populate it at all if we need default credentials only?!
>
> Please give me more detail. I only want to exclude NTLM here.

Strike that, I just reread the API. Everything is fine. Though, I think
this shouldn't be necessary.

>> ** TGT time from CredHandle is huge, true. I believe it is that huge because LSA retains your password in memory so you will ALWAYS have a valid TGT compared to the MIT Kerberos approach.
>>    Shall we really care for that value?
>
> What's your suggestion?

I'd accept it as-is or truncate to year 9999 for ISO 8601 compliance. A
note in the docs is sufficient about that fact. This binding has other
semantics.

>> ** Can someone explain me for the stupid why there is pszPrincipal in AcquireCredentialsHandle if a user principal cannot have anything else and machine principals do not retain any local SPN longterm keys?!
>
> Maybe someone will call this function with a non-null name, and then I'll reject the one which is not myself.

So you are only thinking about a negative case?

>> * gss_inquire_cred():
>> ** Why do you ignore cred_usage? You do support all three values in gss_acquire_cred()
>
> This first version of sspi.cpp only support the client side.

You should then log at least that if usage is not initiator.

>> * gss_init_sec_conent():
>> ** Why don't you probe for GSS_C_NO_CONTEXT instead of zero input_token for NewContext?
>
> Is that more RFC compliant?

This is my understanding of the NO_ macros in MIT Kerbros. See also the
first hit:
https://github.com/krb5/krb5/search?q=GSS_C_NO_CONTEXT&unscoped_q=GSS_C_NO_CONTEXT

int initialContextToken = (*context_handle == GSS_C_NO_CONTEXT);

I'd always use the NO_ macros for cleaner code.

>> ** Why do you already assign output_token length and value of nothing has yet happened and test for a NULL value?
>
> Is there a way to let windows allocating it?

Consider to evaluate: ISC_REQ_ALLOCATE_MEMORY. Frees your from the
malloc() with the maxTokenSize from registry.


Michael

From xuelei.fan at oracle.com  Fri Mar 22 14:51:48 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 22 Mar 2019 07:51:48 -0700
Subject: RFR [13] JDK-8163326: Update the default enabled cipher suites
 preference
Message-ID: <297c8c91-e209-4180-2ca4-460a16c39964@oracle.com>

Hi,

Could I get the following update reviewed?
     http://cr.openjdk.java.net/~xuelei/8163326/webrev.00/

With this update, the SunJSSE default enabled cipher suites preference 
is adjusted accordingly.  For more details, please refer to CSR:
     https://bugs.openjdk.java.net/browse/JDK-8219545

Thanks,
Xuelei

From Nico.Williams at twosigma.com  Fri Mar 22 15:28:24 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Fri, 22 Mar 2019 15:28:24 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
Message-ID: <20190322152824.GF9177@twosigma.com>

On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
> it is intended to work. Means less code you have to maintain

There's a few reasons:

 - NTLM doesn't have an OID, at least as I remember

 - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
   to the ServicePermission stuff

IMO JAAS (and with it, *Permission) should be removed with prejudice now
that applet support has been removed.  Perhaps stubs should be left
behind for compatibility reasons, and all the doAs*() methods should
just act as though permission is granted.

Removing JAAS would be a wonderful simplification, then the JGSS stuff
could stop being Kerberos-specific.

Nico
-- 

From 1983-01-06 at gmx.net  Fri Mar 22 16:23:27 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Fri, 22 Mar 2019 17:23:27 +0100
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190322152824.GF9177@twosigma.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
Message-ID: <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>

Am 2019-03-22 um 16:28 schrieb Nico Williams:
> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
>> it is intended to work. Means less code you have to maintain
>
> There's a few reasons:
>
>   - NTLM doesn't have an OID, at least as I remember

I don't agree:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/e21c0b07-8662-41b7-8853-2b9184eab0db

Heimdal uses it, look at a SPNEGO token from SSPI in Wireshark, you'll
see it.

>   - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
>     to the ServicePermission stuff

Granted.

> IMO JAAS (and with it, *Permission) should be removed with prejudice now
> that applet support has been removed.  Perhaps stubs should be left
> behind for compatibility reasons, and all the doAs*() methods should
> just act as though permission is granted.
>
> Removing JAAS would be a wonderful simplification, then the JGSS stuff
> could stop being Kerberos-specific.

Fully agree, it has been a pain in the last couple of years. This would
also require an RFC update for the JGSS bindings to logon onto network
with username/password or keytab w/o login modules.

Michael

From xuelei.fan at oracle.com  Fri Mar 22 16:39:34 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 22 Mar 2019 09:39:34 -0700
Subject: RFR [13] JDK-8218889: Improperly use of the Optional API
Message-ID: <e567e786-4891-317d-0234-d6eec7a95bcc@oracle.com>

Hi,

Could I have the following update reviewed:
     http://cr.openjdk.java.net/~xuelei/8218889/webrev.00/

In general Optional is a good option.  However, 
Optional.ofNullable?(null).get() throws NoSuchElementException, as limit 
the benefits to use Optional.ofNullable?() for null object in the 
session management context.   With this update, the Optional is replaced 
with other coding conventions.

Code cleanup, no new regression test.

Thanks,
Xuelei

From jamil.j.nimeh at oracle.com  Fri Mar 22 16:41:59 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 22 Mar 2019 09:41:59 -0700
Subject: RFR [13] JDK-8218889: Improperly use of the Optional API
In-Reply-To: <e567e786-4891-317d-0234-d6eec7a95bcc@oracle.com>
References: <e567e786-4891-317d-0234-d6eec7a95bcc@oracle.com>
Message-ID: <738b6af7-00fa-ea02-00d1-74853d13da34@oracle.com>

This looks fine to me.

--Jamil

On 3/22/19 9:39 AM, Xuelei Fan wrote:
> Hi,
>
> Could I have the following update reviewed:
> ??? http://cr.openjdk.java.net/~xuelei/8218889/webrev.00/
>
> In general Optional is a good option.? However, 
> Optional.ofNullable?(null).get() throws NoSuchElementException, as 
> limit the benefits to use Optional.ofNullable?() for null object in 
> the session management context.?? With this update, the Optional is 
> replaced with other coding conventions.
>
> Code cleanup, no new regression test.
>
> Thanks,
> Xuelei

From bradford.wetmore at oracle.com  Fri Mar 22 17:40:22 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 22 Mar 2019 10:40:22 -0700
Subject: RFR [13] JDK-8218889: Improperly use of the Optional API
In-Reply-To: <738b6af7-00fa-ea02-00d1-74853d13da34@oracle.com>
References: <e567e786-4891-317d-0234-d6eec7a95bcc@oracle.com>
 <738b6af7-00fa-ea02-00d1-74853d13da34@oracle.com>
Message-ID: <8247cad2-a56c-c0e9-3a8a-8d3119603b95@oracle.com>

+1.

I noticed this earlier while looking at my other work, and was wondering 
if this was a new style that I had missed.

Thanks,

Brad


On 3/22/2019 9:41 AM, Jamil Nimeh wrote:
> This looks fine to me.
> 
> --Jamil
> 
> On 3/22/19 9:39 AM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I have the following update reviewed:
>> ??? http://cr.openjdk.java.net/~xuelei/8218889/webrev.00/
>>
>> In general Optional is a good option.? However, Optional.ofNullable? 
>> (null).get() throws NoSuchElementException, as limit the benefits to 
>> use Optional.ofNullable?() for null object in the session management 
>> context.?? With this update, the Optional is replaced with other 
>> coding conventions.
>>
>> Code cleanup, no new regression test.
>>
>> Thanks,
>> Xuelei

From Nico.Williams at twosigma.com  Fri Mar 22 19:24:02 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Fri, 22 Mar 2019 19:24:02 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
Message-ID: <20190322192402.GG9177@twosigma.com>

On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 16:28 schrieb Nico Williams:
> > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> > > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
> > > it is intended to work. Means less code you have to maintain
> > 
> > There's a few reasons:
> > 
> >   - NTLM doesn't have an OID, at least as I remember
> 
> I don't agree:
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/e21c0b07-8662-41b7-8853-2b9184eab0db

Ah, good to know.

> Heimdal uses it, look at a SPNEGO token from SSPI in Wireshark, you'll
> see it.

Then I should have known...

    lib/gssapi/mech/gss_oid.c:/* GSS_NTLM_MECHANISM - 1.3.6.1.4.1.311.2.2.10 */
    lib/gssapi/oid.txt:oid  base    GSS_NTLM_MECHANISM                      1.3.6.1.4.1.311.2.2.10

Nico
-- 

From Nico.Williams at twosigma.com  Fri Mar 22 19:29:06 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Fri, 22 Mar 2019 19:29:06 +0000
Subject: was Re: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
Message-ID: <20190322192906.GH9177@twosigma.com>

On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 16:28 schrieb Nico Williams:
> >   - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
> >     to the ServicePermission stuff
> 
> Granted.

:(

> > IMO JAAS (and with it, *Permission) should be removed with prejudice now
> > that applet support has been removed.  Perhaps stubs should be left
> > behind for compatibility reasons, and all the doAs*() methods should
> > just act as though permission is granted.
> > 
> > Removing JAAS would be a wonderful simplification, then the JGSS stuff
> > could stop being Kerberos-specific.
> 
> Fully agree, it has been a pain in the last couple of years. This would
> also require an RFC update for the JGSS bindings to logon onto network
> with username/password or keytab w/o login modules.

Our contributions add acquireCredWithPassword() methods.

And we could add acquireCredFrom() to match gss_acquire_cred_from() /
gss_add_cred_from() (a Heimdal and MIT innovation that allows, among
other things, to use a specific keytab).

But also, most JGSS users don't need the JDK to have this functionality
since using kinit externally and KRB5* env vars works perfectly fine for
the vast majority of cases.

Nico
-- 

From sean.mullan at oracle.com  Fri Mar 22 19:33:27 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 22 Mar 2019 15:33:27 -0400
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>

Hi Christoph,

On 3/21/19 6:20 AM, Langer, Christoph wrote:
> Hi,
> 
> I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update?
> 
> With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests.
> 
> Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all?

I can answer the first two questions. I talked to one of our Product 
Managers who was involved with this JEP and he said that we have 
permission to release these certificates as open source at OpenJDK (much 
as Mozilla has roots in Firefox).  Therefore there should be no concerns 
using with OpenJDK 8 or other versions for that matter.  If you mean the 
jdk8u project specifically, you should check with the current 
maintainers for interest in this as I think they currently use other 
means for their builds.

--Sean

> 
> Just trying to start a discussion? ??
> 
> Best regards
> Christoph
> 
> [0] http://openjdk.java.net/jeps/319
> [1] https://bugs.openjdk.java.net/browse/JDK-8189131
> 

From Nico.Williams at twosigma.com  Fri Mar 22 19:43:46 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Fri, 22 Mar 2019 19:43:46 +0000
Subject: Obsolete and remove JAAS please (was Re: RFR 6722928: Support SSPI
 as a native GSS-API provider)
In-Reply-To: <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
Message-ID: <20190322194346.GI9177@twosigma.com>

On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 16:28 schrieb Nico Williams:
> >   - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
> >     to the ServicePermission stuff
> 
> Granted.
> 
> > IMO JAAS (and with it, *Permission) should be removed with prejudice now
> > that applet support has been removed.  Perhaps stubs should be left
> > behind for compatibility reasons, and all the doAs*() methods should
> > just act as though permission is granted.
> > 
> > Removing JAAS would be a wonderful simplification, then the JGSS stuff
> > could stop being Kerberos-specific.
> 
> Fully agree, it has been a pain in the last couple of years. This would
> also require an RFC update for the JGSS bindings to logon onto network
> with username/password or keytab w/o login modules.

I replied separately about the kinit functionality of Krb5LoginModule.

I want to call out the point that JAAS has no raison d'?tre in a world
without applets.

Even in a JVM multi-tenancy project (which I'm told there's continued
desire for), while there may be uses for doAs() and doAsPrivileged(),
those would be subtly but very different notions than in JAAS.  Any JVM
multi-tenancy project should either start from scratch, or if it will
reuse JAAS classes, should clean up the mess that is ServicePermissions
(and probably others).  (I would also argue against JVM multi-tenancy.)

IMO it would be better to remove JAAS altogether.

All LoginModule functionality that is used to acquire credentials should
be made available outside JAAS.  E.g., JGSS could use kinit-style
functionality (acquireCredWithPassword() and so on).  "Could use", not
"needs", because external use of kinit and KRB5* env vars works for 97%
of cases, though being able to cover 100% is nice, and since I've done a
lot of the necessary work (acquireCredWithPassword()), might as well do
the rest (i.e., add acquireCredFrom()).

It sure feels like a lot of JAAS+JGSS apps use JAAS only for cargo cult
reasons (i.e., devs copy-pasting what [appears to] works for others), or
else because the developers don't know how to use kinit externally.

The Krb5 stack appears to be practically abandoned and far behind all
other Kerberos implementations.  With our JGSS contributions (and Max's
SSPI bridge) there is also the opportunity to remove the Krb5 stack,
which would lighten the development and maintenance burden on Oracle
engineers, freeing up cycles for other, more interesting work.

Nico
-- 

From xuelei.fan at oracle.com  Fri Mar 22 21:02:53 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 22 Mar 2019 14:02:53 -0700
Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys
 are stored in PKCS11
Message-ID: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com>

Hi,

Could I get the following update reviewed?
    http://cr.openjdk.java.net/~xuelei/8217610/webrev.00/

For EC key exchange in TLS connections, the private key should use the 
specified EC groups.  The current code is calling 
ECPrivateKey.getParams().  However, the private key may be not an 
instance of ECPrivateKey, for example for non-extractable private key in 
the SunPKCS11 provider.

To fix the tricky bug, in this update, if private key is an instance of 
ECPrivateKey, use it; otherwise, try to check the groups in the public 
key of the X.509 certificate bound to the private key.

No hardware to reproduce the issue, and no new regression test.  The 
update is straightforward.  Please help to check the patch if you can 
play with a hardware token.

Thanks,
Xuelei

From weijun.wang at oracle.com  Fri Mar 22 23:21:24 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 23 Mar 2019 07:21:24 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190322152824.GF9177@twosigma.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
Message-ID: <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>



> On Mar 22, 2019, at 11:28 PM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> 
> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
>> it is intended to work. Means less code you have to maintain
> 
> There's a few reasons:
> 
> - NTLM doesn't have an OID, at least as I remember
> 
> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
>   to the ServicePermission stuff

Yes, it needs to check a permission if the token is SPNEGO and internally it's Kerberos. I also believe the HTTP Negotiate code there is probably not good at dealing with a Negotiate dialog with 2 rounds. The first problem should be easy to fix, I'll see if the 2nd is complicated.

--Max

> 
> IMO JAAS (and with it, *Permission) should be removed with prejudice now
> that applet support has been removed.  Perhaps stubs should be left
> behind for compatibility reasons, and all the doAs*() methods should
> just act as though permission is granted.
> 
> Removing JAAS would be a wonderful simplification, then the JGSS stuff
> could stop being Kerberos-specific.
> 
> Nico
> -- 


From 1983-01-06 at gmx.net  Fri Mar 22 23:50:34 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Sat, 23 Mar 2019 00:50:34 +0100
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>
Message-ID: <aa68622e-995a-93cf-bb81-8cbc1c5c4c10@gmx.net>

Am 2019-03-23 um 00:21 schrieb Weijun Wang:
>
>
>> On Mar 22, 2019, at 11:28 PM, Nico Williams <Nico.Williams at twosigma.com> wrote:
>>
>> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
>>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
>>> it is intended to work. Means less code you have to maintain
>>
>> There's a few reasons:
>>
>> - NTLM doesn't have an OID, at least as I remember
>>
>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
>>    to the ServicePermission stuff
>
> Yes, it needs to check a permission if the token is SPNEGO and internally it's Kerberos. I also believe the HTTP Negotiate code there is probably not good at dealing with a Negotiate dialog with 2 rounds. The first problem should be easy to fix, I'll see if the 2nd is complicated.

Reminds me of https://issues.apache.org/jira/browse/HTTPCLIENT-1625...

From 1983-01-06 at gmx.net  Sat Mar 23 00:03:17 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Sat, 23 Mar 2019 01:03:17 +0100
Subject: was Re: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190322192906.GH9177@twosigma.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
 <20190322192906.GH9177@twosigma.com>
Message-ID: <6ee577f9-3915-dcf9-4a01-3e57c151d6fa@gmx.net>

Am 2019-03-22 um 20:29 schrieb Nico Williams:
> On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
>> Am 2019-03-22 um 16:28 schrieb Nico Williams:
>>>    - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
>>>      to the ServicePermission stuff
>>
>> Granted.
>
> :(
>
>>> IMO JAAS (and with it, *Permission) should be removed with prejudice now
>>> that applet support has been removed.  Perhaps stubs should be left
>>> behind for compatibility reasons, and all the doAs*() methods should
>>> just act as though permission is granted.
>>>
>>> Removing JAAS would be a wonderful simplification, then the JGSS stuff
>>> could stop being Kerberos-specific.
>>
>> Fully agree, it has been a pain in the last couple of years. This would
>> also require an RFC update for the JGSS bindings to logon onto network
>> with username/password or keytab w/o login modules.
>
> Our contributions add acquireCredWithPassword() methods.
>
> And we could add acquireCredFrom() to match gss_acquire_cred_from() /
> gss_add_cred_from() (a Heimdal and MIT innovation that allows, among
> other things, to use a specific keytab).

Based on this:
https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/gssapi_ext.h

That would be awesome. We have several use cases for keytabs:

1) traditional one, machine account with SPNs (acceptor, sometimes
initiator)
2) service account (initiator)
3) service account with SPNs (both)

That would make JAAS and the Krb5LoginModule completely obsolete.

> But also, most JGSS users don't need the JDK to have this functionality
> since using kinit externally and KRB5* env vars works perfectly fine for
> the vast majority of cases.

I see several cases not covered if MIT Kerberos is used:

1)
# export KRB5_CLIENT_KTNAME=/etc/krb5.keytab
# curl --negotiate -u : ...do magic...

will simply not work with a keytab created by Samba because the machine
UPN is not the first entry of the table. One would require
KRB5_CLIENT_PRINCIPAL for that. It would cover gss_acquire_cred_from()
with the gss_name_t.

2) non-file based ccaches cannot be accessed by Java ATM (e.g., keyring).

3) serialization of credentials to disk for futher usage (e.g.,
credetial delegation)

4) Consider you use MIT Kerberos via JGSS and receive a delegated
credential via HTTP, you store that in the request (no session). There
is no Servlet API callback that the request has been disposed, you
cannot call GSSCredential#dispose(). It will or may lead to a memory
leak. I don't know whether the GC will handle this. Frankly, I need to
check mod_auth_gssapi how they solve that because that memory does not
come from apr_pool_t.

But I really would like to see
https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions
coming.

Michael

From 1983-01-06 at gmx.net  Sat Mar 23 00:07:45 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Sat, 23 Mar 2019 01:07:45 +0100
Subject: Obsolete and remove JAAS please (was Re: RFR 6722928: Support
 SSPI as a native GSS-API provider)
In-Reply-To: <20190322194346.GI9177@twosigma.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
 <20190322194346.GI9177@twosigma.com>
Message-ID: <34888131-7779-c7fe-57f5-9543e52399ea@gmx.net>

Am 2019-03-22 um 20:43 schrieb Nico Williams:
> On Fri, Mar 22, 2019 at 05:23:27PM +0100, Michael Osipov wrote:
>> Am 2019-03-22 um 16:28 schrieb Nico Williams:
>>>    - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
>>>      to the ServicePermission stuff
>>
>> Granted.
>>
>>> IMO JAAS (and with it, *Permission) should be removed with prejudice now
>>> that applet support has been removed.  Perhaps stubs should be left
>>> behind for compatibility reasons, and all the doAs*() methods should
>>> just act as though permission is granted.
>>>
>>> Removing JAAS would be a wonderful simplification, then the JGSS stuff
>>> could stop being Kerberos-specific.
>>
>> Fully agree, it has been a pain in the last couple of years. This would
>> also require an RFC update for the JGSS bindings to logon onto network
>> with username/password or keytab w/o login modules.
> 
> I replied separately about the kinit functionality of Krb5LoginModule.
> 
> I want to call out the point that JAAS has no raison d'?tre in a world
> without applets.
> 
> Even in a JVM multi-tenancy project (which I'm told there's continued
> desire for), while there may be uses for doAs() and doAsPrivileged(),
> those would be subtly but very different notions than in JAAS.  Any JVM
> multi-tenancy project should either start from scratch, or if it will
> reuse JAAS classes, should clean up the mess that is ServicePermissions
> (and probably others).  (I would also argue against JVM multi-tenancy.)
> 
> IMO it would be better to remove JAAS altogether.
> 
> All LoginModule functionality that is used to acquire credentials should
> be made available outside JAAS.  E.g., JGSS could use kinit-style
> functionality (acquireCredWithPassword() and so on).  "Could use", not
> "needs", because external use of kinit and KRB5* env vars works for 97%
> of cases, though being able to cover 100% is nice, and since I've done a
> lot of the necessary work (acquireCredWithPassword()), might as well do
> the rest (i.e., add acquireCredFrom()).

acquireCredFrom() is a must have for multi-tenancy and services. Think 
of TLS virtual hosting with one keytab per host on a Tomcat.

> It sure feels like a lot of JAAS+JGSS apps use JAAS only for cargo cult
> reasons (i.e., devs copy-pasting what [appears to] works for others), or
> else because the developers don't know how to use kinit externally.
> 
> The Krb5 stack appears to be practically abandoned and far behind all
> other Kerberos implementations.  With our JGSS contributions (and Max's
> SSPI bridge) there is also the opportunity to remove the Krb5 stack,
> which would lighten the development and maintenance burden on Oracle
> engineers, freeing up cycles for other, more interesting work.

That is true, but it would require to have a very good coverage via SSPI 
or MIT Kerberos on all platforms where Java runs, not just those Oracle 
officially supports. I do use the same code one four operating systems 
with Java.

Michael


From david.lloyd at redhat.com  Sat Mar 23 15:45:34 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Sat, 23 Mar 2019 10:45:34 -0500
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190322152824.GF9177@twosigma.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
Message-ID: <CANghgrTP9FfK_YhjzhPdiNEmNrTWMX=BAucuX_OWPT2P=MO1bA@mail.gmail.com>

On Fri, Mar 22, 2019 at 10:29 AM Nico Williams
<Nico.Williams at twosigma.com> wrote:
>
> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
> > it is intended to work. Means less code you have to maintain
>
> There's a few reasons:
>
>  - NTLM doesn't have an OID, at least as I remember
>
>  - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
>    to the ServicePermission stuff
>
> IMO JAAS (and with it, *Permission) should be removed with prejudice now
> that applet support has been removed.  Perhaps stubs should be left
> behind for compatibility reasons, and all the doAs*() methods should
> just act as though permission is granted.

I assume that you mean SecurityManager and AccessController as well
(which are not a part of JAAS AFAIK)?

-- 
- DML

From andimullaraj at gmail.com  Sun Mar 24 03:04:55 2019
From: andimullaraj at gmail.com (Andi Mullaraj)
Date: Sat, 23 Mar 2019 20:04:55 -0700
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <d817c9d2-726d-5b55-0d00-7c4ee23b2867@oracle.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
 <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
 <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>
 <CADvBZ+3Ov=oL9d0OwpsCP_rOxwGrmkufF_8j989-6J6-aC+pOg@mail.gmail.com>
 <CAN1v_zrenJqA=vcV4=5RxAJ4-6TVEuqRuFQd_+NfwdF8ZOAoTA@mail.gmail.com>
 <CADvBZ+0vr+cnb6JUEgLjijJSmBzEzvW8vdT_cHqNd3Q1qYCghQ@mail.gmail.com>
 <CANghgrRkE_oqSyPfQq9C7v1k7gSmGMz20uMW=7J=-WVwSgGjKA@mail.gmail.com>
 <CADvBZ+1NwvWsVC6qx_Ovk+FZKRb9cUi-BuCjyeRpjm8iiEsYbQ@mail.gmail.com>
 <d817c9d2-726d-5b55-0d00-7c4ee23b2867@oracle.com>
Message-ID: <CADvBZ+3v2LLhvwoZyjpMkmvCv3LnXipijsWFDjZwvA7pt9u1CQ@mail.gmail.com>

Thank you Alan,

I am in awe! If Loom delivers on its promises I see no point continuing
this (or any blocking/async/io) discussion. I think I will open source my
implementation.

Thanks to all for the feedback,
Best,
--Andi



On Mon, Mar 11, 2019 at 12:58 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 09/03/2019 09:35, Andi Mullaraj wrote:
>
>
> In light of the previous point, I couldn't disagree more. As it is
> painfully clear, the proposed approach stays within the confines of nio,
> and no duplication is needed (I also hate duplication).
>
> This is a topic that was explored, and ruled out, in JSR-51 but lead to
> SSLEngine. Yes, SSLEngine has pain points and performance issues and I
> think it would be better to focus on those issues and see how SSLEngine
> could be improved. This would be more beneficial for the eco system today
> as most developers don't use SocketChannels or Selectors directly (those
> APIs tend to be hidden by libraries and frameworks so most developers don't
> see them).
>
> Also as a reminder is that we are exploring, in Project Loom, ways to make
> it easy to develop simple blocking code that scales as well as code forced
> to asynchronous frameworks today. If we get that right then it should
> eliminate many of the reasons to create further asynchronous or
> non-blocking APIs.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190323/59183d53/attachment.html>

From christoph.langer at sap.com  Sun Mar 24 20:38:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 24 Mar 2019 20:38:14 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
Message-ID: <HE1PR0201MB2266E76919BDF3FAE4C543578A5D0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Sean,

> > Now my questions are: Is it legally possible to bring these root certificates
> also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK
> 8 via an update release? And, last but not least, would there be interest in
> the community for that at all?
> 
> I can answer the first two questions. I talked to one of our Product
> Managers who was involved with this JEP and he said that we have
> permission to release these certificates as open source at OpenJDK (much
> as Mozilla has roots in Firefox).  Therefore there should be no concerns
> using with OpenJDK 8 or other versions for that matter.  If you mean the
> jdk8u project specifically, you should check with the current
> maintainers for interest in this as I think they currently use other
> means for their builds.

Thank you for responding. So I'll check with the jdk8u project whether there's interest in this.

Best regards
Christoph


From weijun.wang at oracle.com  Mon Mar 25 02:42:10 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 25 Mar 2019 10:42:10 +0800
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
 SequenceInputStream
In-Reply-To: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com>
References: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com>
Message-ID: <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com>

Ping again.

No new test added.

Thanks,
Max

> On Mar 5, 2019, at 11:06 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please take a review at
> 
>   https://cr.openjdk.java.net/~weijun/8157404/webrev.00/
> 
> When Java finds out data is not enough while resolving a BER, it reads in more data and try converting again. Please note that calling available() again after readNBytes is not reliable because it might return zero even if there are more bytes.
> 
> A more efficient fix could be rewriting the convert logic to use the stream directly (parsing while reading), and thus avoid the need to call the whole convertBytes method again, but that's a big change and there is a risk getting wrong somewhere. This fix is likely to be backported to older LTS releases.
> 
> Note this could block but it should only happen when data is not enough, and it only reads one byte. 
> 
> The test included in the bug report passed, but I'll see if I can write a new test not depending on any existing binary data.
> 
> And I'm running a mach5 test job now.
> 
> Thanks,
> Max
> 


From Nico.Williams at twosigma.com  Mon Mar 25 02:52:49 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 25 Mar 2019 02:52:49 +0000
Subject: Obsolete and remove JAAS please (was Re: RFR 6722928: Support
 SSPI as a native GSS-API provider)
In-Reply-To: <34888131-7779-c7fe-57f5-9543e52399ea@gmx.net>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
 <20190322194346.GI9177@twosigma.com>
 <34888131-7779-c7fe-57f5-9543e52399ea@gmx.net>
Message-ID: <20190325025249.GJ9177@twosigma.com>

On Sat, Mar 23, 2019 at 01:07:45AM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 20:43 schrieb Nico Williams:
> > All LoginModule functionality that is used to acquire credentials should
> > be made available outside JAAS.  E.g., JGSS could use kinit-style
> > functionality (acquireCredWithPassword() and so on).  "Could use", not
> > "needs", because external use of kinit and KRB5* env vars works for 97%
> > of cases, though being able to cover 100% is nice, and since I've done a
> > lot of the necessary work (acquireCredWithPassword()), might as well do
> > the rest (i.e., add acquireCredFrom()).
> 
> acquireCredFrom() is a must have for multi-tenancy and services. Think of
> TLS virtual hosting with one keytab per host on a Tomcat.

I'm talking about multi-tenancy where you need isolation.

If you mereley want multiple hostnames (and to dispatch on them), then
on the server side you can always just check what name the initiator
called the acceptor by, and that's good enough.  (You have to put all
the relevant keys in the same keytab.)

If you need isolation, then you need acquireCredFrom() and an access
control mechanism.

> > It sure feels like a lot of JAAS+JGSS apps use JAAS only for cargo cult
> > reasons (i.e., devs copy-pasting what [appears to] works for others), or
> > else because the developers don't know how to use kinit externally.
> > 
> > The Krb5 stack appears to be practically abandoned and far behind all
> > other Kerberos implementations.  With our JGSS contributions (and Max's
> > SSPI bridge) there is also the opportunity to remove the Krb5 stack,
> > which would lighten the development and maintenance burden on Oracle
> > engineers, freeing up cycles for other, more interesting work.
> 
> That is true, but it would require to have a very good coverage via SSPI or
> MIT Kerberos on all platforms where Java runs, not just those Oracle
> officially supports. I do use the same code one four operating systems with
> Java.

We use the Martin Rex's gsskrb5 GSS->SSPI bridge, with our own patches
to it (mostly to remove code).  This has a license that has an
advertising clause, which is probably the only reason Oracle wouldn't
accept it.

You can find our fork here: https://github.com/twosigma/gsskrb5

It's missing channel binding support, and, of course, doesn't have some
of the newer extensions, but it does work.

One or both of Heimdal and MIT Kerberos work on all platforms that Java
does, no?  Though on Windows one really wants a GSS->SSPI bridge, even
though Heimdal and MIT have some support for using the LSA as a
credential store.

Nico
-- 

From Nico.Williams at twosigma.com  Mon Mar 25 02:56:48 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 25 Mar 2019 02:56:48 +0000
Subject: was Re: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <6ee577f9-3915-dcf9-4a01-3e57c151d6fa@gmx.net>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <39ff5ae4-033d-3ee6-d1ae-ae7b4b7196a4@gmx.net>
 <20190322192906.GH9177@twosigma.com>
 <6ee577f9-3915-dcf9-4a01-3e57c151d6fa@gmx.net>
Message-ID: <20190325025648.GK9177@twosigma.com>

On Sat, Mar 23, 2019 at 01:03:17AM +0100, Michael Osipov wrote:
> Am 2019-03-22 um 20:29 schrieb Nico Williams:
> > Our contributions add acquireCredWithPassword() methods.
> > 
> > And we could add acquireCredFrom() to match gss_acquire_cred_from() /
> > gss_add_cred_from() (a Heimdal and MIT innovation that allows, among
> > other things, to use a specific keytab).
> 
> Based on this:
> https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/gssapi_ext.h
> 
> That would be awesome. We have several use cases for keytabs:
> 
> 1) traditional one, machine account with SPNs (acceptor, sometimes
> initiator)
> 2) service account (initiator)
> 3) service account with SPNs (both)
> 
> That would make JAAS and the Krb5LoginModule completely obsolete.

Yes, that's the idea.

> > But also, most JGSS users don't need the JDK to have this functionality
> > since using kinit externally and KRB5* env vars works perfectly fine for
> > the vast majority of cases.
> 
> I see several cases not covered if MIT Kerberos is used:
> 
> 1)
> # export KRB5_CLIENT_KTNAME=/etc/krb5.keytab
> # curl --negotiate -u : ...do magic...
> 
> will simply not work with a keytab created by Samba because the machine
> UPN is not the first entry of the table. One would require
> KRB5_CLIENT_PRINCIPAL for that. It would cover gss_acquire_cred_from()
> with the gss_name_t.

You can set KRB5_CLIENT_KTNAME to deal with that.

> 2) non-file based ccaches cannot be accessed by Java ATM (e.g., keyring).

If you're using the JGSS native C JNI interface and MIT Kerberos (or the
upcoming Heimdal 8.0), then you can use the Linux kernel keyring.

> 3) serialization of credentials to disk for futher usage (e.g.,
> credetial delegation)

This definitely requires JGSS bindings for gss_store_cred() and
gss_store_cred_into().

> 4) Consider you use MIT Kerberos via JGSS and receive a delegated
> credential via HTTP, you store that in the request (no session). There
> is no Servlet API callback that the request has been disposed, you
> cannot call GSSCredential#dispose(). It will or may lead to a memory
> leak. I don't know whether the GC will handle this. Frankly, I need to
> check mod_auth_gssapi how they solve that because that memory does not
> come from apr_pool_t.

At least our patches do let you dispose of it.

> But I really would like to see
> https://secure-web.cisco.com/1QDhZ_p9aOLNhO8eSoC7nft6Vay_RWeIFcEMzgJqDQfx-5XV1-ueeUw9GWNtzl_Hsj8Qqmlg9P3VX-LqydOZN2u2bqSJMC7w5TOPYv48kYSl5USixBe75-RKm9cgK2ZDYK2mqkX4b83Tud3TUffwL5SRkf-mpbHvE6YC5nANzW1Lwx0NB9AIsP2FhqBe9fp1KYXdYbknF2prfVcXKpUu81nnWnwfRhXr1Ror2TF75RRZbs-ON27jRx7Cm7LoxLmNJgDCi-AaB41hmGV9KUJKkEQ/https%3A%2F%2Fk5wiki.kerberos.org%2Fwiki%2FProjects%2FCredential_Store_extensions
> coming.

Yes.

Direct link:

https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions

Nico
-- 

From Nico.Williams at twosigma.com  Mon Mar 25 02:58:03 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 25 Mar 2019 02:58:03 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <CANghgrTP9FfK_YhjzhPdiNEmNrTWMX=BAucuX_OWPT2P=MO1bA@mail.gmail.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <CANghgrTP9FfK_YhjzhPdiNEmNrTWMX=BAucuX_OWPT2P=MO1bA@mail.gmail.com>
Message-ID: <20190325025803.GL9177@twosigma.com>

On Sat, Mar 23, 2019 at 10:45:34AM -0500, David Lloyd wrote:
> On Fri, Mar 22, 2019 at 10:29 AM Nico Williams
> <Nico.Williams at twosigma.com> wrote:
> >
> > On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
> > > * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
> > > it is intended to work. Means less code you have to maintain
> >
> > There's a few reasons:
> >
> >  - NTLM doesn't have an OID, at least as I remember
> >
> >  - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
> >    to the ServicePermission stuff
> >
> > IMO JAAS (and with it, *Permission) should be removed with prejudice now
> > that applet support has been removed.  Perhaps stubs should be left
> > behind for compatibility reasons, and all the doAs*() methods should
> > just act as though permission is granted.
> 
> I assume that you mean SecurityManager and AccessController as well
> (which are not a part of JAAS AFAIK)?

Anything that's only used for applets.

From weijun.wang at oracle.com  Mon Mar 25 03:17:17 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 25 Mar 2019 11:17:17 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <aa68622e-995a-93cf-bb81-8cbc1c5c4c10@gmx.net>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>
 <aa68622e-995a-93cf-bb81-8cbc1c5c4c10@gmx.net>
Message-ID: <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com>



> On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> 
> Am 2019-03-23 um 00:21 schrieb Weijun Wang:
>> 
>> 
>>> On Mar 22, 2019, at 11:28 PM, Nico Williams <Nico.Williams at twosigma.com> wrote:
>>> 
>>> On Thu, Mar 21, 2019 at 10:17:36PM +0100, Michael Osipov wrote:
>>>> * header comment: Why do actually exclude NTLM from SPNEGO? Let SSPI work as
>>>> it is intended to work. Means less code you have to maintain
>>> 
>>> There's a few reasons:
>>> 
>>> - NTLM doesn't have an OID, at least as I remember
>>> 
>>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/ regards
>>>   to the ServicePermission stuff
>> 
>> Yes, it needs to check a permission if the token is SPNEGO and internally it's Kerberos. I also believe the HTTP Negotiate code there is probably not good at dealing with a Negotiate dialog with 2 rounds. The first problem should be easy to fix, I'll see if the 2nd is complicated.

It works. Java's (old) HTTPConnection sends an NTLM token to IIS and after 4 messages I see 200 OK.

But 1) Java GSS acceptor does not accept it and I don't want to break interop inside Java. 2) No more permission check.

Not going to do it this time. Later I might ask networking how transparent NTLM works and if they needs any permission checking or other settings I can probably follow.

I'll work on other comments from you.

--Max

> 
> Reminds me of https://issues.apache.org/jira/browse/HTTPCLIENT-1625...




From thomas.stuefe at gmail.com  Mon Mar 25 07:01:08 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 08:01:08 +0100
Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
Message-ID: <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>

Hi David,

(added net-dev, awt-dev, security-dev since part of these fixes are in
their territory)

On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> A few queries, comments and concerns ...
>
> On 25/03/2019 6:58 am, Thomas St?fe wrote:
> > Hi all,
> >
> > After a long time I tried to build a Windows 32bit VM (VS2017) and
> failed;
>
> I'm somewhat surprised as I thought someone was actively doing Windows
> 32-bit builds out there, plus there are shared code changes that should
> also have been caught by non-Windows 32-bit builds. :(
>
>
Not sure what others do. I did a 32bit windows build, slowdebug, warning
enabled, and it failed with those 5+ issues.


> > multiple errors and warnings. Lets reverse the bitrot:
> >
> > cr:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
> >
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
> >
> > Most of the fixes are trivial: Calling convention mismatches (awt DTRACE
> > callbacks), printf specifiers etc.
> >
> > Had to supress a warning in os_windows_x86.cpp - I was surprised by this
> > since this did not look 32bit specifc, do we disable warnings on Windows
> > 64bit builds?
>
> What version of VS2017? We use VS2017 15.9.6 and we don't disable warnings.
>
>
I use VS2017 CE. Not sure which version spcifically, but my compiler is at

Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86


> > The error I had in vmStructs.cpp was a bit weird: compiler complained
> about
> > an assignment of an enum value defined like this:
> >
> > hash_mask_in_place       = (address_word)hash_mask << hash_shift
> >
> > to an uint64_t variable, complaining about narrowing. I did not find out
> > what his problem was. In the end, I decided to add an explicit cast to
> > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
>
> Not at all sure that's the right fix. In markOop.hpp we see that value
> gets special treatment on Windows-x64:
>

> #ifndef _WIN64
>           ,hash_mask               = right_n_bits(hash_bits),
>           hash_mask_in_place       = (address_word)hash_mask << hash_shift
> #endif
>    };
>
>    // Alignment of JavaThread pointers encoded in object header required
> by biased locking
>    enum { biased_lock_alignment    = 2 << (epoch_shift + epoch_bits)
>    };
>
> #ifdef _WIN64
>      // These values are too big for Win64
>      const static uintptr_t hash_mask = right_n_bits(hash_bits);
>      const static uintptr_t hash_mask_in_place  =
>                              (address_word)hash_mask << hash_shift;
> #endif
>
> perhaps something special is needed for Windows-x86. I'm unclear how the
> values can be "too big" ??
>
>
I banged my head against this for an hour or so and I think this is a
compiler bug.

What I get is:

warning C4838: conversion from '' to 'uint64_t' requires a narrowing
conversion

(Note the empty "from" string.)

Here are my tries to provoke the error:

VMLongConstantEntry iii[] = {  { "hallo", markOopDesc::hash_mask_in_place
}, {0,0}};  <<< this fails
VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };
 << but this succeeds
uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too

I have no clue what this means. It is difficult to fix since the expression
is hidden in such a macro pile. But I think either we go with my change or
we disable the warning for win32 for the whole section.


> >
> > With this patch we can build with warnings enabled on 32bit and 64bit
> > windows.
> >
> > Since patch fixes both hotspot and JDK parts, I'm sending it to hs-dev
> and
> > core-libs-dev.
>
> Don't see anything that actually comes under core-libs-dev. Looks like
> one net-dev, one awt-dev and one security-dev. Sorry.
>
>
Okay, I will add them.


> Cheers,
> David
> -----
>
>
Thanks for reviewing,

Thomas


> > Thanks, Thomas
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190325/19c5a7c1/attachment.html>

From david.holmes at oracle.com  Mon Mar 25 07:17:05 2019
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 25 Mar 2019 17:17:05 +1000
Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
Message-ID: <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>

Hi Thomas,

On 25/03/2019 5:01 pm, Thomas St?fe wrote:
> Hi David,
> 
> (added net-dev, awt-dev, security-dev since part of these fixes are in 
> their territory)

May be better to split up the reviews, cross-posting that many groups 
gets very messy given most people won't be subscribed to them all - 
myself included.

> On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     A few queries, comments and concerns ...
> 
>     On 25/03/2019 6:58 am, Thomas St?fe wrote:
>      > Hi all,
>      >
>      > After a long time I tried to build a Windows 32bit VM (VS2017)
>     and failed;
> 
>     I'm somewhat surprised as I thought someone was actively doing Windows
>     32-bit builds out there, plus there are shared code changes that should
>     also have been caught by non-Windows 32-bit builds. :(
> 
> 
> Not sure what others?do. I did a 32bit windows build, slowdebug, warning 
> enabled, and it failed with those 5+ issues.
> 
>      > multiple errors and warnings. Lets reverse the bitrot:
>      >
>      > cr:
>      >
>     http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>      >
>      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>      >
>      > Most of the fixes are trivial: Calling convention mismatches (awt
>     DTRACE
>      > callbacks), printf specifiers etc.
>      >
>      > Had to supress a warning in os_windows_x86.cpp - I was surprised
>     by this
>      > since this did not look 32bit specifc, do we disable warnings on
>     Windows
>      > 64bit builds?
> 
>     What version of VS2017? We use VS2017 15.9.6 and we don't disable
>     warnings.
> 
> 
> I use VS2017 CE. Not sure which version spcifically, but my compiler is at
> 
> Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86

I think that would equate to an older version - 15.7

MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)

Any chance you can upgrade to latest version? (Especially in light of 
the apparent compiler bug you cite below.)

Thanks,
David
-----

>      > The error I had in vmStructs.cpp was a bit weird: compiler
>     complained about
>      > an assignment of an enum value defined like this:
>      >
>      > hash_mask_in_place? ? ? ?= (address_word)hash_mask << hash_shift
>      >
>      > to an uint64_t variable, complaining about narrowing. I did not
>     find out
>      > what his problem was. In the end, I decided to add an explicit
>     cast to
>      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
> 
>     Not at all sure that's the right fix. In markOop.hpp we see that value
>     gets special treatment on Windows-x64:
> 
> 
>     #ifndef _WIN64
>      ? ? ? ? ? ,hash_mask? ? ? ? ? ? ? ?= right_n_bits(hash_bits),
>      ? ? ? ? ? hash_mask_in_place? ? ? ?= (address_word)hash_mask <<
>     hash_shift
>     #endif
>      ? ?};
> 
>      ? ?// Alignment of JavaThread pointers encoded in object header
>     required
>     by biased locking
>      ? ?enum { biased_lock_alignment? ? = 2 << (epoch_shift + epoch_bits)
>      ? ?};
> 
>     #ifdef _WIN64
>      ? ? ?// These values are too big for Win64
>      ? ? ?const static uintptr_t hash_mask = right_n_bits(hash_bits);
>      ? ? ?const static uintptr_t hash_mask_in_place? =
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(address_word)hash_mask << hash_shift;
>     #endif
> 
>     perhaps something special is needed for Windows-x86. I'm unclear how
>     the
>     values can be "too big" ??
> 
> 
> I banged my head against this for an hour or so and I think this is a 
> compiler bug.
> 
> What I get is:
> 
> warning C4838: conversion from '' to 'uint64_t' requires a narrowing 
> conversion
> 
> (Note the empty "from" string.)
> 
> Here are my tries to provoke the error:
> 
> VMLongConstantEntry iii[] = {? { "hallo", 
> markOopDesc::hash_mask_in_place }, {0,0}};? <<< this fails
> VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };  
>  ?<< but this succeeds
> uint64_t iii = markOopDesc::hash_mask_in_place;? ?<< this succeeds? too
> 
> I have no clue what this means. It is difficult to fix since the 
> expression is hidden in such a macro pile. But I think either we go with 
> my change or we disable the warning for win32 for the whole section.
> 
>      >
>      > With this patch we can build with warnings enabled on 32bit and 64bit
>      > windows.
>      >
>      > Since patch fixes both hotspot and JDK parts, I'm sending it to
>     hs-dev and
>      > core-libs-dev.
> 
>     Don't see anything that actually comes under core-libs-dev. Looks like
>     one net-dev, one awt-dev and one security-dev. Sorry.
> 
> 
> Okay, I will add them.
> 
>     Cheers,
>     David
>     -----
> 
> 
> Thanks for reviewing,
> 
> Thomas
> 
>      > Thanks, Thomas
>      >
> 

From christoph.langer at sap.com  Mon Mar 25 07:22:34 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 25 Mar 2019 07:22:34 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <CAP7YuASAo78NL3p-kwMDT7sH7oTHufqMEXSQ75HbmsBTDPQ_Fw@mail.gmail.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
 <CAP7YuASAo78NL3p-kwMDT7sH7oTHufqMEXSQ75HbmsBTDPQ_Fw@mail.gmail.com>
Message-ID: <HE1PR0201MB2266E612E73C33F39B1057438A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Martijn,

as far as I understand the AdoptOpenJDK infrastructure, you have created a cacerts file from the Mozilla certificates which you are using in the AdoptOpenJDK 8 build via configure option [1]. Is that correct or am I missing something?

I was planning to bring the cacerts file from jdk/jdk down to 8 with the associated tests. Your build setup should still work then, I guess.

However, if somebody from AdoptOpenJDK wants to do the work of bringing it into OpenJDK8 updates, feel free. It?s not the very first thing on my todo list ??

Thanks & Best regards
Christoph

[1] https://github.com/AdoptOpenJDK/openjdk-build/tree/master/security


From: Martijn Verburg <martijnverburg at gmail.com>
Sent: Freitag, 22. M?rz 2019 20:38
To: Sean Mullan <sean.mullan at oracle.com>
Cc: Langer, Christoph <christoph.langer at sap.com>; jdk8u-dev at openjdk.java.net; OpenJDK Dev list <security-dev at openjdk.java.net>
Subject: Re: [8u] Is it possible to bring root certificates to OpenJDK 8 [JEP319] ?

FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide a patch to upstream that change.

Cheers,
Martijn


On Fri, 22 Mar 2019 at 19:35, Sean Mullan <sean.mullan at oracle.com<mailto:sean.mullan at oracle.com>> wrote:
Hi Christoph,

On 3/21/19 6:20 AM, Langer, Christoph wrote:
> Hi,
>
> I recently came across a scenario where I wanted to use a self-built OpenJDK 8 in a maven build and it could not download artefacts due to missing root certificates. I helped myself by replacing the cacerts with some other version from a later OpenJDK and came over the issue. However, I?ve asked myself whether it was possible/worthwhile to get the root certificates also into an OpenJDK 8 update?
>
> With JEP 319 [0], Oracle has open-sourced the root certificates into OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1]. After that, several commits have been made to update the set of root certificates and improve the tests.
>
> Now my questions are: Is it legally possible to bring these root certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be added to OpenJDK 8 via an update release? And, last but not least, would there be interest in the community for that at all?

I can answer the first two questions. I talked to one of our Product
Managers who was involved with this JEP and he said that we have
permission to release these certificates as open source at OpenJDK (much
as Mozilla has roots in Firefox).  Therefore there should be no concerns
using with OpenJDK 8 or other versions for that matter.  If you mean the
jdk8u project specifically, you should check with the current
maintainers for interest in this as I think they currently use other
means for their builds.

--Sean

>
> Just trying to start a discussion? ??
>
> Best regards
> Christoph
>
> [0] http://openjdk.java.net/jeps/319
> [1] https://bugs.openjdk.java.net/browse/JDK-8189131
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190325/627f5c6d/attachment-0001.html>

From thomas.stuefe at gmail.com  Mon Mar 25 12:44:21 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 13:44:21 +0100
Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
Message-ID: <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>

Hi David,

Updating vs2017 did not help :/

Cheers, Thomas

On Mon, Mar 25, 2019 at 8:17 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Thomas,
>
> On 25/03/2019 5:01 pm, Thomas St?fe wrote:
> > Hi David,
> >
> > (added net-dev, awt-dev, security-dev since part of these fixes are in
> > their territory)
>
> May be better to split up the reviews, cross-posting that many groups
> gets very messy given most people won't be subscribed to them all -
> myself included.
>


>
> > On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> wrote:
> >
> >     Hi Thomas,
> >
> >     A few queries, comments and concerns ...
> >
> >     On 25/03/2019 6:58 am, Thomas St?fe wrote:
> >      > Hi all,
> >      >
> >      > After a long time I tried to build a Windows 32bit VM (VS2017)
> >     and failed;
> >
> >     I'm somewhat surprised as I thought someone was actively doing
> Windows
> >     32-bit builds out there, plus there are shared code changes that
> should
> >     also have been caught by non-Windows 32-bit builds. :(
> >
> >
> > Not sure what others do. I did a 32bit windows build, slowdebug, warning
> > enabled, and it failed with those 5+ issues.
> >
> >      > multiple errors and warnings. Lets reverse the bitrot:
> >      >
> >      > cr:
> >      >
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
> >      >
> >      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
> >      >
> >      > Most of the fixes are trivial: Calling convention mismatches (awt
> >     DTRACE
> >      > callbacks), printf specifiers etc.
> >      >
> >      > Had to supress a warning in os_windows_x86.cpp - I was surprised
> >     by this
> >      > since this did not look 32bit specifc, do we disable warnings on
> >     Windows
> >      > 64bit builds?
> >
> >     What version of VS2017? We use VS2017 15.9.6 and we don't disable
> >     warnings.
> >
> >
> > I use VS2017 CE. Not sure which version spcifically, but my compiler is
> at
> >
> > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86
>
> I think that would equate to an older version - 15.7
>
> MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>
> Any chance you can upgrade to latest version? (Especially in light of
> the apparent compiler bug you cite below.)
>
> Thanks,
> David
> -----
>
> >      > The error I had in vmStructs.cpp was a bit weird: compiler
> >     complained about
> >      > an assignment of an enum value defined like this:
> >      >
> >      > hash_mask_in_place       = (address_word)hash_mask << hash_shift
> >      >
> >      > to an uint64_t variable, complaining about narrowing. I did not
> >     find out
> >      > what his problem was. In the end, I decided to add an explicit
> >     cast to
> >      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
> >
> >     Not at all sure that's the right fix. In markOop.hpp we see that
> value
> >     gets special treatment on Windows-x64:
> >
> >
> >     #ifndef _WIN64
> >                ,hash_mask               = right_n_bits(hash_bits),
> >                hash_mask_in_place       = (address_word)hash_mask <<
> >     hash_shift
> >     #endif
> >         };
> >
> >         // Alignment of JavaThread pointers encoded in object header
> >     required
> >     by biased locking
> >         enum { biased_lock_alignment    = 2 << (epoch_shift + epoch_bits)
> >         };
> >
> >     #ifdef _WIN64
> >           // These values are too big for Win64
> >           const static uintptr_t hash_mask = right_n_bits(hash_bits);
> >           const static uintptr_t hash_mask_in_place  =
> >                                   (address_word)hash_mask << hash_shift;
> >     #endif
> >
> >     perhaps something special is needed for Windows-x86. I'm unclear how
> >     the
> >     values can be "too big" ??
> >
> >
> > I banged my head against this for an hour or so and I think this is a
> > compiler bug.
> >
> > What I get is:
> >
> > warning C4838: conversion from '' to 'uint64_t' requires a narrowing
> > conversion
> >
> > (Note the empty "from" string.)
> >
> > Here are my tries to provoke the error:
> >
> > VMLongConstantEntry iii[] = {  { "hallo",
> > markOopDesc::hash_mask_in_place }, {0,0}};  <<< this fails
> > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place };
> >   << but this succeeds
> > uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too
> >
> > I have no clue what this means. It is difficult to fix since the
> > expression is hidden in such a macro pile. But I think either we go with
> > my change or we disable the warning for win32 for the whole section.
> >
> >      >
> >      > With this patch we can build with warnings enabled on 32bit and
> 64bit
> >      > windows.
> >      >
> >      > Since patch fixes both hotspot and JDK parts, I'm sending it to
> >     hs-dev and
> >      > core-libs-dev.
> >
> >     Don't see anything that actually comes under core-libs-dev. Looks
> like
> >     one net-dev, one awt-dev and one security-dev. Sorry.
> >
> >
> > Okay, I will add them.
> >
> >     Cheers,
> >     David
> >     -----
> >
> >
> > Thanks for reviewing,
> >
> > Thomas
> >
> >      > Thanks, Thomas
> >      >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190325/b23f0f6d/attachment.html>

From thomas.stuefe at gmail.com  Mon Mar 25 12:45:21 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 13:45:21 +0100
Subject: RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
 <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
Message-ID: <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>

Hi all,

Following David's suggestion, I withdraw this bug and will open issues for
each area separately.

Cheers, Thomas



On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi David,
>
> Updating vs2017 did not help :/
>
> Cheers, Thomas
>
> On Mon, Mar 25, 2019 at 8:17 AM David Holmes <david.holmes at oracle.com>
> wrote:
>
>> Hi Thomas,
>>
>> On 25/03/2019 5:01 pm, Thomas St?fe wrote:
>> > Hi David,
>> >
>> > (added net-dev, awt-dev, security-dev since part of these fixes are in
>> > their territory)
>>
>> May be better to split up the reviews, cross-posting that many groups
>> gets very messy given most people won't be subscribed to them all -
>> myself included.
>>
>
>
>>
>> > On Mon, Mar 25, 2019 at 1:34 AM David Holmes <david.holmes at oracle.com
>> > <mailto:david.holmes at oracle.com>> wrote:
>> >
>> >     Hi Thomas,
>> >
>> >     A few queries, comments and concerns ...
>> >
>> >     On 25/03/2019 6:58 am, Thomas St?fe wrote:
>> >      > Hi all,
>> >      >
>> >      > After a long time I tried to build a Windows 32bit VM (VS2017)
>> >     and failed;
>> >
>> >     I'm somewhat surprised as I thought someone was actively doing
>> Windows
>> >     32-bit builds out there, plus there are shared code changes that
>> should
>> >     also have been caught by non-Windows 32-bit builds. :(
>> >
>> >
>> > Not sure what others do. I did a 32bit windows build, slowdebug,
>> warning
>> > enabled, and it failed with those 5+ issues.
>> >
>> >      > multiple errors and warnings. Lets reverse the bitrot:
>> >      >
>> >      > cr:
>> >      >
>> >
>> http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>> >      >
>> >      > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>> >      >
>> >      > Most of the fixes are trivial: Calling convention mismatches (awt
>> >     DTRACE
>> >      > callbacks), printf specifiers etc.
>> >      >
>> >      > Had to supress a warning in os_windows_x86.cpp - I was surprised
>> >     by this
>> >      > since this did not look 32bit specifc, do we disable warnings on
>> >     Windows
>> >      > 64bit builds?
>> >
>> >     What version of VS2017? We use VS2017 15.9.6 and we don't disable
>> >     warnings.
>> >
>> >
>> > I use VS2017 CE. Not sure which version spcifically, but my compiler is
>> at
>> >
>> > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431 for x86
>>
>> I think that would equate to an older version - 15.7
>>
>> MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>>
>> Any chance you can upgrade to latest version? (Especially in light of
>> the apparent compiler bug you cite below.)
>>
>> Thanks,
>> David
>> -----
>>
>> >      > The error I had in vmStructs.cpp was a bit weird: compiler
>> >     complained about
>> >      > an assignment of an enum value defined like this:
>> >      >
>> >      > hash_mask_in_place       = (address_word)hash_mask << hash_shift
>> >      >
>> >      > to an uint64_t variable, complaining about narrowing. I did not
>> >     find out
>> >      > what his problem was. In the end, I decided to add an explicit
>> >     cast to
>> >      > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see vmStructs.hpp).
>> >
>> >     Not at all sure that's the right fix. In markOop.hpp we see that
>> value
>> >     gets special treatment on Windows-x64:
>> >
>> >
>> >     #ifndef _WIN64
>> >                ,hash_mask               = right_n_bits(hash_bits),
>> >                hash_mask_in_place       = (address_word)hash_mask <<
>> >     hash_shift
>> >     #endif
>> >         };
>> >
>> >         // Alignment of JavaThread pointers encoded in object header
>> >     required
>> >     by biased locking
>> >         enum { biased_lock_alignment    = 2 << (epoch_shift +
>> epoch_bits)
>> >         };
>> >
>> >     #ifdef _WIN64
>> >           // These values are too big for Win64
>> >           const static uintptr_t hash_mask = right_n_bits(hash_bits);
>> >           const static uintptr_t hash_mask_in_place  =
>> >                                   (address_word)hash_mask << hash_shift;
>> >     #endif
>> >
>> >     perhaps something special is needed for Windows-x86. I'm unclear how
>> >     the
>> >     values can be "too big" ??
>> >
>> >
>> > I banged my head against this for an hour or so and I think this is a
>> > compiler bug.
>> >
>> > What I get is:
>> >
>> > warning C4838: conversion from '' to 'uint64_t' requires a narrowing
>> > conversion
>> >
>> > (Note the empty "from" string.)
>> >
>> > Here are my tries to provoke the error:
>> >
>> > VMLongConstantEntry iii[] = {  { "hallo",
>> > markOopDesc::hash_mask_in_place }, {0,0}};  <<< this fails
>> > VMLongConstantEntry iii = { "hallo", markOopDesc::hash_mask_in_place
>> };
>> >   << but this succeeds
>> > uint64_t iii = markOopDesc::hash_mask_in_place;   << this succeeds  too
>> >
>> > I have no clue what this means. It is difficult to fix since the
>> > expression is hidden in such a macro pile. But I think either we go
>> with
>> > my change or we disable the warning for win32 for the whole section.
>> >
>> >      >
>> >      > With this patch we can build with warnings enabled on 32bit and
>> 64bit
>> >      > windows.
>> >      >
>> >      > Since patch fixes both hotspot and JDK parts, I'm sending it to
>> >     hs-dev and
>> >      > core-libs-dev.
>> >
>> >     Don't see anything that actually comes under core-libs-dev. Looks
>> like
>> >     one net-dev, one awt-dev and one security-dev. Sorry.
>> >
>> >
>> > Okay, I will add them.
>> >
>> >     Cheers,
>> >     David
>> >     -----
>> >
>> >
>> > Thanks for reviewing,
>> >
>> > Thomas
>> >
>> >      > Thanks, Thomas
>> >      >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190325/c6690e25/attachment-0001.html>

From thomas.stuefe at gmail.com  Mon Mar 25 13:12:49 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 25 Mar 2019 14:12:49 +0100
Subject: RFR(xxs): 8221407: Windows 32bit build error in
 libsunmscapi/security.cpp
Message-ID: <CAA-vtUy3DRRRSvsAY45EASr_51cEfJC8uN+96i10R9-t4-Quow@mail.gmail.com>

Hi all,

please review this tiny fix to the windows 32 build:

issue: https://bugs.openjdk.java.net/browse/JDK-8221407
cr:
http://cr.openjdk.java.net/~stuefe/webrevs/8221407-windows32-buildfixes-libsunmscapi/webrev.00/webrev/

Just a bunch of obvious fixes for cases where a jlong was handed into
system APIs requiring HANDLEs, which are pointer sized.

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190325/181394f3/attachment.html>

From Nico.Williams at twosigma.com  Mon Mar 25 15:37:41 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 25 Mar 2019 15:37:41 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>
 <aa68622e-995a-93cf-bb81-8cbc1c5c4c10@gmx.net>
 <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com>
Message-ID: <20190325153741.GM9177@twosigma.com>

On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote:
> > On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> >>> There's a few reasons:
> >>> 
> >>> - NTLM doesn't have an OID, at least as I remember
> >>> 
> >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/
> >>>   regards to the ServicePermission stuff
> >> 
> >> Yes, it needs to check a permission if the token is SPNEGO and
> >> internally it's Kerberos. I also believe the HTTP Negotiate code
> >> there is probably not good at dealing with a Negotiate dialog with
> >> 2 rounds. The first problem should be easy to fix, I'll see if the
> >> 2nd is complicated.

I expect lots of implementations of HTTP/Negotiate to not support more
than one round trip.  However, if a client and server lack credentials
for a common mechanism, authentication will fail or not even start, and
if they do have credentials for a common mechanism but one or both
cannot handle more than one round trip, they'll fail.  Either way they
fail, so what's the problem?  Ignoring for a moment NTLM's weakness,
adding support for it adds ways to win, not ways to fail.

> It works. Java's (old) HTTPConnection sends an NTLM token to IIS and
> after 4 messages I see 200 OK.
> 
> But 1) Java GSS acceptor does not accept it and I don't want to break
> interop inside Java.

That's not breaking interop.  A Windows initiator and non-Windows
acceptor (and vice-versa) will still interop provided both have Kerberos
credentials.

> 2) No more permission check.

I don't understand (2).

> Not going to do it this time. Later I might ask networking how
> transparent NTLM works and if they needs any permission checking or
> other settings I can probably follow.

Of course it needs permission checking, except that in a world without
applets that's a bit pointless.

Nico
-- 

From ecki at zusammenkunft.net  Mon Mar 25 19:45:07 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 25 Mar 2019 19:45:07 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190325153741.GM9177@twosigma.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>
 <aa68622e-995a-93cf-bb81-8cbc1c5c4c10@gmx.net>
 <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com>,
 <20190325153741.GM9177@twosigma.com>
Message-ID: <DB7PR08MB3307BE0A3BDD7579033B077AFF5E0@DB7PR08MB3307.eurprd08.prod.outlook.com>

Just to add another aspect to the discussion, there are at least 3 DLLs out there which implement this functionality (Microsoft?s JDBC driver, jTDS driver and Waffle) + commercial solutions as we have heared. All of them are used to allow authenticating the current user against services (mostly TDS (SQL Server), SMB and http.

So having a GSS provider, even when it is not used by default would hugely benefit a lot of projects (especially if it does not require JAAS wrapping and will support Windows 10 with Credential Guard for NTLM and Kerberos)

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: security-dev <security-dev-bounces at openjdk.java.net> im Auftrag von Nico Williams <nico.williams at twosigma.com>
Gesendet: Montag, M?rz 25, 2019 6:38 PM
An: Weijun Wang
Cc: security-dev at openjdk.java.net
Betreff: Re: RFR 6722928: Support SSPI as a native GSS-API provider

On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote:
> > On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> >>> There's a few reasons:
> >>>
> >>> - NTLM doesn't have an OID, at least as I remember
> >>>
> >>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/
> >>> regards to the ServicePermission stuff
> >>
> >> Yes, it needs to check a permission if the token is SPNEGO and
> >> internally it's Kerberos. I also believe the HTTP Negotiate code
> >> there is probably not good at dealing with a Negotiate dialog with
> >> 2 rounds. The first problem should be easy to fix, I'll see if the
> >> 2nd is complicated.

I expect lots of implementations of HTTP/Negotiate to not support more
than one round trip. However, if a client and server lack credentials
for a common mechanism, authentication will fail or not even start, and
if they do have credentials for a common mechanism but one or both
cannot handle more than one round trip, they'll fail. Either way they
fail, so what's the problem? Ignoring for a moment NTLM's weakness,
adding support for it adds ways to win, not ways to fail.

> It works. Java's (old) HTTPConnection sends an NTLM token to IIS and
> after 4 messages I see 200 OK.
>
> But 1) Java GSS acceptor does not accept it and I don't want to break
> interop inside Java.

That's not breaking interop. A Windows initiator and non-Windows
acceptor (and vice-versa) will still interop provided both have Kerberos
credentials.

> 2) No more permission check.

I don't understand (2).

> Not going to do it this time. Later I might ask networking how
> transparent NTLM works and if they needs any permission checking or
> other settings I can probably follow.

Of course it needs permission checking, except that in a world without
applets that's a bit pointless.

Nico
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190325/3d7c9c0a/attachment.html>

From valerie.peng at oracle.com  Mon Mar 25 20:58:23 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 25 Mar 2019 13:58:23 -0700
Subject: [13] RFR JDK-8216039 "TLS with BC and RSASSA-PSS breaks
 ECDHServerKeyExchange"
Message-ID: <483ac341-4260-ea59-4d14-9f5f0643f98f@oracle.com>


Based on the earlier internal discussion, here is a "backportable" fix 
for JDK-8216039 "TLS with BC and RSASSA-PSS breaks 
ECDHServerKeyExchange" which does not bear any public API change. 
Existing JDK codes which uses PSS signature with parameters will call 
the new internal JDK APIs which select the provider based on both key 
and parameters. There is no provider-specific checking and it 
accommodate the usage of the BouncyCastle FIPS provider for TLS and 
other applications.

Default implementations of the new methods are provided, so existing JDK 
crypto providers should continue to work without change. The default 
impl also set the parameters before calling init() to avoid trigger the 
known PSS behavior/issue in BC FIPS provider which leads to signature 
interoperabilities.

As for making the JDK internal APIs public, I plan to file a separate 
bug (and CCC) later if this approach is acceptable.

Bug: https://bugs.openjdk.java.net/browse/JDK-8216039
Webrev: http://cr.openjdk.java.net/~valeriep/8216039/webrev.00/

Mach5 result is clean.

Thanks,

Valerie





From Nico.Williams at twosigma.com  Mon Mar 25 21:22:48 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 25 Mar 2019 21:22:48 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <DB7PR08MB3307BE0A3BDD7579033B077AFF5E0@DB7PR08MB3307.eurprd08.prod.outlook.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>
 <aa68622e-995a-93cf-bb81-8cbc1c5c4c10@gmx.net>
 <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com>
 <20190325153741.GM9177@twosigma.com>
 <DB7PR08MB3307BE0A3BDD7579033B077AFF5E0@DB7PR08MB3307.eurprd08.prod.outlook.com>
Message-ID: <20190325212248.GN9177@twosigma.com>

On Mon, Mar 25, 2019 at 07:45:07PM +0000, Bernd Eckenfels wrote:
> Just to add another aspect to the discussion, there are at least 3 DLLs out
> there which implement this functionality (Microsoft?s JDBC driver, jTDS
> driver and Waffle) + commercial solutions as we have heared. All of them are
> used to allow authenticating the current user against services (mostly TDS
> (SQL Server), SMB and http.
> 
> So having a GSS provider, even when it is not used by default would hugely
> benefit a lot of projects (especially if it does not require JAAS wrapping
> and will support Windows 10 with Credential Guard for NTLM and Kerberos)

Good point.

Oh, and BTW, Windows too has acquireCredential extensions not unlike
gss_acquire_cred_from().

From martijnverburg at gmail.com  Fri Mar 22 19:37:37 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 22 Mar 2019 19:37:37 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
Message-ID: <CAP7YuASAo78NL3p-kwMDT7sH7oTHufqMEXSQ75HbmsBTDPQ_Fw@mail.gmail.com>

FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide a
patch to upstream that change.

Cheers,
Martijn


On Fri, 22 Mar 2019 at 19:35, Sean Mullan <sean.mullan at oracle.com> wrote:

> Hi Christoph,
>
> On 3/21/19 6:20 AM, Langer, Christoph wrote:
> > Hi,
> >
> > I recently came across a scenario where I wanted to use a self-built
> OpenJDK 8 in a maven build and it could not download artefacts due to
> missing root certificates. I helped myself by replacing the cacerts with
> some other version from a later OpenJDK and came over the issue. However,
> I?ve asked myself whether it was possible/worthwhile to get the root
> certificates also into an OpenJDK 8 update?
> >
> > With JEP 319 [0], Oracle has open-sourced the root certificates into
> OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1].
> After that, several commits have been made to update the set of root
> certificates and improve the tests.
> >
> > Now my questions are: Is it legally possible to bring these root
> certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be
> added to OpenJDK 8 via an update release? And, last but not least, would
> there be interest in the community for that at all?
>
> I can answer the first two questions. I talked to one of our Product
> Managers who was involved with this JEP and he said that we have
> permission to release these certificates as open source at OpenJDK (much
> as Mozilla has roots in Firefox).  Therefore there should be no concerns
> using with OpenJDK 8 or other versions for that matter.  If you mean the
> jdk8u project specifically, you should check with the current
> maintainers for interest in this as I think they currently use other
> means for their builds.
>
> --Sean
>
> >
> > Just trying to start a discussion? ??
> >
> > Best regards
> > Christoph
> >
> > [0] http://openjdk.java.net/jeps/319
> > [1] https://bugs.openjdk.java.net/browse/JDK-8189131
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190322/623f82ef/attachment.html>

From martijnverburg at gmail.com  Mon Mar 25 19:47:19 2019
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 25 Mar 2019 19:47:19 +0000
Subject: [8u] Is it possible to bring root certificates to OpenJDK 8
 [JEP319] ?
In-Reply-To: <HE1PR0201MB2266E612E73C33F39B1057438A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <HE1PR0201MB2266AE2C5DC66EB63BE544D98A420@HE1PR0201MB2266.eurprd02.prod.outlook.com>
 <d49422ba-f98e-a906-c072-ba2603f9c203@oracle.com>
 <CAP7YuASAo78NL3p-kwMDT7sH7oTHufqMEXSQ75HbmsBTDPQ_Fw@mail.gmail.com>
 <HE1PR0201MB2266E612E73C33F39B1057438A5E0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CAP7YuAQ2YnieMP3VC1+3A8Ko9i9yTQwij2+Y+K248tJMefwSRg@mail.gmail.com>

We basically pulled in the JEP 319 certs from 11 and put them into 8. Happy
to create a patch if that helps, might be a slightly different set to what
you are proposing though?

Cheers,
Martijn


On Mon, 25 Mar 2019 at 07:22, Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Martijn,
>
>
>
> as far as I understand the AdoptOpenJDK infrastructure, you have created a
> cacerts file from the Mozilla certificates which you are using in the
> AdoptOpenJDK 8 build via configure option [1]. Is that correct or am I
> missing something?
>
>
>
> I was planning to bring the cacerts file from jdk/jdk down to 8 with the
> associated tests. Your build setup should still work then, I guess.
>
>
>
> However, if somebody from AdoptOpenJDK wants to do the work of bringing it
> into OpenJDK8 updates, feel free. It?s not the very first thing on my todo
> list ??
>
>
>
> Thanks & Best regards
>
> Christoph
>
>
>
> [1] https://github.com/AdoptOpenJDK/openjdk-build/tree/master/security
>
>
>
>
>
> *From:* Martijn Verburg <martijnverburg at gmail.com>
> *Sent:* Freitag, 22. M?rz 2019 20:38
> *To:* Sean Mullan <sean.mullan at oracle.com>
> *Cc:* Langer, Christoph <christoph.langer at sap.com>;
> jdk8u-dev at openjdk.java.net; OpenJDK Dev list <
> security-dev at openjdk.java.net>
> *Subject:* Re: [8u] Is it possible to bring root certificates to OpenJDK
> 8 [JEP319] ?
>
>
>
> FWIW - we backported these in the AdoptOpenJDK 8 builds and could provide
> a patch to upstream that change.
>
>
> Cheers,
> Martijn
>
>
>
>
>
> On Fri, 22 Mar 2019 at 19:35, Sean Mullan <sean.mullan at oracle.com> wrote:
>
> Hi Christoph,
>
> On 3/21/19 6:20 AM, Langer, Christoph wrote:
> > Hi,
> >
> > I recently came across a scenario where I wanted to use a self-built
> OpenJDK 8 in a maven build and it could not download artefacts due to
> missing root certificates. I helped myself by replacing the cacerts with
> some other version from a later OpenJDK and came over the issue. However,
> I?ve asked myself whether it was possible/worthwhile to get the root
> certificates also into an OpenJDK 8 update?
> >
> > With JEP 319 [0], Oracle has open-sourced the root certificates into
> OpenJDK. The initial check-in was done for jdk10, via bug JDK-8189131 [1].
> After that, several commits have been made to update the set of root
> certificates and improve the tests.
> >
> > Now my questions are: Is it legally possible to bring these root
> certificates also into OpenJDK 8? Since it is a JEP, can the ?feature? be
> added to OpenJDK 8 via an update release? And, last but not least, would
> there be interest in the community for that at all?
>
> I can answer the first two questions. I talked to one of our Product
> Managers who was involved with this JEP and he said that we have
> permission to release these certificates as open source at OpenJDK (much
> as Mozilla has roots in Firefox).  Therefore there should be no concerns
> using with OpenJDK 8 or other versions for that matter.  If you mean the
> jdk8u project specifically, you should check with the current
> maintainers for interest in this as I think they currently use other
> means for their builds.
>
> --Sean
>
> >
> > Just trying to start a discussion? ??
> >
> > Best regards
> > Christoph
> >
> > [0] http://openjdk.java.net/jeps/319
> > [1] https://bugs.openjdk.java.net/browse/JDK-8189131
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190325/83c0822a/attachment.html>

From alexey.ivanov at oracle.com  Mon Mar 25 14:46:25 2019
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Mon, 25 Mar 2019 14:46:25 +0000
Subject: <AWT Dev> RFR(xs): 8221375: Windows 32bit build (VS2017) broken
In-Reply-To: <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>
References: <CAA-vtUwuJ0MFWbgeT+Ch2qSZeZTFq-uYB-Fd3r3b3Ht+67S1wQ@mail.gmail.com>
 <44c67029-57fc-155c-39e1-bd810e70fe32@oracle.com>
 <CAA-vtUyhVLJm-TjJk-Rt4ibk7cYdM2k5ONUszt3ms39SjcoTHA@mail.gmail.com>
 <46ea4603-9a4c-6330-ad47-30fe4137fc0b@oracle.com>
 <CAA-vtUwA+cUxS3XHvNkwXP3hMPiW=WWhn5RFWsTK9qQA_NUHug@mail.gmail.com>
 <CAA-vtUzbk8aCq8XV7pyDj3z5+dh9bjt7HtAm1MJWsm3o2bv0Yg@mail.gmail.com>
Message-ID: <8200636c-f2d8-b9b8-824b-a6e25445539b@oracle.com>

Hi Thomas,

There was a thread about failing build on 32 bit Windows:
http://mail.openjdk.java.net/pipermail/build-dev/2018-November/023767.html

It continued in February 2019:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024925.html

Fast debug builds were affected. Likely there was mismatch between 
CALLBACK / JNICALL macro:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024972.html
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024973.html

Magnus suggested a fix:
http://mail.openjdk.java.net/pipermail/build-dev/2019-February/024996.html

Yet there was no reply as whether it fixed the debug build or not.


Hope these pointers help.

Regards,
Alexey

On 25/03/2019 12:45, Thomas St?fe wrote:
> Hi all,
>
> Following David's suggestion, I withdraw this bug and will open issues 
> for each area separately.
>
> Cheers, Thomas
>
>
>
> On Mon, Mar 25, 2019 at 1:44 PM Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi David,
>
>     Updating vs2017 did not help :/
>
>     Cheers, Thomas
>
>     On Mon, Mar 25, 2019 at 8:17 AM David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>
>         Hi Thomas,
>
>         On 25/03/2019 5:01 pm, Thomas St?fe wrote:
>         > Hi David,
>         >
>         > (added net-dev, awt-dev, security-dev since part of these
>         fixes are in
>         > their territory)
>
>         May be better to split up the reviews, cross-posting that many
>         groups
>         gets very messy given most people won't be subscribed to them
>         all -
>         myself included.
>
>
>
>         > On Mon, Mar 25, 2019 at 1:34 AM David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         > <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>         >
>         >? ? ?Hi Thomas,
>         >
>         >? ? ?A few queries, comments and concerns ...
>         >
>         >? ? ?On 25/03/2019 6:58 am, Thomas St?fe wrote:
>         >? ? ? > Hi all,
>         >? ? ? >
>         >? ? ? > After a long time I tried to build a Windows 32bit VM
>         (VS2017)
>         >? ? ?and failed;
>         >
>         >? ? ?I'm somewhat surprised as I thought someone was actively
>         doing Windows
>         >? ? ?32-bit builds out there, plus there are shared code
>         changes that should
>         >? ? ?also have been caught by non-Windows 32-bit builds. :(
>         >
>         >
>         > Not sure what others?do. I did a 32bit windows build,
>         slowdebug, warning
>         > enabled, and it failed with those 5+ issues.
>         >
>         >? ? ? > multiple errors and warnings. Lets reverse the bitrot:
>         >? ? ? >
>         >? ? ? > cr:
>         >? ? ? >
>         >
>         http://cr.openjdk.java.net/~stuefe/webrevs/8221375--windows-32bit-build-(vs2017)-broken-in-many-places/webrev.00/webrev/
>         >? ? ? >
>         >? ? ? > Issue: https://bugs.openjdk.java.net/browse/JDK-8221375
>         >? ? ? >
>         >? ? ? > Most of the fixes are trivial: Calling convention
>         mismatches (awt
>         >? ? ?DTRACE
>         >? ? ? > callbacks), printf specifiers etc.
>         >? ? ? >
>         >? ? ? > Had to supress a warning in os_windows_x86.cpp - I
>         was surprised
>         >? ? ?by this
>         >? ? ? > since this did not look 32bit specifc, do we disable
>         warnings on
>         >? ? ?Windows
>         >? ? ? > 64bit builds?
>         >
>         >? ? ?What version of VS2017? We use VS2017 15.9.6 and we
>         don't disable
>         >? ? ?warnings.
>         >
>         >
>         > I use VS2017 CE. Not sure which version spcifically, but my
>         compiler is at
>         >
>         > Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26431
>         for x86
>
>         I think that would equate to an older version - 15.7
>
>         MSVC++ 14.14 _MSC_VER == 1914 (Visual Studio 2017 version 15.7)
>
>         Any chance you can upgrade to latest version? (Especially in
>         light of
>         the apparent compiler bug you cite below.)
>
>         Thanks,
>         David
>         -----
>
>         >? ? ? > The error I had in vmStructs.cpp was a bit weird:
>         compiler
>         >? ? ?complained about
>         >? ? ? > an assignment of an enum value defined like this:
>         >? ? ? >
>         >? ? ? > hash_mask_in_place? ? ? ?= (address_word)hash_mask <<
>         hash_shift
>         >? ? ? >
>         >? ? ? > to an uint64_t variable, complaining about narrowing.
>         I did not
>         >? ? ?find out
>         >? ? ? > what his problem was. In the end, I decided to add an
>         explicit
>         >? ? ?cast to
>         >? ? ? > GENERATE_VM_LONG_CONSTANT_ENTRY(name) (see
>         vmStructs.hpp).
>         >
>         >? ? ?Not at all sure that's the right fix. In markOop.hpp we
>         see that value
>         >? ? ?gets special treatment on Windows-x64:
>         >
>         >
>         >? ? ?#ifndef _WIN64
>         >? ? ? ? ? ? ? ? ,hash_mask? ? ? ? ? ? ? ?=
>         right_n_bits(hash_bits),
>         >? ? ? ? ? ? ? ? hash_mask_in_place? ? ? ?=
>         (address_word)hash_mask <<
>         >? ? ?hash_shift
>         >? ? ?#endif
>         >? ? ? ? ?};
>         >
>         >? ? ? ? ?// Alignment of JavaThread pointers encoded in
>         object header
>         >? ? ?required
>         >? ? ?by biased locking
>         >? ? ? ? ?enum { biased_lock_alignment? ? = 2 << (epoch_shift
>         + epoch_bits)
>         >? ? ? ? ?};
>         >
>         >? ? ?#ifdef _WIN64
>         >? ? ? ? ? ?// These values are too big for Win64
>         >? ? ? ? ? ?const static uintptr_t hash_mask =
>         right_n_bits(hash_bits);
>         >? ? ? ? ? ?const static uintptr_t hash_mask_in_place? =
>         > ?(address_word)hash_mask << hash_shift;
>         >? ? ?#endif
>         >
>         >? ? ?perhaps something special is needed for Windows-x86. I'm
>         unclear how
>         >? ? ?the
>         >? ? ?values can be "too big" ??
>         >
>         >
>         > I banged my head against this for an hour or so and I think
>         this is a
>         > compiler bug.
>         >
>         > What I get is:
>         >
>         > warning C4838: conversion from '' to 'uint64_t' requires a
>         narrowing
>         > conversion
>         >
>         > (Note the empty "from" string.)
>         >
>         > Here are my tries to provoke the error:
>         >
>         > VMLongConstantEntry iii[] = {? { "hallo",
>         > markOopDesc::hash_mask_in_place }, {0,0}}; <<< this fails
>         > VMLongConstantEntry iii = { "hallo",
>         markOopDesc::hash_mask_in_place };
>         >? ?<< but this succeeds
>         > uint64_t iii = markOopDesc::hash_mask_in_place; ?<< this
>         succeeds? too
>         >
>         > I have no clue what this means. It is difficult to fix since
>         the
>         > expression is hidden in such a macro pile. But I think
>         either we go with
>         > my change or we disable the warning for win32 for the whole
>         section.
>         >
>         >? ? ? >
>         >? ? ? > With this patch we can build with warnings enabled on
>         32bit and 64bit
>         >? ? ? > windows.
>         >? ? ? >
>         >? ? ? > Since patch fixes both hotspot and JDK parts, I'm
>         sending it to
>         >? ? ?hs-dev and
>         >? ? ? > core-libs-dev.
>         >
>         >? ? ?Don't see anything that actually comes under
>         core-libs-dev. Looks like
>         >? ? ?one net-dev, one awt-dev and one security-dev. Sorry.
>         >
>         >
>         > Okay, I will add them.
>         >
>         >? ? ?Cheers,
>         >? ? ?David
>         >? ? ?-----
>         >
>         >
>         > Thanks for reviewing,
>         >
>         > Thomas
>         >
>         >? ? ? > Thanks, Thomas
>         >? ? ? >
>         >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190325/9e143f6c/attachment-0001.html>

From weijun.wang at oracle.com  Mon Mar 25 23:12:21 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 26 Mar 2019 07:12:21 +0800
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <20190325153741.GM9177@twosigma.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>
 <aa68622e-995a-93cf-bb81-8cbc1c5c4c10@gmx.net>
 <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com>
 <20190325153741.GM9177@twosigma.com>
Message-ID: <9FED7A0B-8E3B-4D8E-B35C-EFE5521E6274@oracle.com>



> On Mar 25, 2019, at 11:37 PM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> 
> On Mon, Mar 25, 2019 at 11:17:17AM +0800, Weijun Wang wrote:
>>> On Mar 23, 2019, at 7:50 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
>>>>> There's a few reasons:
>>>>> 
>>>>> - NTLM doesn't have an OID, at least as I remember
>>>>> 
>>>>> - the JDK's JGSS stuff is very Kerberos-specific, especially w/
>>>>>  regards to the ServicePermission stuff
>>>> 
>>>> Yes, it needs to check a permission if the token is SPNEGO and
>>>> internally it's Kerberos. I also believe the HTTP Negotiate code
>>>> there is probably not good at dealing with a Negotiate dialog with
>>>> 2 rounds. The first problem should be easy to fix, I'll see if the
>>>> 2nd is complicated.
> 
> I expect lots of implementations of HTTP/Negotiate to not support more
> than one round trip.  However, if a client and server lack credentials
> for a common mechanism, authentication will fail or not even start, and
> if they do have credentials for a common mechanism but one or both
> cannot handle more than one round trip, they'll fail.  Either way they
> fail, so what's the problem?  Ignoring for a moment NTLM's weakness,
> adding support for it adds ways to win, not ways to fail.
> 
>> It works. Java's (old) HTTPConnection sends an NTLM token to IIS and
>> after 4 messages I see 200 OK.
>> 
>> But 1) Java GSS acceptor does not accept it and I don't want to break
>> interop inside Java.
> 
> That's not breaking interop.  A Windows initiator and non-Windows
> acceptor (and vice-versa) will still interop provided both have Kerberos
> credentials.

But there needs another round of negotiation and you know Java might not be good at it.

> 
>> 2) No more permission check.
> 
> I don't understand (2).

Now that the ServicePermission check is skipped, some sort of NTLMPermission check will be needed.

--Max

> 
>> Not going to do it this time. Later I might ask networking how
>> transparent NTLM works and if they needs any permission checking or
>> other settings I can probably follow.
> 
> Of course it needs permission checking, except that in a world without
> applets that's a bit pointless.
> 
> Nico
> -- 


From valerie.peng at oracle.com  Tue Mar 26 00:03:39 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 25 Mar 2019 17:03:39 -0700
Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in
 SunPKCS11 crypto provider
In-Reply-To: <acf11db3-b06e-9703-0a94-d0198fb7335f@redhat.com>
References: <a03d6a49-5811-faad-e6ba-0e6c668d614a@redhat.com>
 <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com>
 <acf11db3-b06e-9703-0a94-d0198fb7335f@redhat.com>
Message-ID: <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com>

Hi, Martin,

Thanks for trying to address this "free-wrapper-key" issue. However, 
changes in the key clean up/free area is difficult to verify and check 
for issues and I am a little concerned that this new model may be hard 
to trace when the key id is mutable and potentially fragile/error prone 
for future changes/fixes.

I still need to think through a few things. Maybe you can help me 
understand the current changes or we can explore alternatives.

My questions/feedbacks on current changes are:

1) line 1283: ref may be null (see line 1220) and this will lead to NPE?

2) It looks like you don't really need to store the "wrapperKeyUsed" 
value in both NativeKeyHolder and SessionKeyRef classes. It can be a 
local variable for NativeKeyHolder class and the increment of 
nativeKeyWrapperRefCount can be moved to SessionKeyRef constructor.? The 
counter nativeKeyWrapperRefCount is incremented inside NativeKeyHolder 
constructor

3) I have not spent as much time as you on tracing this. However, I 
think we should be able to keep the "final keyID" approach and handle 
the NativeKeyWrapperRefCount inc/dec in SessionKeyRef 
constructor/dispose methods. Have you tried this?

4) It may not be enough to just run tests under sun/security/pkcs11, as 
SunPKCS11 provider is used by many other JDK security components such as 
TLS. To be safe, you should submit the test against jdk-tier1,jdk-tier2 
to check for possible regressions. If you can't, please let me know.

Thanks,

Valerie

On 3/20/2019 9:24 PM, Martin Balao wrote:
> Hi Valerie,
>
> On 3/19/19 7:17 PM, Valerie Peng wrote:
>> How about another potential problem - wrapper key may never get deleted?
>> If we don't have a good solution to addressing it, at least add a
>> comment about it?
>> Rest looks fine.
>>
> Thanks for your feedback.
>
> The Wrapper Key was never meant to be destroyed. However, it's a good
> idea and we should do it, in addition to fixing this bug.
>
> Here it's my proposal for getting rid of the Wrapper Key when it's no
> longer needed:
>
> Webrev 01:
>
>   * http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.01/
>
> Please note that a few changes were required in SessionKeyRef objects
> lifetime. SessionKeyRef objects will live as long as their corresponding
> P11Key object lives -a similar scheme was implemented in the original
> patch-. This allows us to decrement Wrapper Key references -and
> eventually destroy it- while P11Key objects which don't have a native
> key created are deleted. In other words, objects that have wrapped
> native key information but don't have a native key alive can also
> decrement the Wrapper Key reference counter when deleted.
>
> Testing:
>
>   * No regressions found in sun/security/pkcs11.
>
>   * I've verified with the debugger all the new execution flows,
> including the deletion of a Wrapper Key. It would be a bit difficult to
> assert this from an automated test though.
>
> Kind regards,
> Martin.-

From raell at web.de  Mon Mar 25 23:17:59 2019
From: raell at web.de (raell at web.de)
Date: Tue, 26 Mar 2019 00:17:59 +0100
Subject: Release plan for ChaCha20/Poly1305 cipher suite
Message-ID: <trinity-56faa43e-1488-4185-bf3a-3fcffb331d40-1553555879570@3c-app-webde-bap09>

Dear,

in Java 11 (JEP 329) ChaCha20 and Poly1305 cryptographic algorithms had been implemented. However, the cipher suite TLS_CHACHA20_POLY1305_SHA256 wasn't added to the Java standard cipher suites. As far as I can see, support for this cipher suite is  neither part of Java 12.

Out of interest: Is there a plan in which Java release the cipher suite will be supported.

Thanks and regards,

Ralph


From bradford.wetmore at oracle.com  Tue Mar 26 00:14:24 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 25 Mar 2019 17:14:24 -0700
Subject: Release plan for ChaCha20/Poly1305 cipher suite
In-Reply-To: <trinity-56faa43e-1488-4185-bf3a-3fcffb331d40-1553555879570@3c-app-webde-bap09>
References: <trinity-56faa43e-1488-4185-bf3a-3fcffb331d40-1553555879570@3c-app-webde-bap09>
Message-ID: <b9cf5cb9-0850-0497-b283-bce6d0ead23d@oracle.com>

Please see the SunJSSE provider documentation for JDK 12.

https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2

Brad


On 3/25/2019 4:17 PM, raell at web.de wrote:
> Dear,
> 
> in Java 11 (JEP 329) ChaCha20 and Poly1305 cryptographic algorithms had been implemented. However, the cipher suite TLS_CHACHA20_POLY1305_SHA256 wasn't added to the Java standard cipher suites. As far as I can see, support for this cipher suite is  neither part of Java 12.
> 
> Out of interest: Is there a plan in which Java release the cipher suite will be supported.
> 
> Thanks and regards,
> 
> Ralph
> 

From jamil.j.nimeh at oracle.com  Tue Mar 26 01:33:09 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 25 Mar 2019 18:33:09 -0700
Subject: Release plan for ChaCha20/Poly1305 cipher suite
In-Reply-To: <b9cf5cb9-0850-0497-b283-bce6d0ead23d@oracle.com>
References: <trinity-56faa43e-1488-4185-bf3a-3fcffb331d40-1553555879570@3c-app-webde-bap09>
 <b9cf5cb9-0850-0497-b283-bce6d0ead23d@oracle.com>
Message-ID: <28c42571-811c-16a9-2b8a-487d1b290d3c@oracle.com>

Hello Ralph, to add to what Brad already said:

The TLS 1.2 and 1.3 ChaCha20-Poly1305 suites are present in JDK 12, but 
not JDK 11 (that was just the JCE Cipher support).

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

Commit: http://hg.openjdk.java.net/jdk/jdk/rev/720fd6544b03

--Jamil

On 3/25/19 5:14 PM, Bradford Wetmore wrote:
> Please see the SunJSSE provider documentation for JDK 12.
>
> https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2 
>
>
> Brad
>
>
> On 3/25/2019 4:17 PM, raell at web.de wrote:
>> Dear,
>>
>> in Java 11 (JEP 329) ChaCha20 and Poly1305 cryptographic algorithms 
>> had been implemented. However, the cipher suite 
>> TLS_CHACHA20_POLY1305_SHA256 wasn't added to the Java standard cipher 
>> suites. As far as I can see, support for this cipher suite is? 
>> neither part of Java 12.
>>
>> Out of interest: Is there a plan in which Java release the cipher 
>> suite will be supported.
>>
>> Thanks and regards,
>>
>> Ralph
>>

From weijun.wang at oracle.com  Tue Mar 26 03:20:10 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 26 Mar 2019 11:20:10 +0800
Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain
 java tests
In-Reply-To: <B5E5C972-8C01-42B6-8CD7-500B2AF99A7F@oracle.com>
References: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com>
 <1550223285.2497.12.camel@paratix.ch>
 <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com>
 <B5E5C972-8C01-42B6-8CD7-500B2AF99A7F@oracle.com>
Message-ID: <DD160E4A-25AF-4275-990A-C75D06467C9B@oracle.com>

Ding-dong.

> On Mar 5, 2019, at 8:26 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Webrev updated at
> 
>   https://cr.openjdk.java.net/~weijun/8180573/webrev.01
> 
> BTW, last time I mistakenly removed ExportPrivateKeyNoPwd.java which is used by ListKeychainStore.sh. It's now back.
> 
> Thanks,
> Max
> 
>> On Feb 15, 2019, at 9:31 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>> 
>> Hi Philipp,
>> 
>> In most cases, it's just about creating a non-empty file; in some case, the content is relevant. For the former, I will change it to something like "new byte[10]"; for the latter, I'll use getBytes(UTF_8).
>> 
>> Thanks,
>> Max
>> 
>> 
>>> On Feb 15, 2019, at 5:34 PM, Philipp Kunz <philipp.kunz at paratix.ch> wrote:
>>> 
>>> Hi Max,
>>> 
>>> I don't know if it is important enough, certainly not a serious issue.
>>> In your patch, for example in DiffEnd.java and a few other tests, Strings are encoded to byte streams with String.getBytes() which uses the default platform character set to encode the strings.
>>> Manifests, however, always use UTF-8 as the character set to encode. In my opinion, getBytes(java.nio.charset.StandardCharsets.UTF_8) would be appropriate to specify the encoding in a platform-independent way.
>>> Now the manifests used in the tests use so few different characters that this might not even make a real difference because the first around 100 characters or so of most character sets are the same in most encodings.
>>> I suspect that the encoding might also have been platform-dependent in at least some of the previous shell tests and therefore this aspect might as well be addressed separately and is not strictly necessary to just properly convert shell tests to java.
>>> 
>>> Regards,
>>> Philipp
>>> 
>>> 
>>> On Wed, 2019-02-13 at 11:01 +0800, Weijun Wang wrote:
>>>> Please review the fix at
>>>> 
>>>> 
>>>> https://cr.openjdk.java.net/~weijun/8180573/webrev.00/
>>>> 
>>>> 
>>>> Notes:
>>>> 
>>>> - Most changes are just .sh -> .java
>>>> 
>>>> - StorePasswordsByShell.sh combined into StorePasswords.java
>>>> 
>>>> - In most cases, JarUtils is called to create a jar file. Sometimes the jar command is called because of delicate differences, for example, jar adds directory entries also.
>>>> 
>>>> - The i18n tests are completely manual described in i18n.html. Old i18n.java is useless, now is also empty.
>>>> 
>>>> - Copyright year updated to 2019, @bug unchanged.
>>>> 
>>>> Two files not converted yet:
>>>> 
>>>> - ./keytool/console.sh
>>>> 
>>>> This is a manual test calling old versions of JDK.
>>>> 
>>>> - ./keytool/ListKeychainStore.sh
>>>> 
>>>> I tried on this one but "security list-keychains -s ..." has no effect on mach5 machines when calling by ProcessTools. No idea why, I've created a separate bug (JDK-8218886) for it.
>>>> 
>>>> Thanks,
>>>> Max
>>>> 
>>>> 
>> 
> 


From christoph.langer at sap.com  Tue Mar 26 08:39:33 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 26 Mar 2019 08:39:33 +0000
Subject: RFR(xxs): 8221407: Windows 32bit build error in
 libsunmscapi/security.cpp
In-Reply-To: <CAA-vtUy3DRRRSvsAY45EASr_51cEfJC8uN+96i10R9-t4-Quow@mail.gmail.com>
References: <CAA-vtUy3DRRRSvsAY45EASr_51cEfJC8uN+96i10R9-t4-Quow@mail.gmail.com>
Message-ID: <HE1PR0201MB2266B8E02ED8AC5795CBD3EB8A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>

Hi Thomas,

looks good to me.

Best regards
Christoph

From: security-dev <security-dev-bounces at openjdk.java.net> On Behalf Of Thomas St?fe
Sent: Montag, 25. M?rz 2019 14:13
To: security-dev at openjdk.java.net
Subject: RFR(xxs): 8221407: Windows 32bit build error in libsunmscapi/security.cpp

Hi all,

please review this tiny fix to the windows 32 build:

issue: https://bugs.openjdk.java.net/browse/JDK-8221407
cr: http://cr.openjdk.java.net/~stuefe/webrevs/8221407-windows32-buildfixes-libsunmscapi/webrev.00/webrev/

Just a bunch of obvious fixes for cases where a jlong was handed into system APIs requiring HANDLEs, which are pointer sized.

Thanks, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190326/365a3199/attachment.html>

From thomas.stuefe at gmail.com  Tue Mar 26 08:50:33 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 26 Mar 2019 09:50:33 +0100
Subject: RFR(xxs): 8221407: Windows 32bit build error in
 libsunmscapi/security.cpp
In-Reply-To: <HE1PR0201MB2266B8E02ED8AC5795CBD3EB8A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
References: <CAA-vtUy3DRRRSvsAY45EASr_51cEfJC8uN+96i10R9-t4-Quow@mail.gmail.com>
 <HE1PR0201MB2266B8E02ED8AC5795CBD3EB8A5F0@HE1PR0201MB2266.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUwsitV=ADCA6TpAVTLBrYmHGkAtK16H9WCoid-sbgcJ_g@mail.gmail.com>

Thanks, Christoph!

On Tue, Mar 26, 2019, 9:39 AM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi Thomas,
>
>
>
> looks good to me.
>
>
>
> Best regards
>
> Christoph
>
>
>
> *From:* security-dev <security-dev-bounces at openjdk.java.net> *On Behalf
> Of *Thomas St?fe
> *Sent:* Montag, 25. M?rz 2019 14:13
> *To:* security-dev at openjdk.java.net
> *Subject:* RFR(xxs): 8221407: Windows 32bit build error in
> libsunmscapi/security.cpp
>
>
>
> Hi all,
>
>
>
> please review this tiny fix to the windows 32 build:
>
>
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8221407
>
> cr:
> http://cr.openjdk.java.net/~stuefe/webrevs/8221407-windows32-buildfixes-libsunmscapi/webrev.00/webrev/
>
>
>
> Just a bunch of obvious fixes for cases where a jlong was handed into
> system APIs requiring HANDLEs, which are pointer sized.
>
>
>
> Thanks, Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190326/5ab80a36/attachment.html>

From Nico.Williams at twosigma.com  Tue Mar 26 15:24:04 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Tue, 26 Mar 2019 15:24:04 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <9FED7A0B-8E3B-4D8E-B35C-EFE5521E6274@oracle.com>
References: <a0c26d6d-29a2-6466-85ca-2cea2be05c8b@gmx.net>
 <20190322152824.GF9177@twosigma.com>
 <87B89800-053B-4635-A5B3-F2BEEFDB4F4B@oracle.com>
 <aa68622e-995a-93cf-bb81-8cbc1c5c4c10@gmx.net>
 <77568CBC-DD9B-4F5D-8CC3-AC334719C788@oracle.com>
 <20190325153741.GM9177@twosigma.com>
 <9FED7A0B-8E3B-4D8E-B35C-EFE5521E6274@oracle.com>
Message-ID: <20190326152404.GO9177@twosigma.com>

On Tue, Mar 26, 2019 at 07:12:21AM +0800, Weijun Wang wrote:
> > On Mar 25, 2019, at 11:37 PM, Nico Williams <Nico.Williams at twosigma.com> wrote:
> >> But 1) Java GSS acceptor does not accept it and I don't want to break
> >> interop inside Java.
> > 
> > That's not breaking interop.  A Windows initiator and non-Windows
> > acceptor (and vice-versa) will still interop provided both have Kerberos
> > credentials.
> 
> But there needs another round of negotiation and you know Java might not be good at it.

As long as it doesn't crash it's good enough.  There's two ways to fail,
and that's OK.

> >> 2) No more permission check.
> > 
> > I don't understand (2).
> 
> Now that the ServicePermission check is skipped, some sort of
> NTLMPermission check will be needed.

IIRC that's too difficult.  It would be easier to map generic GSS names
to Kerberos names for use with ServicePermission.  The design of
ServicePermission was all wrong, it should always have dealt with GSS
names only, and Krb5Principal should never have been a thing because
GSSName should have been a (extend) Principal.

By making GSSName extend Principal we can begin to fix these issues.

From weijun.wang at oracle.com  Wed Mar 27 13:53:00 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 27 Mar 2019 21:53:00 +0800
Subject: RFR 8221257: Improve serial number generation mechanism for keytool
 -gencert
Message-ID: <20A492B5-B87C-43FF-9227-90E2CD8A6605@oracle.com>

Please take a review at

   https://cr.openjdk.java.net/~weijun/8221257/webrev.00/

The test would intermittently fail, which could be annoying in the future although the randomness keyword is used. But the test is meant to ensure that we provide 64 bits of randomness so I'll keep it.

Thanks,
Max


From xuelei.fan at oracle.com  Wed Mar 27 14:44:17 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 27 Mar 2019 07:44:17 -0700
Subject: RFR 8221257: Improve serial number generation mechanism for
 keytool -gencert
In-Reply-To: <20A492B5-B87C-43FF-9227-90E2CD8A6605@oracle.com>
References: <20A492B5-B87C-43FF-9227-90E2CD8A6605@oracle.com>
Message-ID: <bd24ad1a-093b-5049-85ab-c25a36b61fe4@oracle.com>

Looks fine to me.

Xuelei

On 3/27/2019 6:53 AM, Weijun Wang wrote:
> Please take a review at
> 
>     https://cr.openjdk.java.net/~weijun/8221257/webrev.00/
> 
> The test would intermittently fail, which could be annoying in the future although the randomness keyword is used. But the test is meant to ensure that we provide 64 bits of randomness so I'll keep it.
> 
> Thanks,
> Max
> 

From xuelei.fan at oracle.com  Wed Mar 27 15:48:59 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 27 Mar 2019 08:48:59 -0700
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
 SequenceInputStream
In-Reply-To: <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com>
References: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com>
 <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com>
Message-ID: <56d8b3c3-54f9-9896-c4b8-d34b8ccc2cba@oracle.com>

DerIndefLenConverter.convertStream().

Is it a concern that this method read too much? For example, the DER 
bytes of the target object is 256 bytes, but read 1024 bytes from the 
input stream.  And then the next DER or other object in the inputstream 
may not be able to properly parsed.

BTW, if the input stream is a slow traffic, there might be a few 
DataNotEnoughException get thrown.  Throwing and catching of exceptions 
are expensive.  I may divide the convertBytes() into two parts, one 
looking for the DER ending position, the other one converting to DER 
encoding.  Then the DataNotEnoughException in convertStream() could be 
avoided.

Thanks,
Xuelei

On 3/24/2019 7:42 PM, Weijun Wang wrote:
> Ping again.
> 
> No new test added.
> 
> Thanks,
> Max
> 
>> On Mar 5, 2019, at 11:06 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Please take a review at
>>
>>    https://cr.openjdk.java.net/~weijun/8157404/webrev.00/
>>
>> When Java finds out data is not enough while resolving a BER, it reads in more data and try converting again. Please note that calling available() again after readNBytes is not reliable because it might return zero even if there are more bytes.
>>
>> A more efficient fix could be rewriting the convert logic to use the stream directly (parsing while reading), and thus avoid the need to call the whole convertBytes method again, but that's a big change and there is a risk getting wrong somewhere. This fix is likely to be backported to older LTS releases.
>>
>> Note this could block but it should only happen when data is not enough, and it only reads one byte.
>>
>> The test included in the bug report passed, but I'll see if I can write a new test not depending on any existing binary data.
>>
>> And I'm running a mach5 test job now.
>>
>> Thanks,
>> Max
>>
> 

From weijun.wang at oracle.com  Thu Mar 28 12:20:29 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 28 Mar 2019 20:20:29 +0800
Subject: 8219861: Add new keytool -tls command for displaying TLS
 configuration information
Message-ID: <F5936D4D-36F3-439E-B88F-902A7C24F48F@oracle.com>

Please take a review at

   https://cr.openjdk.java.net/~weijun/8219861/webrev.01/

The ShowInfo::tls method is extracted from the JSSE Provider doc [1].

Noreg-other?

Thanks,
Max

[1] https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2

From xuelei.fan at oracle.com  Thu Mar 28 14:50:56 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 28 Mar 2019 07:50:56 -0700
Subject: RFR [13] JDK-8168261: Use server cipher suites preference by
 default
In-Reply-To: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com>
References: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com>
Message-ID: <746bc4c2-657a-fb36-1f70-15d8407fd034@oracle.com>

ping ...

Xuelei

On 3/21/2019 8:24 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the update reviewed?
>  ?? http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/
> 
> With this update, server cipher suite preference will be used by default 
> for TLS handshaking in the SunJSSE provider.? For more details, please 
> refer to CSR:
>  ?? https://bugs.openjdk.java.net/browse/JDK-8219657
> 
> Thanks,
> Xuelei

From xuelei.fan at oracle.com  Thu Mar 28 14:50:10 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 28 Mar 2019 07:50:10 -0700
Subject: RFR [13] JDK-8163326: Update the default enabled cipher suites
 preference
In-Reply-To: <297c8c91-e209-4180-2ca4-460a16c39964@oracle.com>
References: <297c8c91-e209-4180-2ca4-460a16c39964@oracle.com>
Message-ID: <23208a33-0b70-4f25-2c8e-61b36f112e5f@oracle.com>

ping ...

Xuelei

On 3/22/2019 7:51 AM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed?
>  ??? http://cr.openjdk.java.net/~xuelei/8163326/webrev.00/
> 
> With this update, the SunJSSE default enabled cipher suites preference 
> is adjusted accordingly.? For more details, please refer to CSR:
>  ??? https://bugs.openjdk.java.net/browse/JDK-8219545
> 
> Thanks,
> Xuelei

From xuelei.fan at oracle.com  Thu Mar 28 14:52:59 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 28 Mar 2019 07:52:59 -0700
Subject: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC
 keys are stored in PKCS11
In-Reply-To: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com>
References: <21eb9440-05e2-29df-4fe5-ef4c04bb289f@oracle.com>
Message-ID: <bbb2f19b-9bf5-9bb9-c3bf-533b1bb5542d@oracle.com>

ping ...

Xuelei

On 3/22/2019 2:02 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed?
>  ?? http://cr.openjdk.java.net/~xuelei/8217610/webrev.00/
> 
> For EC key exchange in TLS connections, the private key should use the 
> specified EC groups.? The current code is calling 
> ECPrivateKey.getParams().? However, the private key may be not an 
> instance of ECPrivateKey, for example for non-extractable private key in 
> the SunPKCS11 provider.
> 
> To fix the tricky bug, in this update, if private key is an instance of 
> ECPrivateKey, use it; otherwise, try to check the groups in the public 
> key of the X.509 certificate bound to the private key.
> 
> No hardware to reproduce the issue, and no new regression test.? The 
> update is straightforward.? Please help to check the patch if you can 
> play with a hardware token.
> 
> Thanks,
> Xuelei

From sean.mullan at oracle.com  Thu Mar 28 19:33:29 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 28 Mar 2019 15:33:29 -0400
Subject: RFR [13] JDK-8168261: Use server cipher suites preference by
 default
In-Reply-To: <746bc4c2-657a-fb36-1f70-15d8407fd034@oracle.com>
References: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com>
 <746bc4c2-657a-fb36-1f70-15d8407fd034@oracle.com>
Message-ID: <d6b3cd62-efa8-2b3c-b137-2cfdcbacb02f@oracle.com>

On 3/28/19 10:50 AM, Xuelei Fan wrote:
> ping ...
> 
> Xuelei
> 
> On 3/21/2019 8:24 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the update reviewed?
>> ??? http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/
>>
>> With this update, server cipher suite preference will be used by 
>> default for TLS handshaking in the SunJSSE provider.? For more 
>> details, please refer to CSR:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8219657

Can you explain why the change in SSLContextSpi was necessary?

Also, why do we need to override the engine methods in SSLContextImpl? 
Probably something simple, but not seeing the reason just from the diffs ...

--Sean




From xuelei.fan at oracle.com  Fri Mar 29 15:23:13 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 29 Mar 2019 08:23:13 -0700
Subject: RFR [13] JDK-8168261: Use server cipher suites preference by
 default
In-Reply-To: <d6b3cd62-efa8-2b3c-b137-2cfdcbacb02f@oracle.com>
References: <52c8d02c-6872-43bd-5074-a8a8f73889a6@oracle.com>
 <746bc4c2-657a-fb36-1f70-15d8407fd034@oracle.com>
 <d6b3cd62-efa8-2b3c-b137-2cfdcbacb02f@oracle.com>
Message-ID: <c0e0e13c-1356-a9ac-c6bf-ad24e9bdb869@oracle.com>

On 3/28/2019 12:33 PM, Sean Mullan wrote:
> On 3/28/19 10:50 AM, Xuelei Fan wrote:
>> ping ...
>>
>> Xuelei
>>
>> On 3/21/2019 8:24 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the update reviewed?
>>> ??? http://cr.openjdk.java.net/~xuelei/8168261/webrev.00/
>>>
>>> With this update, server cipher suite preference will be used by 
>>> default for TLS handshaking in the SunJSSE provider.? For more 
>>> details, please refer to CSR:
>>> ??? https://bugs.openjdk.java.net/browse/JDK-8219657
> 
> Can you explain why the change in SSLContextSpi was necessary?
> 
There is a bug in the implementation.

The spec says:
    "The default implementation obtains the parameters from an
     SSLSocket ..."

The parameters should be populated by the socket.

> Also, why do we need to override the engine methods in SSLContextImpl? 
> Probably something simple, but not seeing the reason just from the diffs 
> ...
> 
The SSLContextSpi implementation uses default SSLSocket instance for the 
parameters, which does not apply to DTLS protocols as the SunJSSE 
provider does not support DTLS protocols.

If we update SSLContextSpi within this update, the SSLContextImpl update 
is not necessary any more.

Here is the new webrev that removes the SSLContextImpl update:
     http://cr.openjdk.java.net/~xuelei/8168261/webrev.01/

Thanks,
Xuelei

From mbalao at redhat.com  Fri Mar 29 16:05:26 2019
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 29 Mar 2019 13:05:26 -0300
Subject: RFR 8220513: Wrapper Key may get deleted when closing sessions in
 SunPKCS11 crypto provider
In-Reply-To: <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com>
References: <a03d6a49-5811-faad-e6ba-0e6c668d614a@redhat.com>
 <431230a2-7e45-5588-920b-b73ec3e3d5f7@oracle.com>
 <acf11db3-b06e-9703-0a94-d0198fb7335f@redhat.com>
 <67deeca5-fafe-1159-e21e-0d8725e7babc@oracle.com>
Message-ID: <67fa60b7-f79e-89ed-1d94-a9d8b1e8e407@redhat.com>

Hi Valerie,

Thanks for having a look at this proposal.

On 3/25/19 9:03 PM, Valerie Peng wrote:
> 
> Thanks for trying to address this "free-wrapper-key" issue. However,
> changes in the key clean up/free area is difficult to verify and check
> for issues and I am a little concerned that this new model may be hard
> to trace when the key id is mutable and potentially fragile/error prone
> for future changes/fixes.

I agree in that there is some complexity involved, but it is not much
different than the one we have dealt with before in this whole "memory
leak" fix.

> 
> My questions/feedbacks on current changes are:
> 
> 1) line 1283: ref may be null (see line 1220) and this will lead to NPE?

For line 1283 to be executed, nativeKeyInfo has to be non-null (see line
1264). When nativeKeyInfo is non-null, a SessionKeyRef instance is
always assigned to a "ref" variable, and no execution path can set "ref"
back to null -we removed the previous "this.ref = this.ref.dispose()" line-.

This is not by-chance, this is because we now keep SessionKeyRef
instances always alive when there is native key info extracted. Previous
to this patch, a SessionKeyRef instance was alive only while there was a
native key created. The reason for this change, as I said, is that
SessionKeyRef instances now protect not only a created native key but a
wrapper key that may have been used to encrypt the extracted native key
information.

> 
> 2) It looks like you don't really need to store the "wrapperKeyUsed"
> value in both NativeKeyHolder and SessionKeyRef classes. It can be a
> local variable for NativeKeyHolder class and the increment of
> nativeKeyWrapperRefCount can be moved to SessionKeyRef constructor.? The
> counter nativeKeyWrapperRefCount is incremented inside NativeKeyHolder
> constructor

Yes, I thought about that when coming to the proposed patch but was not
convinced for clarity and safety reasons. When a wrapper key does not
exist and has to be created, we must exit the creation block with the
reference counter incremented to protect the key. Otherwise, a race
condition is possible: while one thread creates the native key but still
does not increment the reference counter, a short-living object may
destroy the wrapper key. Moving the whole creation block to the
SessionKeyRef constructor is less clear to me -see below-.

> 
> 3) I have not spent as much time as you on tracing this. However, I
> think we should be able to keep the "final keyID" approach and handle
> the NativeKeyWrapperRefCount inc/dec in SessionKeyRef
> constructor/dispose methods. Have you tried this?

Keeping the "final keyID" approach is creating different SessionKeyRef
instances every time a native key is created. However, this approach
does not have a SessionKeyRef instance when there is extracted native
key information but there isn't a native key created. Now suppose that
this extracted native key information is protected by a wrapper key and
that the P11Key gets garbage-collected. There is no one to decrement the
reference counter and the wrapper key will be always alive.

> 
> 4) It may not be enough to just run tests under sun/security/pkcs11, as
> SunPKCS11 provider is used by many other JDK security components such as
> TLS. To be safe, you should submit the test against jdk-tier1,jdk-tier2
> to check for possible regressions. If you can't, please let me know.
> 

I'm not exactly sure how can I do that but sounds good. If I cannot find
public information, I'll ask you for help.

Thanks,
Martin.-

From weijun.wang at oracle.com  Sat Mar 30 13:32:35 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 30 Mar 2019 21:32:35 +0800
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
 SequenceInputStream
In-Reply-To: <56d8b3c3-54f9-9896-c4b8-d34b8ccc2cba@oracle.com>
References: <9AE2BF48-7A80-4667-8322-B68FDC39E552@oracle.com>
 <5B15F985-85DA-4FC1-AEEC-ACF1530336DF@oracle.com>
 <56d8b3c3-54f9-9896-c4b8-d34b8ccc2cba@oracle.com>
Message-ID: <D807C1A8-C2FC-4879-B228-7132CBDB61B7@oracle.com>



> On Mar 27, 2019, at 11:48 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> DerIndefLenConverter.convertStream().
> 
> Is it a concern that this method read too much? For example, the DER bytes of the target object is 256 bytes, but read 1024 bytes from the input stream.  And then the next DER or other object in the inputstream may not be able to properly parsed.

Yes, this is possible, but I am not going to deal with it here.

> 
> BTW, if the input stream is a slow traffic, there might be a few DataNotEnoughException get thrown.  Throwing and catching of exceptions are expensive.  I may divide the convertBytes() into two parts, one looking for the DER ending position, the other one converting to DER encoding.  Then the DataNotEnoughException in convertStream() could be avoided.

You mean still using the same logic but just not with an exception? Can I just return null?

Thanks,
Max

> 
> Thanks,
> Xuelei
> 
> On 3/24/2019 7:42 PM, Weijun Wang wrote:
>> Ping again.
>> No new test added.
>> Thanks,
>> Max
>>> On Mar 5, 2019, at 11:06 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Please take a review at
>>> 
>>>   https://cr.openjdk.java.net/~weijun/8157404/webrev.00/
>>> 
>>> When Java finds out data is not enough while resolving a BER, it reads in more data and try converting again. Please note that calling available() again after readNBytes is not reliable because it might return zero even if there are more bytes.
>>> 
>>> A more efficient fix could be rewriting the convert logic to use the stream directly (parsing while reading), and thus avoid the need to call the whole convertBytes method again, but that's a big change and there is a risk getting wrong somewhere. This fix is likely to be backported to older LTS releases.
>>> 
>>> Note this could block but it should only happen when data is not enough, and it only reads one byte.
>>> 
>>> The test included in the bug report passed, but I'll see if I can write a new test not depending on any existing binary data.
>>> 
>>> And I'm running a mach5 test job now.
>>> 
>>> Thanks,
>>> Max
>>> 


From weijun.wang at oracle.com  Sat Mar 30 15:01:18 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 30 Mar 2019 23:01:18 +0800
Subject: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong
 Case
In-Reply-To: <1550666474.2433.13.camel@paratix.ch>
References: <1550666474.2433.13.camel@paratix.ch>
Message-ID: <59102068-56D8-462C-AA7B-DB129F9D082B@oracle.com>

Hi Philipp,

Sorry I'm so late giving a response. I've filed

   https://bugs.openjdk.java.net/browse/JDK-8221719
   Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case

The fix is good. Since we don't support identitydb anymore I think we can remove the parenthesis around the alias in the storeHash now.

Thanks,
Max

> On Feb 20, 2019, at 8:41 PM, Philipp Kunz <philipp.kunz at paratix.ch> wrote:
> 
> Hi,
> 
> When signing a jarfile the specified alias is converted by JavaKeyStore (storetype JKS) to lower case.
> When verifying the jarfile with the same alias, it is currently not converted by JKS to lower case and jarsigner reports that the jar is not signed by the alias even after having just signed it with that same alias if not all characters are in lower case.
> 
> I found no statement in the documentation that an alias would support only lower case or which characters could be used. It could, however, be worth noting in the documentation of JavaKeyStore or the keytool that the alias can be changed by the keystore in certain circumstances.
> In my opinion, it feels like a bug that aliases are treated differently when signing and verifying with respect to their upper and lower case.
> 
> Find a patch attached. Some explanations, just in case not too obvious anyway:
> 
> - The jarsigner never changed the upper and lower cases of aliases itself and neither does with the patch. That is now delegated to the keystore implementation not only for signing but in addition also for verifying. The fix is therefore not JSK-specific.
> - I assume it is correct that the if (store != null) check and the try catch KeyStoreException can both be moved outside the for loop over the certificates because before as well as now with the patch the result was alway 0 if store was null and KeyStoreException can happen only when loading the keystore, which is certainly true for JKS.
> - storeHash is used only by printCert and inKeyStoreForOneSigner and contains the aliases as values enclosed in parentheses "(" and ")" which is how it is printed by printCert. It would have probably been easier to add the parentheses only later in printCert but then I tried to change as little as possible.
> - Two pairs of "result |= " statements were duplicate. Therefore there are the two methods in the test which show that both actually failed with "ckaliases.contains" being the offending piece of code. In the patch I refactored to recombine them.
> - I really wonder how "result |= SIGNED_BY_ALIAS;" should be set for any certificate c and not only the one an alias in ckaliases points at but I guess that is another story if one at all and might have come from filling storeHash with all certificates and not only the ones in ckaliases or so.
> - At first glance it might look like a mistake that "alias" is not used inside the loop over ckaliases but instead of comparing "alias" in lower case to ckaliases with unspecified case, the certificate c is now compared to the one gotten from the keystore handling the alias case in its own way.
> 
> Would someone sponsor this fix or can/should it be improved?
> 
> Regards,
> Philipp
> <JavaKeyStoreAliasCaseInsensitive.patch>


From raell at web.de  Tue Mar 26 10:18:47 2019
From: raell at web.de (raell at web.de)
Date: Tue, 26 Mar 2019 10:18:47 -0000
Subject: Release plan for ChaCha20/Poly1305 cipher suite
In-Reply-To: <b9cf5cb9-0850-0497-b283-bce6d0ead23d@oracle.com>
References: <trinity-56faa43e-1488-4185-bf3a-3fcffb331d40-1553555879570@3c-app-webde-bap09>
 <b9cf5cb9-0850-0497-b283-bce6d0ead23d@oracle.com>
Message-ID: <trinity-e3703620-628a-45c6-abcd-fe06e85ebcda-1553595514002@3c-app-webde-bap45>

Great! Thank you Bradford and  Jamil.
?
-- Ralph 
?

On 3/26 0:14:24 AM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote: 
>Please see the SunJSSE provider documentation for JDK 12.
>
>https://docs.oracle.com/en/java/javase/12/security/oracle-providers.html#GUID-7093246A-31A3-4304-AC5F-5FB6400405E2
>
>Brad
>
>
>On 3/25/2019 4:17 PM, raell at web.de wrote:
>> Dear,
>>
>> in Java 11 (JEP 329) ChaCha20 and Poly1305 cryptographic algorithms had been implemented. However, the cipher suite TLS_CHACHA20_POLY1305_SHA256 wasn't added to the Java standard cipher suites. As far as I can see, support for this cipher suite is neither part of Java 12.
>>
>> Out of interest: Is there a plan in which Java release the cipher suite will be supported.
>>
>> Thanks and regards,
>>
>> Ralph
>>