From sean.mullan at oracle.com  Mon Aug  1 18:26:21 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 1 Aug 2016 14:26:21 -0400
Subject: Review Request: JDK-8162882: Permission merge issue in
	jdk.crypto.ucrypto module
Message-ID: <d81d6bf3-f464-8d15-1bd0-2f8073b7df35@oracle.com>

The fix for JDK-8159752 accidentally put back an older version of the 
policy permissions for the jdk.crypto.ucrypto module. It is a simple fix 
to restore the correct permission:

diff -r 5584be31a8f9 src/java.base/solaris/lib/security/default.policy
--- a/src/java.base/solaris/lib/security/default.policy	Mon Aug 01 
09:58:36 2016 -0400
+++ b/src/java.base/solaris/lib/security/default.policy	Mon Aug 01 
14:23:51 2016 -0400
@@ -11,6 +11,6 @@
                     "clearProviderProperties.OracleUcrypto";
      permission java.security.SecurityPermission
                     "removeProviderProperty.OracleUcrypto";
-    permission java.io.FilePermission
-                   "${java.home}/conf/security/ucrypto-solaris.cfg", 
"read";
+    // Needed for reading Ucrypto config file
+    permission java.io.FilePermission "<<ALL FILES>>", "read";
  };

Thanks,
Sean


From valerie.peng at oracle.com  Mon Aug  1 20:45:15 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 1 Aug 2016 13:45:15 -0700
Subject: Review Request: JDK-8162882: Permission merge issue in
	jdk.crypto.ucrypto module
In-Reply-To: <d81d6bf3-f464-8d15-1bd0-2f8073b7df35@oracle.com>
References: <d81d6bf3-f464-8d15-1bd0-2f8073b7df35@oracle.com>
Message-ID: <29faa1d0-b6be-b690-a7f2-ef04a74e190d@oracle.com>

Looks fine.
Thanks,
Valerie

On 8/1/2016 11:26 AM, Sean Mullan wrote:
> The fix for JDK-8159752 accidentally put back an older version of the 
> policy permissions for the jdk.crypto.ucrypto module. It is a simple 
> fix to restore the correct permission:
>
> diff -r 5584be31a8f9 src/java.base/solaris/lib/security/default.policy
> --- a/src/java.base/solaris/lib/security/default.policy    Mon Aug 01 
> 09:58:36 2016 -0400
> +++ b/src/java.base/solaris/lib/security/default.policy    Mon Aug 01 
> 14:23:51 2016 -0400
> @@ -11,6 +11,6 @@
>                     "clearProviderProperties.OracleUcrypto";
>      permission java.security.SecurityPermission
>                     "removeProviderProperty.OracleUcrypto";
> -    permission java.io.FilePermission
> - "${java.home}/conf/security/ucrypto-solaris.cfg", "read";
> +    // Needed for reading Ucrypto config file
> +    permission java.io.FilePermission "<<ALL FILES>>", "read";
>  };
>
> Thanks,
> Sean



From ecki at zusammenkunft.net  Mon Aug  1 22:13:02 2016
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 2 Aug 2016 00:13:02 +0200
Subject: RFC7525 mapped to JSSE
Message-ID: <20160802001302.00005374.ecki@zusammenkunft.net>

Hello,

because I was asked by a customer I started to map the RFC7525

https://tools.ietf.org/html/rfc7525

recommendations for TLS to JSSE implementation.


It is not complete yet but I think I at least have extraced all
"normative" requirements from the RFC into this table:

https://docs.google.com/spreadsheets/d/135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE

would like to get your feedback.

Gruss
Bernd


From artem.smotrakov at oracle.com  Tue Aug  2 01:25:38 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Mon, 1 Aug 2016 18:25:38 -0700
Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on
	timeout
In-Reply-To: <67fd1bb2-35d2-2c15-6c76-5133e084b461@oracle.com>
References: <5771CEF7.8060400@oracle.com>
	<694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com>
	<67fd1bb2-35d2-2c15-6c76-5133e084b461@oracle.com>
Message-ID: <59082443-e0ec-165c-d9f6-d337600fe38f@oracle.com>

Here is an updated webrev which includes a fix for 8161086 (thanks 
Xuelei for help):
- No updates to the problem list
- CustomDatagramSocketImplFactory drops 5% of packets by default
- Updated DTLSInputRecord and DTLSOutputRecord to print sequence numbers 
if -Djavax.net.debug=ssl option is specified
- Updated InvalidRecords.java tests not to drop packets by default 
because handshaking unexpectedly succeeds if an invalid packet was dropped

http://cr.openjdk.java.net/~asmotrak/8159416/webrev.03/

Please take a look.

Artem

On 07/28/2016 04:36 PM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> I updated CustomDatagramSocketImpl class to be able to drop some 
> packets randomly or by specified numbers.
>
> While updating the test, I found 
> https://bugs.openjdk.java.net/browse/JDK-8161086 which I think is the 
> root cause of these intermittent failures.
>
> I added a couple of PacketLoss* tests to reproduce and verify 8161086. 
> These tests drop different packets while handshaking. They use 
> different cipher suites and modes, so that they take a while. I didn't 
> notice they fail with timeout, but I suspect that may happen on slower 
> machines. That's why I increased timeout value for them. I added the 
> tests to the problem list since 8161086 is not fixed yet.
>
> There are a couple of other updates to DTLSOverDatagram.java:
> - Server tries to receive first application data when it finishes 
> handshaking. Server re-sends final handshaking messages if timeout 
> reached while waiting for application data from client.
> - Updated client and server to use simple threads instead of thread 
> pools. This way, it's possible to specify meaningful names for threads 
> which makes logs more readable if "-Djavax.net.debug=ssl" specified
> - Added more logging
> - Made some fields final
>
> At the moment, CustomDatagramSocketImplFactory doesn't drop packets by 
> default because it may cause intermittent failures of tests which are 
> based on DTLSOverDatagram class:
>
> ...
>     static class CustomDatagramSocketImplFactory
>                 implements DatagramSocketImplFactory {
> ...
>     // if true, it's going to drop some packets
>     private static boolean dropPackets = false;
> ...
>
> When 8161086 is fixed, it may be set to true by default. Currently the 
> packet loss rate is 5% which I think is much more than if we use UDP 
> sockets on localhost, so that we test DTLS impl in worse conditions.
>
> Could you please take a look at updated webrev?
>
> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/
>
> Artem
>
> On 06/27/2016 06:25 PM, Xuelei Fan wrote:
>> On 6/28/2016 9:12 AM, Artem Smotrakov wrote:
>>> Hello,
>>>
>>> Please review this patch for javax/net/ssl/DTLS tests.
>>>
>>> A couple of DTLS tests fail intermittently on Mac with timeout or "Too
>>> many handshake loops ..." error. The tests use UDP to transfer DTLS
>>> records. It happens sometimes that server cannot receive UDP packets
>>> with DatagramSocket.receive() method even if client tries to re-send
>>> them multiple times. Please see logs in the bug.
>>>
>>> At the moment, it is not clear why UDP packets can't be delivered to
>>> server. If someone has seen something similar before, or has some ideas
>>> what might be the root cause, please let me know.
>>>
>> UDP is not reliable.  It could happen that the packets get lost.
>>
>>> I think that the tests and DTLS implementation are fine here. Since the
>>> tests are for DTLS, we can workaround this issue by avoiding real UDP
>>> connections. To avoid changing test logic much, we can use a custom
>>> DatagramSocketImpl and DatagramSocketImplFactory implementations to
>>> replace system UDP implementation.
>>>
>>> The patch below updates the tests with the following:
>>> - added custom DatagramSocketImpl and DatagramSocketImplFactory
>>> implementations to avoid real UDP connections
>> Tests for real connections in practice are needed.  If we update this
>> test this way, we need to add other tests to test real application
>> usage.  I don't think this is the right direction to avoid real UDP
>> connections.
>>
>>> - added more test output, so that we can have more info it the tests
>>> fail again
>>>
>> I agree with this point.
>>
>> Xuelei
>>
>>> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac,
>>> and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on
>>> all supported generic platforms, and they worked fine.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416
>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/
>>>
>>> Artem
>



From xuelei.fan at oracle.com  Tue Aug  2 04:35:29 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 2 Aug 2016 12:35:29 +0800
Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on
	timeout
In-Reply-To: <59082443-e0ec-165c-d9f6-d337600fe38f@oracle.com>
References: <5771CEF7.8060400@oracle.com>
	<694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com>
	<67fd1bb2-35d2-2c15-6c76-5133e084b461@oracle.com>
	<59082443-e0ec-165c-d9f6-d337600fe38f@oracle.com>
Message-ID: <d743b82c-a16f-e660-29d7-4164b64fefd7@oracle.com>

DTLSOutputRecord
----------------
 182   int len = destination.remaining();
 235   int len = destination.remaining();

This variable is only use by debug block.  I may try to avoid to define
it out side of the debug block.  I know you want to dump the length in
the "record" debug option.  But I think the epoch/sequence# belong to
the "packet" debug option.  The "record" option does not include the
header part, so may be, it is not suitable to dump the epoch/seq# here.

I may suggest to remove the update as the "packet" option can help if
users want to know the epoch/sequence numbers.  Please see the comment
for DTLSOverDatagram.java, too.

466-470
This is a nice update to get the user friendly handshake type
description.  There are still a lot similar debug log that need to get
similar update.  Would you mind to file a new RFE, and make the update
together with other places (both TLS and DTLS) all together?


DTLSInputRecord
---------------
 159    long onlySeqNum  =
            Authenticator.getDTLSSequenceNumber(recordEnS);

Using getDTLSSequenceNumber(long) may be more effective.

161-165, if you consider to remove the debug log update in
DTLSOutputRecord, you may also want to remove the debug log update here
for similar reasons.

HandshakeMessage
----------------
See comment for DTLSOutputRecord.  I may prefer to file a new RFE, and
make the update all together.


Authenticator
-------------
May not need the update any more if you consider my suggestions above.
Otherwise, I think may be only

   getDTLSSequenceNumber(long recordEnS)

is actually used.  Other two new methods can be removed.


InvalidRecords
--------------
I like this find!


DTLSOverDatagram
----------------

50         System.setProperty("javax.net.debug", "ssl,record");

I may suggest to use "ssl,record,packet" for debugging if you won't dump
the epoch/seq# in "record" debug option.  If the test passed, I may
prefer to turn the debug log off.


doServerSide()
I did not get too much about the update:
1. Is it necessary to combine handshake and reading client application
data together?
   I think the receiveAppData can be reused.

2. Is it necessary to re-send application data?
   I think if application data is not allowed to drop, may not need to
the re-send code.

Same for the doClientSide() implementation.

disablePacketDrop() is a static method, you may not want to call it
exception the initialization stage.  The following line need to be very
carefully used:

 162   CustomDatagramSocketImplFactory.disablePacketDrop();
 334   CustomDatagramSocketImplFactory.disablePacketDrop();


324-375, may be not necessary, or can be improved to use
receiveAppData() method instead.  I think the wrap() and unwrap() impl
should take care of the retransmission of handshaking messages, but not
the application.  Resending the previous packet does not comply to DTLS
retransmission specification.  If you run into problems, would you mind
show me the debug log?

>> - Updated client and server to use simple threads instead of thread
>> pools. This way, it's possible to specify meaningful names for
>> threads
A more light update may be use Thread.setName(String name) in the
ServerCallable.call().  I did not test.  If you like, you can have a try.


CustomDatagramSocketImpl.addPacket()
I may suggest to check application data here.

     927     private void addPacket(byte[] data) {
     928         // check if a packet should be dropped
-    929         if (CustomDatagramSocketImplFactory.losePacket()) {
+                if (ustomDatagramSocketImplFactory.losePacket() &&
+                        (data[0] != (byte)0x17)) {
     930             return;
     931         }

"data[0] != (byte)0x17" means that it is not application data.  As would
simplify the code a lot.  See comments above about the application data
re-sending issue.


PacketLossXXX.java
------------------
It should not be the common case to split test cases separated with the
test code.  I would suggest merge them into the PacketLoss.java.  If you
are worrying about the debug log length, please turn off the debug log.
Actually, we should turn off the debug log unless we need more detailed
debug log for problematic test.  Or alternatively, we can ask the JTREG
to consider the behavior more about the debug length restrictions.

Thanks,
Xuelei

On 8/2/2016 9:25 AM, Artem Smotrakov wrote:
> Here is an updated webrev which includes a fix for 8161086 (thanks
> Xuelei for help):
> - No updates to the problem list
> - CustomDatagramSocketImplFactory drops 5% of packets by default
> - Updated DTLSInputRecord and DTLSOutputRecord to print sequence numbers
> if -Djavax.net.debug=ssl option is specified
> - Updated InvalidRecords.java tests not to drop packets by default
> because handshaking unexpectedly succeeds if an invalid packet was dropped
> 
> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.03/
> 
> Please take a look.
> 
> Artem
> 
> On 07/28/2016 04:36 PM, Artem Smotrakov wrote:
>> Hi Xuelei,
>>
>> I updated CustomDatagramSocketImpl class to be able to drop some
>> packets randomly or by specified numbers.
>>
>> While updating the test, I found
>> https://bugs.openjdk.java.net/browse/JDK-8161086 which I think is the
>> root cause of these intermittent failures.
>>
>> I added a couple of PacketLoss* tests to reproduce and verify 8161086.
>> These tests drop different packets while handshaking. They use
>> different cipher suites and modes, so that they take a while. I didn't
>> notice they fail with timeout, but I suspect that may happen on slower
>> machines. That's why I increased timeout value for them. I added the
>> tests to the problem list since 8161086 is not fixed yet.
>>
>> There are a couple of other updates to DTLSOverDatagram.java:
>> - Server tries to receive first application data when it finishes
>> handshaking. Server re-sends final handshaking messages if timeout
>> reached while waiting for application data from client.
>> - Updated client and server to use simple threads instead of thread
>> pools. This way, it's possible to specify meaningful names for threads
>> which makes logs more readable if "-Djavax.net.debug=ssl" specified
>> - Added more logging
>> - Made some fields final
>>
>> At the moment, CustomDatagramSocketImplFactory doesn't drop packets by
>> default because it may cause intermittent failures of tests which are
>> based on DTLSOverDatagram class:
>>
>> ...
>>     static class CustomDatagramSocketImplFactory
>>                 implements DatagramSocketImplFactory {
>> ...
>>     // if true, it's going to drop some packets
>>     private static boolean dropPackets = false;
>> ...
>>
>> When 8161086 is fixed, it may be set to true by default. Currently the
>> packet loss rate is 5% which I think is much more than if we use UDP
>> sockets on localhost, so that we test DTLS impl in worse conditions.
>>
>> Could you please take a look at updated webrev?
>>
>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/
>>
>> Artem
>>
>> On 06/27/2016 06:25 PM, Xuelei Fan wrote:
>>> On 6/28/2016 9:12 AM, Artem Smotrakov wrote:
>>>> Hello,
>>>>
>>>> Please review this patch for javax/net/ssl/DTLS tests.
>>>>
>>>> A couple of DTLS tests fail intermittently on Mac with timeout or "Too
>>>> many handshake loops ..." error. The tests use UDP to transfer DTLS
>>>> records. It happens sometimes that server cannot receive UDP packets
>>>> with DatagramSocket.receive() method even if client tries to re-send
>>>> them multiple times. Please see logs in the bug.
>>>>
>>>> At the moment, it is not clear why UDP packets can't be delivered to
>>>> server. If someone has seen something similar before, or has some ideas
>>>> what might be the root cause, please let me know.
>>>>
>>> UDP is not reliable.  It could happen that the packets get lost.
>>>
>>>> I think that the tests and DTLS implementation are fine here. Since the
>>>> tests are for DTLS, we can workaround this issue by avoiding real UDP
>>>> connections. To avoid changing test logic much, we can use a custom
>>>> DatagramSocketImpl and DatagramSocketImplFactory implementations to
>>>> replace system UDP implementation.
>>>>
>>>> The patch below updates the tests with the following:
>>>> - added custom DatagramSocketImpl and DatagramSocketImplFactory
>>>> implementations to avoid real UDP connections
>>> Tests for real connections in practice are needed.  If we update this
>>> test this way, we need to add other tests to test real application
>>> usage.  I don't think this is the right direction to avoid real UDP
>>> connections.
>>>
>>>> - added more test output, so that we can have more info it the tests
>>>> fail again
>>>>
>>> I agree with this point.
>>>
>>> Xuelei
>>>
>>>> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac,
>>>> and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on
>>>> all supported generic platforms, and they worked fine.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416
>>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/
>>>>
>>>> Artem
>>
> 



From xuelei.fan at oracle.com  Tue Aug  2 15:34:38 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 2 Aug 2016 23:34:38 +0800
Subject: Code Review Request JDK-8162362, Cannot enable previously default
	enabled cipher suites
In-Reply-To: <cda84bd9-56dd-3f61-2d91-9775528627e5@oracle.com>
References: <cda84bd9-56dd-3f61-2d91-9775528627e5@oracle.com>
Message-ID: <44fa2f16-55b9-59f7-44f0-b83d259e7980@oracle.com>

Ping ...

On 7/29/2016 11:23 PM, Xuelei Fan wrote:
> Hi,
> 
> Please review the fix for JDK-8162362:
> 
>    http://cr.openjdk.java.net/~xuelei/8162362/webrev.00/
> 
> If a cipher suite is getting weak or vulnerable, it is normally removed
> from the default enabled list in JDK.  The compatibility impact of the
> removing is normally minimal as if there are other available cipher
> suites enabled.
> 
> However, some applications may want to support the disabled cipher
> suites in JDK.  If the source code is not accessible, there is not much
> workaround to have the cipher suite back to work if it is removed from
> the default enabled list in JDK.
> 
> This fix introduces two new system properties, which can be used to
> customize the default enabled cipher suites.
> 
> The system property "jdk.tls.client.cipherSuites" is used to customize
> the default enabled cipher suites for client side of SSL/TLS/DTLS
> connections. Similarly, the system property
> "jdk.tls.server.cipherSuites" is used for server side.
> 
> The system property contains a comma-separated list of supported cipher
> suite names specifying the default enabled cipher suites.  All other
> supported cipher suites are disabled for this default setting.
> Unrecognized or unsupported cipher suite name specified in the property
> is ignored.  Explicit setting of enabled cipher suites will override the
> system property.
> 
> Thanks,
> Xuelei
> 



From artem.smotrakov at oracle.com  Tue Aug  2 21:42:01 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 2 Aug 2016 14:42:01 -0700
Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on
	timeout
In-Reply-To: <d743b82c-a16f-e660-29d7-4164b64fefd7@oracle.com>
References: <5771CEF7.8060400@oracle.com>
	<694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com>
	<67fd1bb2-35d2-2c15-6c76-5133e084b461@oracle.com>
	<59082443-e0ec-165c-d9f6-d337600fe38f@oracle.com>
	<d743b82c-a16f-e660-29d7-4164b64fefd7@oracle.com>
Message-ID: <4f1f89f5-8d15-7db2-c891-39a4079edc24@oracle.com>

Hi Xuelei,

Thank you for review. Please see inline. I'll send an updated webrev soon.

On 08/01/2016 09:35 PM, Xuelei Fan wrote:
> DTLSOutputRecord
> ----------------
>   182   int len = destination.remaining();
>   235   int len = destination.remaining();
>
> This variable is only use by debug block.  I may try to avoid to define
> it out side of the debug block.
encrypt() changes "destination" buffer, that's why the "len" variable is 
defined before it. Probably the length may be calculated some other way. 
I don't like it much either, but this way is just the most simple and 
straightforward to me.
> I know you want to dump the length in
> the "record" debug option.  But I think the epoch/sequence# belong to
> the "packet" debug option.  The "record" option does not include the
> header part, so may be, it is not suitable to dump the epoch/seq# here.
>
> I may suggest to remove the update as the "packet" option can help if
> users want to know the epoch/sequence numbers.  Please see the comment
> for DTLSOverDatagram.java, too.
If -Djavax.net.debug=packet is set, then it prints something like the 
following:

[Raw write]: length = 135
0000: 16 FE FD 00 00 00 00 00   00 00 00 00 7A 01 00 00 ............z...
0010: 6E 00 00 00 00 00 00 00   6E FE FD 18 E3 9C 82 DF n.......n.......
0020: 02 6C 42 FF AB EE 0C 9A   82 1B 78 6A 31 93 DC 6A .lB.......xj1..j
0030: DC 70 9F 5A 91 DB D5 04   E1 99 65 00 00 00 02 00 .p.Z......e.....
0040: 3C 01 00 00 42 00 0D 00   1C 00 1A 06 03 06 01 05 <...B...........
0050: 03 05 01 04 03 04 01 04   02 03 03 03 01 03 02 02 ................
0060: 03 02 01 02 02 00 11 00   10 00 0E 02 00 04 00 00 ................
0070: 00 00 01 00 04 00 00 00   00 00 05 00 05 01 00 00 ................
0080: 00 00 FF 01 00 01 00                               .......

Well ... I am sure that such a dump contains everything we need, but ... 
it doesn't look really friendly :) If someone is not an expert in 
TLS/DTLS like me, than it might be helpful to have some thing more 
human-readable in logs :) That's why I wanted to print sequence and 
epoch numbers (it helped me while looking into 8161086).
>
> 466-470
> This is a nice update to get the user friendly handshake type
> description.  There are still a lot similar debug log that need to get
> similar update.  Would you mind to file a new RFE, and make the update
> together with other places (both TLS and DTLS) all together?
Sure, I filed https://bugs.openjdk.java.net/browse/JDK-8162996

I'll revert all changes related to debut output. They may be integrated 
in the RFE above.
>
>
> DTLSInputRecord
> ---------------
>   159    long onlySeqNum  =
>              Authenticator.getDTLSSequenceNumber(recordEnS);
>
> Using getDTLSSequenceNumber(long) may be more effective.
>
> 161-165, if you consider to remove the debug log update in
> DTLSOutputRecord, you may also want to remove the debug log update here
> for similar reasons.
>
> HandshakeMessage
> ----------------
> See comment for DTLSOutputRecord.  I may prefer to file a new RFE, and
> make the update all together.
>
>
> Authenticator
> -------------
> May not need the update any more if you consider my suggestions above.
> Otherwise, I think may be only
>
>     getDTLSSequenceNumber(long recordEnS)
>
> is actually used.  Other two new methods can be removed.
>
>
> InvalidRecords
> --------------
> I like this find!
>
>
> DTLSOverDatagram
> ----------------
>
> 50         System.setProperty("javax.net.debug", "ssl,record");
>
> I may suggest to use "ssl,record,packet" for debugging if you won't dump
> the epoch/seq# in "record" debug option.  If the test passed, I may
> prefer to turn the debug log off.
The tests pass now. I don't mind removing this debug output, but it 
happens often that we don't have enough info if a test fails 
intermittently. Then, we may update the test to use -Djavax.net.debug to 
get more info when it fails next time. I think it might be good to 
enable debug output for tests by default, so that we have more info to 
analyze failures. As far as I know, jtreg may be configured to keep jtr 
files only for failed tests, so additional output shouldn't take much 
space if someone runs these test often. Is there any other concerns?
> doServerSide()
> I did not get too much about the update:
> 1. Is it necessary to combine handshake and reading client application
> data together?
Final handshake messages to a client may be lost. Client still will be 
expecting them, and server needs to re-send them. When server is done 
with handshaking, it tries to receive first application data. But if 
client didn't receive final handshake messages (because they were lost), 
it keeps re-sending handshake messages to server. In this situation, 
server needs to re-send final handshake messages to client. Those 
messages are easily accessible while we're in handshake() method, so 
that's why I added reading first application data there. handshake() 
method may return final handshake packets to the caller, so that it can 
re-send them if necessary. This is just another way, I don't think any 
of them is better that another.
>     I think the receiveAppData can be reused.
I don't think it can be re-used "as is" because it needs to re-send 
final handshake messages on server side. Okay, I'll update the method, 
and re-use it.
>
> 2. Is it necessary to re-send application data?
>     I think if application data is not allowed to drop, may not need to
> the re-send code.
You're right. I'll remove those while loops.
>
> Same for the doClientSide() implementation.
>
> disablePacketDrop() is a static method, you may not want to call it
> exception the initialization stage.  The following line need to be very
> carefully used:
>
>   162   CustomDatagramSocketImplFactory.disablePacketDrop();
>   334   CustomDatagramSocketImplFactory.disablePacketDrop();
disablePacketDrop() asks CustomDatagramSocketImpl to stop dropping 
packets. This method should be called before we start sending 
application data. It seems like one of these disablePacketDrop() calls 
is redundant, I'll move it to sendAppData() method.
>
> 324-375, may be not necessary, or can be improved to use
> receiveAppData() method instead.
Sure, will do, please see above.
>    I think the wrap() and unwrap() impl
> should take care of the retransmission of handshaking messages, but not
> the application.  Resending the previous packet does not comply to DTLS
> retransmission specification.  If you run into problems, would you mind
> show me the debug log?
I am not sure what logs you are asking about. You can find some logs 
attached to https://bugs.openjdk.java.net/browse/JDK-8159416

I am also not sure what you mean by retransmission here. As far as I 
understand, wrap() and unwrap() methods produce/consume (D)TLS records, 
and client code should take care of sending them over the network to the 
remote peer. While expecting first application data, the test re-sends 
the same packets which were generated by last wrap() call on server 
side. This means that DTLS records with the same sequence numbers are 
used again.

Do you think that server should generate records with new sequence numbers?

(I have not tried to call wrap() again to produce final handshake 
message after server's SSLEngine has finished handshaking, not sure if 
it works)

>
>>> - Updated client and server to use simple threads instead of thread
>>> pools. This way, it's possible to specify meaningful names for
>>> threads
> A more light update may be use Thread.setName(String name) in the
> ServerCallable.call().  I did not test.  If you like, you can have a try.
setName() method is not static, so it should be called on an instance of 
Thread, but I don't know how to access it in ServerCallable.call() method.
>
>
> CustomDatagramSocketImpl.addPacket()
> I may suggest to check application data here.
>
>       927     private void addPacket(byte[] data) {
>       928         // check if a packet should be dropped
> -    929         if (CustomDatagramSocketImplFactory.losePacket()) {
> +                if (ustomDatagramSocketImplFactory.losePacket() &&
> +                        (data[0] != (byte)0x17)) {
>       930             return;
>       931         }
>
> "data[0] != (byte)0x17" means that it is not application data.  As would
> simplify the code a lot.  See comments above about the application data
> re-sending issue.
It wouldn't simplify the code to me because "0x17" looks like a magic 
number. Of course, we can define it as a constant with some meaningful 
name, but to me it is clearer to call a method which just stops dropping 
packets. It doesn't make the code too complicated to me. If you don't 
mind, and there is no other issues with it, I would prefer to keep it.
>
>
> PacketLossXXX.java
> ------------------
> It should not be the common case to split test cases separated with the
> test code.  I would suggest merge them into the PacketLoss.java.
The problem here is that those test take some time for execution. That's 
why I splitted them to different files.

As far as I remember, there was a concern from people who run those 
tests in CI systems that some tests take too long. Their point was that 
tests execution may be faster if we run tests in concurrent mode, and 
don't have tests which take too long. And if I recall correctly, there 
was an agreement that we split such tests this way.

I am cc'ing Rajan, he may remember more about this.

Artem
>    If you
> are worrying about the debug log length, please turn off the debug log.
> Actually, we should turn off the debug log unless we need more detailed
> debug log for problematic test.  Or alternatively, we can ask the JTREG
> to consider the behavior more about the debug length restrictions.
>
> Thanks,
> Xuelei
>
> On 8/2/2016 9:25 AM, Artem Smotrakov wrote:
>> Here is an updated webrev which includes a fix for 8161086 (thanks
>> Xuelei for help):
>> - No updates to the problem list
>> - CustomDatagramSocketImplFactory drops 5% of packets by default
>> - Updated DTLSInputRecord and DTLSOutputRecord to print sequence numbers
>> if -Djavax.net.debug=ssl option is specified
>> - Updated InvalidRecords.java tests not to drop packets by default
>> because handshaking unexpectedly succeeds if an invalid packet was dropped
>>
>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.03/
>>
>> Please take a look.
>>
>> Artem
>>
>> On 07/28/2016 04:36 PM, Artem Smotrakov wrote:
>>> Hi Xuelei,
>>>
>>> I updated CustomDatagramSocketImpl class to be able to drop some
>>> packets randomly or by specified numbers.
>>>
>>> While updating the test, I found
>>> https://bugs.openjdk.java.net/browse/JDK-8161086 which I think is the
>>> root cause of these intermittent failures.
>>>
>>> I added a couple of PacketLoss* tests to reproduce and verify 8161086.
>>> These tests drop different packets while handshaking. They use
>>> different cipher suites and modes, so that they take a while. I didn't
>>> notice they fail with timeout, but I suspect that may happen on slower
>>> machines. That's why I increased timeout value for them. I added the
>>> tests to the problem list since 8161086 is not fixed yet.
>>>
>>> There are a couple of other updates to DTLSOverDatagram.java:
>>> - Server tries to receive first application data when it finishes
>>> handshaking. Server re-sends final handshaking messages if timeout
>>> reached while waiting for application data from client.
>>> - Updated client and server to use simple threads instead of thread
>>> pools. This way, it's possible to specify meaningful names for threads
>>> which makes logs more readable if "-Djavax.net.debug=ssl" specified
>>> - Added more logging
>>> - Made some fields final
>>>
>>> At the moment, CustomDatagramSocketImplFactory doesn't drop packets by
>>> default because it may cause intermittent failures of tests which are
>>> based on DTLSOverDatagram class:
>>>
>>> ...
>>>      static class CustomDatagramSocketImplFactory
>>>                  implements DatagramSocketImplFactory {
>>> ...
>>>      // if true, it's going to drop some packets
>>>      private static boolean dropPackets = false;
>>> ...
>>>
>>> When 8161086 is fixed, it may be set to true by default. Currently the
>>> packet loss rate is 5% which I think is much more than if we use UDP
>>> sockets on localhost, so that we test DTLS impl in worse conditions.
>>>
>>> Could you please take a look at updated webrev?
>>>
>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/
>>>
>>> Artem
>>>
>>> On 06/27/2016 06:25 PM, Xuelei Fan wrote:
>>>> On 6/28/2016 9:12 AM, Artem Smotrakov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this patch for javax/net/ssl/DTLS tests.
>>>>>
>>>>> A couple of DTLS tests fail intermittently on Mac with timeout or "Too
>>>>> many handshake loops ..." error. The tests use UDP to transfer DTLS
>>>>> records. It happens sometimes that server cannot receive UDP packets
>>>>> with DatagramSocket.receive() method even if client tries to re-send
>>>>> them multiple times. Please see logs in the bug.
>>>>>
>>>>> At the moment, it is not clear why UDP packets can't be delivered to
>>>>> server. If someone has seen something similar before, or has some ideas
>>>>> what might be the root cause, please let me know.
>>>>>
>>>> UDP is not reliable.  It could happen that the packets get lost.
>>>>
>>>>> I think that the tests and DTLS implementation are fine here. Since the
>>>>> tests are for DTLS, we can workaround this issue by avoiding real UDP
>>>>> connections. To avoid changing test logic much, we can use a custom
>>>>> DatagramSocketImpl and DatagramSocketImplFactory implementations to
>>>>> replace system UDP implementation.
>>>>>
>>>>> The patch below updates the tests with the following:
>>>>> - added custom DatagramSocketImpl and DatagramSocketImplFactory
>>>>> implementations to avoid real UDP connections
>>>> Tests for real connections in practice are needed.  If we update this
>>>> test this way, we need to add other tests to test real application
>>>> usage.  I don't think this is the right direction to avoid real UDP
>>>> connections.
>>>>
>>>>> - added more test output, so that we can have more info it the tests
>>>>> fail again
>>>>>
>>>> I agree with this point.
>>>>
>>>> Xuelei
>>>>
>>>>> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on Mac,
>>>>> and I didn't see it failed. I also have run javax/net/ssl/DTLS tests on
>>>>> all supported generic platforms, and they worked fine.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416
>>>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/
>>>>>
>>>>> Artem



From valerie.peng at oracle.com  Tue Aug  2 22:04:43 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 2 Aug 2016 15:04:43 -0700
Subject: [9] RFR 8154113: java.security.AccessControlException: access denied
	("java.security.SecurityPermission" "authProvider.SunMSCAPI")
Message-ID: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>

Sean,

Would you be able to review this policy update for SunMSCAPI provider? 
In addition to the policy update, the test is updated to replace the 
shell script with @run tags.

Bug: https://bugs.openjdk.java.net/browse/JDK-8154113
Webrev: http://cr.openjdk.java.net/~valeriep/8154113/webrev.00/

Thanks,
Valerie


From artem.smotrakov at oracle.com  Tue Aug  2 22:10:54 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 2 Aug 2016 15:10:54 -0700
Subject: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on
	timeout
In-Reply-To: <4f1f89f5-8d15-7db2-c891-39a4079edc24@oracle.com>
References: <5771CEF7.8060400@oracle.com>
	<694f0a14-d67c-567b-e665-d5c71c7c7331@oracle.com>
	<67fd1bb2-35d2-2c15-6c76-5133e084b461@oracle.com>
	<59082443-e0ec-165c-d9f6-d337600fe38f@oracle.com>
	<d743b82c-a16f-e660-29d7-4164b64fefd7@oracle.com>
	<4f1f89f5-8d15-7db2-c891-39a4079edc24@oracle.com>
Message-ID: <896290b8-43e0-6125-16b7-db38a041823f@oracle.com>

Please see an updated webrev

http://cr.openjdk.java.net/~asmotrak/8159416/webrev.04/

Artem


On 08/02/2016 02:42 PM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> Thank you for review. Please see inline. I'll send an updated webrev 
> soon.
>
> On 08/01/2016 09:35 PM, Xuelei Fan wrote:
>> DTLSOutputRecord
>> ----------------
>>   182   int len = destination.remaining();
>>   235   int len = destination.remaining();
>>
>> This variable is only use by debug block.  I may try to avoid to define
>> it out side of the debug block.
> encrypt() changes "destination" buffer, that's why the "len" variable 
> is defined before it. Probably the length may be calculated some other 
> way. I don't like it much either, but this way is just the most simple 
> and straightforward to me.
>> I know you want to dump the length in
>> the "record" debug option.  But I think the epoch/sequence# belong to
>> the "packet" debug option.  The "record" option does not include the
>> header part, so may be, it is not suitable to dump the epoch/seq# here.
>>
>> I may suggest to remove the update as the "packet" option can help if
>> users want to know the epoch/sequence numbers.  Please see the comment
>> for DTLSOverDatagram.java, too.
> If -Djavax.net.debug=packet is set, then it prints something like the 
> following:
>
> [Raw write]: length = 135
> 0000: 16 FE FD 00 00 00 00 00   00 00 00 00 7A 01 00 00 ............z...
> 0010: 6E 00 00 00 00 00 00 00   6E FE FD 18 E3 9C 82 DF n.......n.......
> 0020: 02 6C 42 FF AB EE 0C 9A   82 1B 78 6A 31 93 DC 6A .lB.......xj1..j
> 0030: DC 70 9F 5A 91 DB D5 04   E1 99 65 00 00 00 02 00 .p.Z......e.....
> 0040: 3C 01 00 00 42 00 0D 00   1C 00 1A 06 03 06 01 05 <...B...........
> 0050: 03 05 01 04 03 04 01 04   02 03 03 03 01 03 02 02 ................
> 0060: 03 02 01 02 02 00 11 00   10 00 0E 02 00 04 00 00 ................
> 0070: 00 00 01 00 04 00 00 00   00 00 05 00 05 01 00 00 ................
> 0080: 00 00 FF 01 00 01 00                               .......
>
> Well ... I am sure that such a dump contains everything we need, but 
> ... it doesn't look really friendly :) If someone is not an expert in 
> TLS/DTLS like me, than it might be helpful to have some thing more 
> human-readable in logs :) That's why I wanted to print sequence and 
> epoch numbers (it helped me while looking into 8161086).
>>
>> 466-470
>> This is a nice update to get the user friendly handshake type
>> description.  There are still a lot similar debug log that need to get
>> similar update.  Would you mind to file a new RFE, and make the update
>> together with other places (both TLS and DTLS) all together?
> Sure, I filed https://bugs.openjdk.java.net/browse/JDK-8162996
>
> I'll revert all changes related to debut output. They may be 
> integrated in the RFE above.
>>
>>
>> DTLSInputRecord
>> ---------------
>>   159    long onlySeqNum  =
>>              Authenticator.getDTLSSequenceNumber(recordEnS);
>>
>> Using getDTLSSequenceNumber(long) may be more effective.
>>
>> 161-165, if you consider to remove the debug log update in
>> DTLSOutputRecord, you may also want to remove the debug log update here
>> for similar reasons.
>>
>> HandshakeMessage
>> ----------------
>> See comment for DTLSOutputRecord.  I may prefer to file a new RFE, and
>> make the update all together.
>>
>>
>> Authenticator
>> -------------
>> May not need the update any more if you consider my suggestions above.
>> Otherwise, I think may be only
>>
>>     getDTLSSequenceNumber(long recordEnS)
>>
>> is actually used.  Other two new methods can be removed.
>>
>>
>> InvalidRecords
>> --------------
>> I like this find!
>>
>>
>> DTLSOverDatagram
>> ----------------
>>
>> 50         System.setProperty("javax.net.debug", "ssl,record");
>>
>> I may suggest to use "ssl,record,packet" for debugging if you won't dump
>> the epoch/seq# in "record" debug option.  If the test passed, I may
>> prefer to turn the debug log off.
> The tests pass now. I don't mind removing this debug output, but it 
> happens often that we don't have enough info if a test fails 
> intermittently. Then, we may update the test to use -Djavax.net.debug 
> to get more info when it fails next time. I think it might be good to 
> enable debug output for tests by default, so that we have more info to 
> analyze failures. As far as I know, jtreg may be configured to keep 
> jtr files only for failed tests, so additional output shouldn't take 
> much space if someone runs these test often. Is there any other concerns?
>> doServerSide()
>> I did not get too much about the update:
>> 1. Is it necessary to combine handshake and reading client application
>> data together?
> Final handshake messages to a client may be lost. Client still will be 
> expecting them, and server needs to re-send them. When server is done 
> with handshaking, it tries to receive first application data. But if 
> client didn't receive final handshake messages (because they were 
> lost), it keeps re-sending handshake messages to server. In this 
> situation, server needs to re-send final handshake messages to client. 
> Those messages are easily accessible while we're in handshake() 
> method, so that's why I added reading first application data there. 
> handshake() method may return final handshake packets to the caller, 
> so that it can re-send them if necessary. This is just another way, I 
> don't think any of them is better that another.
>>     I think the receiveAppData can be reused.
> I don't think it can be re-used "as is" because it needs to re-send 
> final handshake messages on server side. Okay, I'll update the method, 
> and re-use it.
>>
>> 2. Is it necessary to re-send application data?
>>     I think if application data is not allowed to drop, may not need to
>> the re-send code.
> You're right. I'll remove those while loops.
>>
>> Same for the doClientSide() implementation.
>>
>> disablePacketDrop() is a static method, you may not want to call it
>> exception the initialization stage.  The following line need to be very
>> carefully used:
>>
>>   162   CustomDatagramSocketImplFactory.disablePacketDrop();
>>   334   CustomDatagramSocketImplFactory.disablePacketDrop();
> disablePacketDrop() asks CustomDatagramSocketImpl to stop dropping 
> packets. This method should be called before we start sending 
> application data. It seems like one of these disablePacketDrop() calls 
> is redundant, I'll move it to sendAppData() method.
>>
>> 324-375, may be not necessary, or can be improved to use
>> receiveAppData() method instead.
> Sure, will do, please see above.
>>    I think the wrap() and unwrap() impl
>> should take care of the retransmission of handshaking messages, but not
>> the application.  Resending the previous packet does not comply to DTLS
>> retransmission specification.  If you run into problems, would you mind
>> show me the debug log?
> I am not sure what logs you are asking about. You can find some logs 
> attached to https://bugs.openjdk.java.net/browse/JDK-8159416
>
> I am also not sure what you mean by retransmission here. As far as I 
> understand, wrap() and unwrap() methods produce/consume (D)TLS 
> records, and client code should take care of sending them over the 
> network to the remote peer. While expecting first application data, 
> the test re-sends the same packets which were generated by last wrap() 
> call on server side. This means that DTLS records with the same 
> sequence numbers are used again.
>
> Do you think that server should generate records with new sequence 
> numbers?
>
> (I have not tried to call wrap() again to produce final handshake 
> message after server's SSLEngine has finished handshaking, not sure if 
> it works)
>
>>
>>>> - Updated client and server to use simple threads instead of thread
>>>> pools. This way, it's possible to specify meaningful names for
>>>> threads
>> A more light update may be use Thread.setName(String name) in the
>> ServerCallable.call().  I did not test.  If you like, you can have a 
>> try.
> setName() method is not static, so it should be called on an instance 
> of Thread, but I don't know how to access it in ServerCallable.call() 
> method.
>>
>>
>> CustomDatagramSocketImpl.addPacket()
>> I may suggest to check application data here.
>>
>>       927     private void addPacket(byte[] data) {
>>       928         // check if a packet should be dropped
>> -    929         if (CustomDatagramSocketImplFactory.losePacket()) {
>> +                if (ustomDatagramSocketImplFactory.losePacket() &&
>> +                        (data[0] != (byte)0x17)) {
>>       930             return;
>>       931         }
>>
>> "data[0] != (byte)0x17" means that it is not application data. As would
>> simplify the code a lot.  See comments above about the application data
>> re-sending issue.
> It wouldn't simplify the code to me because "0x17" looks like a magic 
> number. Of course, we can define it as a constant with some meaningful 
> name, but to me it is clearer to call a method which just stops 
> dropping packets. It doesn't make the code too complicated to me. If 
> you don't mind, and there is no other issues with it, I would prefer 
> to keep it.
>>
>>
>> PacketLossXXX.java
>> ------------------
>> It should not be the common case to split test cases separated with the
>> test code.  I would suggest merge them into the PacketLoss.java.
> The problem here is that those test take some time for execution. 
> That's why I splitted them to different files.
>
> As far as I remember, there was a concern from people who run those 
> tests in CI systems that some tests take too long. Their point was 
> that tests execution may be faster if we run tests in concurrent mode, 
> and don't have tests which take too long. And if I recall correctly, 
> there was an agreement that we split such tests this way.
>
> I am cc'ing Rajan, he may remember more about this.
>
> Artem
>>    If you
>> are worrying about the debug log length, please turn off the debug log.
>> Actually, we should turn off the debug log unless we need more detailed
>> debug log for problematic test.  Or alternatively, we can ask the JTREG
>> to consider the behavior more about the debug length restrictions.
>>
>> Thanks,
>> Xuelei
>>
>> On 8/2/2016 9:25 AM, Artem Smotrakov wrote:
>>> Here is an updated webrev which includes a fix for 8161086 (thanks
>>> Xuelei for help):
>>> - No updates to the problem list
>>> - CustomDatagramSocketImplFactory drops 5% of packets by default
>>> - Updated DTLSInputRecord and DTLSOutputRecord to print sequence 
>>> numbers
>>> if -Djavax.net.debug=ssl option is specified
>>> - Updated InvalidRecords.java tests not to drop packets by default
>>> because handshaking unexpectedly succeeds if an invalid packet was 
>>> dropped
>>>
>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.03/
>>>
>>> Please take a look.
>>>
>>> Artem
>>>
>>> On 07/28/2016 04:36 PM, Artem Smotrakov wrote:
>>>> Hi Xuelei,
>>>>
>>>> I updated CustomDatagramSocketImpl class to be able to drop some
>>>> packets randomly or by specified numbers.
>>>>
>>>> While updating the test, I found
>>>> https://bugs.openjdk.java.net/browse/JDK-8161086 which I think is the
>>>> root cause of these intermittent failures.
>>>>
>>>> I added a couple of PacketLoss* tests to reproduce and verify 8161086.
>>>> These tests drop different packets while handshaking. They use
>>>> different cipher suites and modes, so that they take a while. I didn't
>>>> notice they fail with timeout, but I suspect that may happen on slower
>>>> machines. That's why I increased timeout value for them. I added the
>>>> tests to the problem list since 8161086 is not fixed yet.
>>>>
>>>> There are a couple of other updates to DTLSOverDatagram.java:
>>>> - Server tries to receive first application data when it finishes
>>>> handshaking. Server re-sends final handshaking messages if timeout
>>>> reached while waiting for application data from client.
>>>> - Updated client and server to use simple threads instead of thread
>>>> pools. This way, it's possible to specify meaningful names for threads
>>>> which makes logs more readable if "-Djavax.net.debug=ssl" specified
>>>> - Added more logging
>>>> - Made some fields final
>>>>
>>>> At the moment, CustomDatagramSocketImplFactory doesn't drop packets by
>>>> default because it may cause intermittent failures of tests which are
>>>> based on DTLSOverDatagram class:
>>>>
>>>> ...
>>>>      static class CustomDatagramSocketImplFactory
>>>>                  implements DatagramSocketImplFactory {
>>>> ...
>>>>      // if true, it's going to drop some packets
>>>>      private static boolean dropPackets = false;
>>>> ...
>>>>
>>>> When 8161086 is fixed, it may be set to true by default. Currently the
>>>> packet loss rate is 5% which I think is much more than if we use UDP
>>>> sockets on localhost, so that we test DTLS impl in worse conditions.
>>>>
>>>> Could you please take a look at updated webrev?
>>>>
>>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.02/
>>>>
>>>> Artem
>>>>
>>>> On 06/27/2016 06:25 PM, Xuelei Fan wrote:
>>>>> On 6/28/2016 9:12 AM, Artem Smotrakov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review this patch for javax/net/ssl/DTLS tests.
>>>>>>
>>>>>> A couple of DTLS tests fail intermittently on Mac with timeout or 
>>>>>> "Too
>>>>>> many handshake loops ..." error. The tests use UDP to transfer DTLS
>>>>>> records. It happens sometimes that server cannot receive UDP packets
>>>>>> with DatagramSocket.receive() method even if client tries to re-send
>>>>>> them multiple times. Please see logs in the bug.
>>>>>>
>>>>>> At the moment, it is not clear why UDP packets can't be delivered to
>>>>>> server. If someone has seen something similar before, or has some 
>>>>>> ideas
>>>>>> what might be the root cause, please let me know.
>>>>>>
>>>>> UDP is not reliable.  It could happen that the packets get lost.
>>>>>
>>>>>> I think that the tests and DTLS implementation are fine here. 
>>>>>> Since the
>>>>>> tests are for DTLS, we can workaround this issue by avoiding real 
>>>>>> UDP
>>>>>> connections. To avoid changing test logic much, we can use a custom
>>>>>> DatagramSocketImpl and DatagramSocketImplFactory implementations to
>>>>>> replace system UDP implementation.
>>>>>>
>>>>>> The patch below updates the tests with the following:
>>>>>> - added custom DatagramSocketImpl and DatagramSocketImplFactory
>>>>>> implementations to avoid real UDP connections
>>>>> Tests for real connections in practice are needed.  If we update this
>>>>> test this way, we need to add other tests to test real application
>>>>> usage.  I don't think this is the right direction to avoid real UDP
>>>>> connections.
>>>>>
>>>>>> - added more test output, so that we can have more info it the tests
>>>>>> fail again
>>>>>>
>>>>> I agree with this point.
>>>>>
>>>>> Xuelei
>>>>>
>>>>>> I have run javax/net/ssl/DTLS/CipherSuite.java test in a loop on 
>>>>>> Mac,
>>>>>> and I didn't see it failed. I also have run javax/net/ssl/DTLS 
>>>>>> tests on
>>>>>> all supported generic platforms, and they worked fine.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159416
>>>>>> http://cr.openjdk.java.net/~asmotrak/8159416/webrev.00/
>>>>>>
>>>>>> Artem
>



From sean.coffey at oracle.com  Wed Aug  3 08:13:14 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 3 Aug 2016 09:13:14 +0100
Subject: Code Review Request JDK-8162362, Cannot enable previously default
	enabled cipher suites
In-Reply-To: <44fa2f16-55b9-59f7-44f0-b83d259e7980@oracle.com>
References: <cda84bd9-56dd-3f61-2d91-9775528627e5@oracle.com>
	<44fa2f16-55b9-59f7-44f0-b83d259e7980@oracle.com>
Message-ID: <f25becd1-b3e3-7911-cd8a-9b4a333943bc@oracle.com>

Hi Xuelei,

Thanks for taking this one on. I think the approach looks good. Some 
minor comments ..

Can we update bug description to something like "Introduce system 
property to control enabled ciphersuites"
SSLContextImpl.java :

typo : getCustomizedCipehrSuites --> getCustomizedCipherSuites

line 432, if we're in debug mode, can we print the property name handed 
in from application code ?
e.g. Something like this might appear : jdk.tls.client.cipherSuites 
property set to : "SSL_RSA_WITH_DES_CBC_SHA"

For the testcase, would you mind testing the new value with multiple 
comma separated values ?

e.g. -Djdk.tls.client.cipherSuites="unknown, SSL_RSA_WITH_DES_CBC_SHA, 
unknown1, TLS_RSA_WITH_AES_128_CBC_SHA"

On line 200, 205, I think you can then just change your test to a 
String.contains("<cipher>") call.

Regards,
Sean.

On 02/08/2016 16:34, Xuelei Fan wrote:
> Ping ...
>
> On 7/29/2016 11:23 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the fix for JDK-8162362:
>>
>>     http://cr.openjdk.java.net/~xuelei/8162362/webrev.00/
>>
>> If a cipher suite is getting weak or vulnerable, it is normally removed
>> from the default enabled list in JDK.  The compatibility impact of the
>> removing is normally minimal as if there are other available cipher
>> suites enabled.
>>
>> However, some applications may want to support the disabled cipher
>> suites in JDK.  If the source code is not accessible, there is not much
>> workaround to have the cipher suite back to work if it is removed from
>> the default enabled list in JDK.
>>
>> This fix introduces two new system properties, which can be used to
>> customize the default enabled cipher suites.
>>
>> The system property "jdk.tls.client.cipherSuites" is used to customize
>> the default enabled cipher suites for client side of SSL/TLS/DTLS
>> connections. Similarly, the system property
>> "jdk.tls.server.cipherSuites" is used for server side.
>>
>> The system property contains a comma-separated list of supported cipher
>> suite names specifying the default enabled cipher suites.  All other
>> supported cipher suites are disabled for this default setting.
>> Unrecognized or unsupported cipher suite name specified in the property
>> is ignored.  Explicit setting of enabled cipher suites will override the
>> system property.
>>
>> Thanks,
>> Xuelei
>>



From xuelei.fan at oracle.com  Wed Aug  3 09:23:19 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 3 Aug 2016 17:23:19 +0800
Subject: Code Review Request JDK-8162362, Cannot enable previously default
	enabled cipher suites
In-Reply-To: <f25becd1-b3e3-7911-cd8a-9b4a333943bc@oracle.com>
References: <cda84bd9-56dd-3f61-2d91-9775528627e5@oracle.com>
	<44fa2f16-55b9-59f7-44f0-b83d259e7980@oracle.com>
	<f25becd1-b3e3-7911-cd8a-9b4a333943bc@oracle.com>
Message-ID: <62063757-5df7-475e-1f30-3bffba040ef6@oracle.com>

New webrev:
   http://cr.openjdk.java.net/~xuelei/8162362/webrev.01/

On 8/3/2016 4:13 PM, Se?n Coffey wrote:
> Hi Xuelei,
> 
> Thanks for taking this one on. I think the approach looks good. Some
> minor comments ..
> 
> Can we update bug description to something like "Introduce system
> property to control enabled ciphersuites"
> SSLContextImpl.java :
> 
> typo : getCustomizedCipehrSuites --> getCustomizedCipherSuites
> 
> line 432, if we're in debug mode, can we print the property name handed
> in from application code ?
> e.g. Something like this might appear : jdk.tls.client.cipherSuites
> property set to : "SSL_RSA_WITH_DES_CBC_SHA"
> 
> For the testcase, would you mind testing the new value with multiple
> comma separated values ?
> 
> e.g. -Djdk.tls.client.cipherSuites="unknown, SSL_RSA_WITH_DES_CBC_SHA,
> unknown1, TLS_RSA_WITH_AES_128_CBC_SHA"
> 
All above comments get addressed in the new webrev.


> On line 200, 205, I think you can then just change your test to a
> String.contains("<cipher>") call.
>
I got the point.  I want to use isEmpty() so that it is reminding me
that empty string is special in the context.  Let me use the old code.

Thanks,
Xuelei


> Regards,
> Sean.
> 
> On 02/08/2016 16:34, Xuelei Fan wrote:
>> Ping ...
>>
>> On 7/29/2016 11:23 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8162362:
>>>
>>>     http://cr.openjdk.java.net/~xuelei/8162362/webrev.00/
>>>
>>> If a cipher suite is getting weak or vulnerable, it is normally removed
>>> from the default enabled list in JDK.  The compatibility impact of the
>>> removing is normally minimal as if there are other available cipher
>>> suites enabled.
>>>
>>> However, some applications may want to support the disabled cipher
>>> suites in JDK.  If the source code is not accessible, there is not much
>>> workaround to have the cipher suite back to work if it is removed from
>>> the default enabled list in JDK.
>>>
>>> This fix introduces two new system properties, which can be used to
>>> customize the default enabled cipher suites.
>>>
>>> The system property "jdk.tls.client.cipherSuites" is used to customize
>>> the default enabled cipher suites for client side of SSL/TLS/DTLS
>>> connections. Similarly, the system property
>>> "jdk.tls.server.cipherSuites" is used for server side.
>>>
>>> The system property contains a comma-separated list of supported cipher
>>> suite names specifying the default enabled cipher suites.  All other
>>> supported cipher suites are disabled for this default setting.
>>> Unrecognized or unsupported cipher suite name specified in the property
>>> is ignored.  Explicit setting of enabled cipher suites will override the
>>> system property.
>>>
>>> Thanks,
>>> Xuelei
>>>
> 



From sean.coffey at oracle.com  Wed Aug  3 10:23:31 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 3 Aug 2016 11:23:31 +0100
Subject: Code Review Request JDK-8162362, Cannot enable previously default
	enabled cipher suites
In-Reply-To: <62063757-5df7-475e-1f30-3bffba040ef6@oracle.com>
References: <cda84bd9-56dd-3f61-2d91-9775528627e5@oracle.com>
	<44fa2f16-55b9-59f7-44f0-b83d259e7980@oracle.com>
	<f25becd1-b3e3-7911-cd8a-9b4a333943bc@oracle.com>
	<62063757-5df7-475e-1f30-3bffba040ef6@oracle.com>
Message-ID: <57A1C623.8050801@oracle.com>

looks good.

Regards,
Sean.

On 03/08/16 10:23, Xuelei Fan wrote:
> New webrev:
>     http://cr.openjdk.java.net/~xuelei/8162362/webrev.01/
>
> On 8/3/2016 4:13 PM, Se?n Coffey wrote:
>> Hi Xuelei,
>>
>> Thanks for taking this one on. I think the approach looks good. Some
>> minor comments ..
>>
>> Can we update bug description to something like "Introduce system
>> property to control enabled ciphersuites"
>> SSLContextImpl.java :
>>
>> typo : getCustomizedCipehrSuites --> getCustomizedCipherSuites
>>
>> line 432, if we're in debug mode, can we print the property name handed
>> in from application code ?
>> e.g. Something like this might appear : jdk.tls.client.cipherSuites
>> property set to : "SSL_RSA_WITH_DES_CBC_SHA"
>>
>> For the testcase, would you mind testing the new value with multiple
>> comma separated values ?
>>
>> e.g. -Djdk.tls.client.cipherSuites="unknown, SSL_RSA_WITH_DES_CBC_SHA,
>> unknown1, TLS_RSA_WITH_AES_128_CBC_SHA"
>>
> All above comments get addressed in the new webrev.
>
>
>> On line 200, 205, I think you can then just change your test to a
>> String.contains("<cipher>") call.
>>
> I got the point.  I want to use isEmpty() so that it is reminding me
> that empty string is special in the context.  Let me use the old code.
>
> Thanks,
> Xuelei
>
>
>> Regards,
>> Sean.
>>
>> On 02/08/2016 16:34, Xuelei Fan wrote:
>>> Ping ...
>>>
>>> On 7/29/2016 11:23 PM, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Please review the fix for JDK-8162362:
>>>>
>>>>      http://cr.openjdk.java.net/~xuelei/8162362/webrev.00/
>>>>
>>>> If a cipher suite is getting weak or vulnerable, it is normally removed
>>>> from the default enabled list in JDK.  The compatibility impact of the
>>>> removing is normally minimal as if there are other available cipher
>>>> suites enabled.
>>>>
>>>> However, some applications may want to support the disabled cipher
>>>> suites in JDK.  If the source code is not accessible, there is not much
>>>> workaround to have the cipher suite back to work if it is removed from
>>>> the default enabled list in JDK.
>>>>
>>>> This fix introduces two new system properties, which can be used to
>>>> customize the default enabled cipher suites.
>>>>
>>>> The system property "jdk.tls.client.cipherSuites" is used to customize
>>>> the default enabled cipher suites for client side of SSL/TLS/DTLS
>>>> connections. Similarly, the system property
>>>> "jdk.tls.server.cipherSuites" is used for server side.
>>>>
>>>> The system property contains a comma-separated list of supported cipher
>>>> suite names specifying the default enabled cipher suites.  All other
>>>> supported cipher suites are disabled for this default setting.
>>>> Unrecognized or unsupported cipher suite name specified in the property
>>>> is ignored.  Explicit setting of enabled cipher suites will override the
>>>> system property.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>



From sean.mullan at oracle.com  Wed Aug  3 13:09:42 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 3 Aug 2016 09:09:42 -0400
Subject: [9] RFR 8154113: java.security.AccessControlException: access
	denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")
In-Reply-To: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>
References: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>
Message-ID: <a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>

Hi Valerie,

Can you also clean up the noaccess.policy and access.policy files and 
remove the permissions that are now granted to the jdk.crypto.mscapi 
module in default.policy?

Also, in the test, I would use the java.security.policy== option instead 
of the policy option. The policy option is an older jtreg option that I 
think we should phase out from tests. The java.security.policy option is 
easier to understand because it is consistent with the system property.

--Sean

On 08/02/2016 06:04 PM, Valerie Peng wrote:
> Sean,
>
> Would you be able to review this policy update for SunMSCAPI provider?
> In addition to the policy update, the test is updated to replace the
> shell script with @run tags.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154113
> Webrev: http://cr.openjdk.java.net/~valeriep/8154113/webrev.00/
>
> Thanks,
> Valerie


From valerie.peng at oracle.com  Wed Aug  3 23:15:27 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 3 Aug 2016 16:15:27 -0700
Subject: [9] RFR 8154113: java.security.AccessControlException: access
	denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")
In-Reply-To: <a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>
References: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>
	<a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>
Message-ID: <8ff19f74-eaff-34c7-fd00-b8531e50c9df@oracle.com>


Sure, webrev updated: 
http://cr.openjdk.java.net/~valeriep/8154113/webrev.01/
Thanks,
Valerie

On 8/3/2016 6:09 AM, Sean Mullan wrote:
> Hi Valerie,
>
> Can you also clean up the noaccess.policy and access.policy files and 
> remove the permissions that are now granted to the jdk.crypto.mscapi 
> module in default.policy?
>
> Also, in the test, I would use the java.security.policy== option 
> instead of the policy option. The policy option is an older jtreg 
> option that I think we should phase out from tests. The 
> java.security.policy option is easier to understand because it is 
> consistent with the system property.
>
> --Sean
>
> On 08/02/2016 06:04 PM, Valerie Peng wrote:
>> Sean,
>>
>> Would you be able to review this policy update for SunMSCAPI provider?
>> In addition to the policy update, the test is updated to replace the
>> shell script with @run tags.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154113
>> Webrev: http://cr.openjdk.java.net/~valeriep/8154113/webrev.00/
>>
>> Thanks,
>> Valerie



From mandy.chung at oracle.com  Thu Aug  4 04:42:17 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 3 Aug 2016 21:42:17 -0700
Subject: [9] RFR 8154113: java.security.AccessControlException: access
	denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")
In-Reply-To: <a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>
References: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>
	<a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>
Message-ID: <5576A0CD-A802-42FD-A38F-2AC4BB7FFC7F@oracle.com>

A passing comment: 

The test can simply specify @modules jdk.crypto.mscapi and this test will only run when jdk.crypto.mscapi is present; in other words, line 45-48 are no longer needed.

Mandy

> On Aug 3, 2016, at 6:09 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Hi Valerie,
> 
> Can you also clean up the noaccess.policy and access.policy files and remove the permissions that are now granted to the jdk.crypto.mscapi module in default.policy?
> 
> Also, in the test, I would use the java.security.policy== option instead of the policy option. The policy option is an older jtreg option that I think we should phase out from tests. The java.security.policy option is easier to understand because it is consistent with the system property.
> 
> --Sean
> 
> On 08/02/2016 06:04 PM, Valerie Peng wrote:
>> Sean,
>> 
>> Would you be able to review this policy update for SunMSCAPI provider?
>> In addition to the policy update, the test is updated to replace the
>> shell script with @run tags.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154113
>> Webrev: http://cr.openjdk.java.net/~valeriep/8154113/webrev.00/
>> 
>> Thanks,
>> Valerie



From sean.mullan at oracle.com  Thu Aug  4 14:20:53 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 4 Aug 2016 10:20:53 -0400
Subject: [9] RFR 8154113: java.security.AccessControlException: access
	denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")
In-Reply-To: <5576A0CD-A802-42FD-A38F-2AC4BB7FFC7F@oracle.com>
References: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>
	<a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>
	<5576A0CD-A802-42FD-A38F-2AC4BB7FFC7F@oracle.com>
Message-ID: <43c5db63-c57c-6741-4820-4f316d84ce96@oracle.com>

On 08/04/2016 12:42 AM, Mandy Chung wrote:
> A passing comment:
>
> The test can simply specify @modules jdk.crypto.mscapi and this test will only run when jdk.crypto.mscapi is present; in other words, line 45-48 are no longer needed.

Does that also mean line 27 can be removed:

27  * @requires os.family == "windows"

--Sean

>
> Mandy
>
>> On Aug 3, 2016, at 6:09 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> Hi Valerie,
>>
>> Can you also clean up the noaccess.policy and access.policy files and remove the permissions that are now granted to the jdk.crypto.mscapi module in default.policy?
>>
>> Also, in the test, I would use the java.security.policy== option instead of the policy option. The policy option is an older jtreg option that I think we should phase out from tests. The java.security.policy option is easier to understand because it is consistent with the system property.
>>
>> --Sean
>>
>> On 08/02/2016 06:04 PM, Valerie Peng wrote:
>>> Sean,
>>>
>>> Would you be able to review this policy update for SunMSCAPI provider?
>>> In addition to the policy update, the test is updated to replace the
>>> shell script with @run tags.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154113
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8154113/webrev.00/
>>>
>>> Thanks,
>>> Valerie
>


From sean.mullan at oracle.com  Thu Aug  4 14:24:51 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 4 Aug 2016 10:24:51 -0400
Subject: [9] RFR 8154113: java.security.AccessControlException: access
	denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")
In-Reply-To: <8ff19f74-eaff-34c7-fd00-b8531e50c9df@oracle.com>
References: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>
	<a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>
	<8ff19f74-eaff-34c7-fd00-b8531e50c9df@oracle.com>
Message-ID: <3af6cb00-c951-299d-fa45-3543182ea50b@oracle.com>

Looks good.

--Sean

On 08/03/2016 07:15 PM, Valerie Peng wrote:
>
> Sure, webrev updated:
> http://cr.openjdk.java.net/~valeriep/8154113/webrev.01/
> Thanks,
> Valerie
>
> On 8/3/2016 6:09 AM, Sean Mullan wrote:
>> Hi Valerie,
>>
>> Can you also clean up the noaccess.policy and access.policy files and
>> remove the permissions that are now granted to the jdk.crypto.mscapi
>> module in default.policy?
>>
>> Also, in the test, I would use the java.security.policy== option
>> instead of the policy option. The policy option is an older jtreg
>> option that I think we should phase out from tests. The
>> java.security.policy option is easier to understand because it is
>> consistent with the system property.
>>
>> --Sean
>>
>> On 08/02/2016 06:04 PM, Valerie Peng wrote:
>>> Sean,
>>>
>>> Would you be able to review this policy update for SunMSCAPI provider?
>>> In addition to the policy update, the test is updated to replace the
>>> shell script with @run tags.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154113
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8154113/webrev.00/
>>>
>>> Thanks,
>>> Valerie
>


From bradford.wetmore at oracle.com  Thu Aug  4 19:35:21 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 4 Aug 2016 12:35:21 -0700
Subject: RFR: 8061842: Package jurisdiction policy files as something other
	than JAR
Message-ID: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8061842
http://cr.openjdk.java.net/~wetmore/8061842/webrev.00/

The proposal is to move the configuration files from the jar files in 
<java-home>/lib/security to a series of subdirectories under a new 
"policy" subdirectory in <java-home>/conf/security.  Each subdirectory 
within that directory will represent a complete policy configuration. 
The existing jar files will be split into flat text files such that the 
current/existing policies remain.

The default set of policy files (i.e. directory) is configured using a 
new java.security.Security property called "crypto.policy" which will be 
added to the <java-home>/conf/security/java.security file.  The default 
initial options are "limited" or "unlimited", however additional 
directories could potentially be created that specify other 
as-yet-unknown policies.

The default value of this property will be "limited" which corresponds 
to our current policy for JRE/JDK export/import around the world. 
However, the build respects the following "configure" option:

     --enable-unlimited-crypto
                         Enable unlimited crypto policy [disabled]

Within the directory, our implementation will look for files using the 
standard filename prefix above ("default_" or "exempt_"), thus new 
additional policy restrictions/abstractions can be added with a simple 
file addition.

Brad



From ecki at zusammenkunft.net  Thu Aug  4 20:41:21 2016
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 4 Aug 2016 22:41:21 +0200
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
Message-ID: <20160804224121.00005bb3.ecki@zusammenkunft.net>

Hello,

I am glad as a user that I am only annoyed by the limited policies and
that I do not have to actually implement features to restrict my
software. :)

However your mail reminded me: will it be a good idea to implement
something like a Fips-compliant runtime in terms of (yet another)
policy?

Related to that: are there any other useful uses for those jce policies?
(Never encounter them besides the restricted ciphers). For things like
enforcing minimum security (FIPS, PCI-DSS, ...) the policy objects
should not only feature maximum keysizes, but also minimum sizes,
right? Same is true for denying weakening attributes and such. On the
other hand this greatly conflicts with the security properties already
existing (at least for JSSE).

You mail did not talk about signatures, will the new policies require
to be signed by a JCE certifiate (i.e. via Oracle) or can they be
customized without?

Will there be an option "use strongest available"? That way an JDK
upgrade (overwrite the files) will no longer be a problem as the
additional policy persists - but I still would need the system property
to activate it...

Gruss
Bernd


 Am Thu, 4 Aug 2016 12:35:21 -0700 schrieb Bradford Wetmore
<bradford.wetmore at oracle.com>:

> https://bugs.openjdk.java.net/browse/JDK-8061842
> http://cr.openjdk.java.net/~wetmore/8061842/webrev.00/
> 
> The proposal is to move the configuration files from the jar files in 
> <java-home>/lib/security to a series of subdirectories under a new 
> "policy" subdirectory in <java-home>/conf/security.  Each
> subdirectory within that directory will represent a complete policy
> configuration. The existing jar files will be split into flat text
> files such that the current/existing policies remain.
> 
> The default set of policy files (i.e. directory) is configured using
> a new java.security.Security property called "crypto.policy" which
> will be added to the <java-home>/conf/security/java.security file.
> The default initial options are "limited" or "unlimited", however
> additional directories could potentially be created that specify
> other as-yet-unknown policies.
> 
> The default value of this property will be "limited" which
> corresponds to our current policy for JRE/JDK export/import around
> the world. However, the build respects the following "configure"
> option:
> 
>      --enable-unlimited-crypto
>                          Enable unlimited crypto policy [disabled]
> 
> Within the directory, our implementation will look for files using
> the standard filename prefix above ("default_" or "exempt_"), thus
> new additional policy restrictions/abstractions can be added with a
> simple file addition.
> 
> Brad
> 



From bradford.wetmore at oracle.com  Thu Aug  4 21:38:10 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 4 Aug 2016 14:38:10 -0700
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <20160804224121.00005bb3.ecki@zusammenkunft.net>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<20160804224121.00005bb3.ecki@zusammenkunft.net>
Message-ID: <a6db5ef1-01e8-5b3c-facd-7a3f64845654@oracle.com>



On 8/4/2016 1:41 PM, Bernd Eckenfels wrote:
> Hello,
>
> I am glad as a user that I am only annoyed by the limited policies and
> that I do not have to actually implement features to restrict my
> software. :)

You are indeed fortunate.  :)

> However your mail reminded me: will it be a good idea to implement
> something like a Fips-compliant runtime in terms of (yet another)
> policy?

This policy is just for enforcing maximum JCE keysizes for import/export 
purposes, which has been there since pretty much Day 1 of JCE.  This is 
just repackaging existing policy, as the jigsaw team really wanted to 
get rid of the jar files.  JEP 220.

A FIPs matrix is a discussion for another release.

> Related to that: are there any other useful uses for those jce policies?
> (Never encounter them besides the restricted ciphers).

I don't think so.  I think for most cases, people are able to install 
the unlimited bundle and are done.

This was before my time, but I believe this was only to satisfy 
export/import requirements.

> For things like
> enforcing minimum security (FIPS, PCI-DSS, ...) the policy objects
> should not only feature maximum keysizes, but also minimum sizes,
> right? Same is true for denying weakening attributes and such. On the
> other hand this greatly conflicts with the security properties already
> existing (at least for JSSE).
>
> You mail did not talk about signatures, will the new policies require
> to be signed by a JCE certifiate (i.e. via Oracle) or can they be
> customized without?

Customized without.

> Will there be an option "use strongest available"? That way an JDK
> upgrade (overwrite the files) will no longer be a problem as the
> additional policy persists - but I still would need the system property
> to activate it...

I would expect our limited/unlimited files/directories won't change. The 
contents have been static for years, but required the extra step of the 
download/replacement until earlier in JDK 9.

There have been 2-3 one-off policy file bundles generated over the last 
15 years (with even tighter restrictions), but ivery rare.

If you're modifying java.security, that is the only file you'll need for 
persistent policy going forward.  If you are creating your own 
directories, you'll of course need to copy those over too.

BTW, it's a Security property, not a java.lang.System property.

Brad


> Gruss
> Bernd
>
>
>  Am Thu, 4 Aug 2016 12:35:21 -0700 schrieb Bradford Wetmore
> <bradford.wetmore at oracle.com>:
>
>> https://bugs.openjdk.java.net/browse/JDK-8061842
>> http://cr.openjdk.java.net/~wetmore/8061842/webrev.00/
>>
>> The proposal is to move the configuration files from the jar files in
>> <java-home>/lib/security to a series of subdirectories under a new
>> "policy" subdirectory in <java-home>/conf/security.  Each
>> subdirectory within that directory will represent a complete policy
>> configuration. The existing jar files will be split into flat text
>> files such that the current/existing policies remain.
>>
>> The default set of policy files (i.e. directory) is configured using
>> a new java.security.Security property called "crypto.policy" which
>> will be added to the <java-home>/conf/security/java.security file.
>> The default initial options are "limited" or "unlimited", however
>> additional directories could potentially be created that specify
>> other as-yet-unknown policies.
>>
>> The default value of this property will be "limited" which
>> corresponds to our current policy for JRE/JDK export/import around
>> the world. However, the build respects the following "configure"
>> option:
>>
>>      --enable-unlimited-crypto
>>                          Enable unlimited crypto policy [disabled]
>>
>> Within the directory, our implementation will look for files using
>> the standard filename prefix above ("default_" or "exempt_"), thus
>> new additional policy restrictions/abstractions can be added with a
>> simple file addition.
>>
>> Brad
>>
>


From valerie.peng at oracle.com  Fri Aug  5 02:01:56 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 4 Aug 2016 19:01:56 -0700
Subject: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed on
	solaris12(sparcv9 and x86)
Message-ID: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>


Anyone has time to review this fix? The code change is in only one file 
and straightforward if you agree with the approach.
Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto 
APIs for message digest operations and there is no clone support.
This affects the MAC impls of SunJCE provider which delegates the digest 
operation to the most preferred provider.
To ensure the clone support, I will switch to getting the digest impl 
from SUN provider if the most preferred one does not.
In the case of SUN provider is not available, it will then goes through 
provider list.

Bug: https://bugs.openjdk.java.net/browse/JDK-8157579
Webrev: http://cr.openjdk.java.net/~valeriep/8157579/webrev.00/

No new test as it's covered by existing regression test.

Thanks,
Valerie




From mandy.chung at oracle.com  Fri Aug  5 04:07:09 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 4 Aug 2016 21:07:09 -0700
Subject: [9] RFR 8154113: java.security.AccessControlException: access
	denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")
In-Reply-To: <43c5db63-c57c-6741-4820-4f316d84ce96@oracle.com>
References: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>
	<a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>
	<5576A0CD-A802-42FD-A38F-2AC4BB7FFC7F@oracle.com>
	<43c5db63-c57c-6741-4820-4f316d84ce96@oracle.com>
Message-ID: <445729BB-05DA-4B93-9831-AC7BD06ECEDA@oracle.com>


> On Aug 4, 2016, at 7:20 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 08/04/2016 12:42 AM, Mandy Chung wrote:
>> A passing comment:
>> 
>> The test can simply specify @modules jdk.crypto.mscapi and this test will only run when jdk.crypto.mscapi is present; in other words, line 45-48 are no longer needed.
> 
> Does that also mean line 27 can be removed:
> 
> 27  * @requires os.family == ?windows"
> 

I think it should also be removed but you should verify it to make sure jtreg selects this test on windows only (where jdk.crypto.mscap1 is present).

Mandy



From sibabrata.sahoo at oracle.com  Fri Aug  5 10:00:40 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Fri, 5 Aug 2016 03:00:40 -0700 (PDT)
Subject: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488
	Deprivilege java.xml.crypto"
Message-ID: <e2c41364-77bf-43db-9991-82f85a39d132@default>

Hi,

 

Please review the patch for "deprivilege java.xml.crypto, java.security.jgss, jdk.security.jgss and jdk.security.auth" modules.

 

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

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

 

Description:

This includes a new Test which verifies the classes from "java.xml.crypto, java.security.jgss, jdk.security.jgss and jdk.security.auth" modules get loaded through Platform Classloader. It also includes modifying few existing test to run with Security manager enabled.

 

Thanks,

Siba

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

From weijun.wang at oracle.com  Fri Aug  5 10:48:50 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 5 Aug 2016 18:48:50 +0800
Subject: [9] RFR: 8159964: Update Tests to verify JDK build for
	"JDK-8159488 Deprivilege java.xml.crypto"
In-Reply-To: <e2c41364-77bf-43db-9991-82f85a39d132@default>
References: <e2c41364-77bf-43db-9991-82f85a39d132@default>
Message-ID: <d1551d01-adc3-1a78-561f-bed585bb4989@oracle.com>

I'm looking at DeprivilegedModuleLoaderTest.java.

Why not just call

    classes.add(XMLSignatureFactory.class);

--Max

On 8/5/2016 18:00, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for ?deprivilege java.xml.crypto,
> java.security.jgss, jdk.security.jgss and jdk.security.auth? modules.
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8159964
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.00/
>
>
>
> Description:
>
> This includes a new Test which verifies the classes from
> ?java.xml.crypto, java.security.jgss, jdk.security.jgss and
> jdk.security.auth? modules get loaded through Platform Classloader. It
> also includes modifying few existing test to run with Security manager
> enabled.
>
>
>
> Thanks,
>
> Siba
>
>
>


From vincent.x.ryan at oracle.com  Fri Aug  5 11:02:16 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 5 Aug 2016 12:02:16 +0100
Subject: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed
	on solaris12(sparcv9 and x86)
In-Reply-To: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>
References: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>
Message-ID: <F4F24844-63AA-4A03-B1C1-64DD64BA2FB0@oracle.com>

Your fix looks good. One comment is that you could trim the Provider[] to exclude the most-preferred provider (at index=0).
Thanks.


> On 5 Aug 2016, at 03:01, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> 
> Anyone has time to review this fix? The code change is in only one file and straightforward if you agree with the approach.
> Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto APIs for message digest operations and there is no clone support.
> This affects the MAC impls of SunJCE provider which delegates the digest operation to the most preferred provider.
> To ensure the clone support, I will switch to getting the digest impl from SUN provider if the most preferred one does not.
> In the case of SUN provider is not available, it will then goes through provider list.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8157579
> Webrev: http://cr.openjdk.java.net/~valeriep/8157579/webrev.00/
> 
> No new test as it's covered by existing regression test.
> 
> Thanks,
> Valerie
> 
> 



From sibabrata.sahoo at oracle.com  Fri Aug  5 13:57:31 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Fri, 5 Aug 2016 06:57:31 -0700 (PDT)
Subject: [9] RFR: 8159964: Update Tests to verify JDK build for
	"JDK-8159488 Deprivilege java.xml.crypto"
In-Reply-To: <d1551d01-adc3-1a78-561f-bed585bb4989@oracle.com>
References: <e2c41364-77bf-43db-9991-82f85a39d132@default>
	<d1551d01-adc3-1a78-561f-bed585bb4989@oracle.com>
Message-ID: <e5624c68-40e8-40fc-a366-38581939c751@default>

Hi Max,

Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.01/

Thanks,
Siba

-----Original Message-----
From: Weijun Wang 
Sent: Friday, August 05, 2016 4:19 PM
To: Sibabrata Sahoo; security-dev at openjdk.java.net; Valerie Peng
Subject: Re: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"

I'm looking at DeprivilegedModuleLoaderTest.java.

Why not just call

    classes.add(XMLSignatureFactory.class);

--Max

On 8/5/2016 18:00, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for "deprivilege java.xml.crypto, 
> java.security.jgss, jdk.security.jgss and jdk.security.auth" modules.
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8159964
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.00/
>
>
>
> Description:
>
> This includes a new Test which verifies the classes from 
> "java.xml.crypto, java.security.jgss, jdk.security.jgss and 
> jdk.security.auth" modules get loaded through Platform Classloader. It 
> also includes modifying few existing test to run with Security manager 
> enabled.
>
>
>
> Thanks,
>
> Siba
>
>
>


From sean.coffey at oracle.com  Fri Aug  5 14:25:27 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 5 Aug 2016 15:25:27 +0100
Subject: 8163104: Unexpected NPE still possible on some Kerberos ticket calls
Message-ID: <57A4A1D7.5040203@oracle.com>

Post JDK-8147772 <https://bugs.openjdk.java.net/browse/JDK-8147772>, I 
think we still have a possibility of hitting an NPE in Kerberos ticket 
management.

Could only find one method affected.
bug report : https://bugs.openjdk.java.net/browse/JDK-8163104
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8163104.jdk9/webrev/

-- 
Regards,
Sean.

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

From jamil.j.nimeh at oracle.com  Sat Aug  6 04:56:48 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 5 Aug 2016 21:56:48 -0700
Subject: RFR 8132943: ServerHandshaker may select non-empty OCSPStatusRequest
	structures when Responder ID selection is not supported
Message-ID: <4f2937f4-ba59-ffec-92d3-409b9e420bf9@oracle.com>

Hello all,

This fixes an issue with OCSPStatusRequest selection by the server when 
doing OCSP stapling.  Since we currently do not support responder ID 
filtering, the server should not select an OCSPStatusRequest with 
responder IDs in it, else it could potentially return OCSP responses 
that the client has already stated it would not trust.  This fix takes 
care of that.  If the server cannot find an OCSPStatusRequest that is 
suitable (in this case, one that has an empty responder ID list) it will 
not do stapling for that handshake.

Bug: https://bugs.openjdk.java.net/browse/JDK-8132943
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132943/webrev.01

Thanks,
--Jamil


From xuelei.fan at oracle.com  Mon Aug  8 00:57:29 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 8 Aug 2016 08:57:29 +0800
Subject: RFC7525 mapped to JSSE
In-Reply-To: <20160802001302.00005374.ecki@zusammenkunft.net>
References: <20160802001302.00005374.ecki@zusammenkunft.net>
Message-ID: <0ff9135c-dd24-cf99-0913-47939d07fd03@oracle.com>

Hi Bernd,

Thanks for the summary of the compliance.  The following comments are
mainly about the items marked with "TODO" or "???".

JDK 9 will support DTLS 1.0/1.2 and OCSP stapling (both RFC 6066 and RFC
6961).

The server preference of cipher suites can be configurable.

JDK uses uncompressed EC point format only.

JDK does not use EC curves < 224 bits for EC key exchange, default 256+
bits.

For TLS 1.2, SHA2 is requested in the signature algorithm extension.

JDK does not implement the truncted HMAC extension.

JDK supports hostname verification APIs for HTTPS, and support hostname
verification during handshaking for HTTPS and LDAP.

JDK tests the DH public keys.

Thanks & Regards,
Xuelei

On 8/2/2016 6:13 AM, Bernd Eckenfels wrote:
> Hello,
> 
> because I was asked by a customer I started to map the RFC7525
> 
> https://tools.ietf.org/html/rfc7525
> 
> recommendations for TLS to JSSE implementation.
> 
> 
> It is not complete yet but I think I at least have extraced all
> "normative" requirements from the RFC into this table:
> 
> https://docs.google.com/spreadsheets/d/135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE
> 
> would like to get your feedback.
> 
> Gruss
> Bernd
> 



From weijun.wang at oracle.com  Mon Aug  8 07:28:49 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 8 Aug 2016 15:28:49 +0800
Subject: RFR 8163303: Remove identity scope information from jarsigner
	-verbose output
Message-ID: <f84c78ee-3687-a6b7-4120-12a0515017e2@oracle.com>

Hi All

Please review the code change at

    http://cr.openjdk.java.net/~weijun/8163303/webrev.00

I removed the "@SuppressWarnings("deprecation")" at the beginning. I 
think this has been unnecessary for quite a while since calls to 
deprecated classes (ContentSigner and ContentSignerParameters) have been 
moved to the new JarSigner API.

*Leo*: I take the chance to update localized Resourses.java files for 
Japanese and Chinese, since this is only about removing items. Please 
confirm this is OK.

Thanks
Max


From sean.mullan at oracle.com  Mon Aug  8 13:33:16 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 8 Aug 2016 09:33:16 -0400
Subject: RFR 8163303: Remove identity scope information from jarsigner
	-verbose output
In-Reply-To: <f84c78ee-3687-a6b7-4120-12a0515017e2@oracle.com>
References: <f84c78ee-3687-a6b7-4120-12a0515017e2@oracle.com>
Message-ID: <b7b66867-ff42-c5c4-16ae-29815cb9763f@oracle.com>

Looks good to me. You will need to add an appropriate noreg label to the 
bug.

--Sean

On 08/08/2016 03:28 AM, Weijun Wang wrote:
> Hi All
>
> Please review the code change at
>
>    http://cr.openjdk.java.net/~weijun/8163303/webrev.00
>
> I removed the "@SuppressWarnings("deprecation")" at the beginning. I
> think this has been unnecessary for quite a while since calls to
> deprecated classes (ContentSigner and ContentSignerParameters) have been
> moved to the new JarSigner API.
>
> *Leo*: I take the chance to update localized Resourses.java files for
> Japanese and Chinese, since this is only about removing items. Please
> confirm this is OK.
>
> Thanks
> Max


From weijun.wang at oracle.com  Mon Aug  8 13:42:51 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 8 Aug 2016 21:42:51 +0800
Subject: RFR 8163303: Remove identity scope information from jarsigner
	-verbose output
In-Reply-To: <b7b66867-ff42-c5c4-16ae-29815cb9763f@oracle.com>
References: <f84c78ee-3687-a6b7-4120-12a0515017e2@oracle.com>
	<b7b66867-ff42-c5c4-16ae-29815cb9763f@oracle.com>
Message-ID: <17431033-98d8-b4a5-725c-716766a8fc49@oracle.com>

Thanks. I'll add noreg-cleanup.

--Max

On 8/8/2016 21:33, Sean Mullan wrote:
> Looks good to me. You will need to add an appropriate noreg label to the
> bug.
>
> --Sean
>
> On 08/08/2016 03:28 AM, Weijun Wang wrote:
>> Hi All
>>
>> Please review the code change at
>>
>>    http://cr.openjdk.java.net/~weijun/8163303/webrev.00
>>
>> I removed the "@SuppressWarnings("deprecation")" at the beginning. I
>> think this has been unnecessary for quite a while since calls to
>> deprecated classes (ContentSigner and ContentSignerParameters) have been
>> moved to the new JarSigner API.
>>
>> *Leo*: I take the chance to update localized Resourses.java files for
>> Japanese and Chinese, since this is only about removing items. Please
>> confirm this is OK.
>>
>> Thanks
>> Max


From weijun.wang at oracle.com  Mon Aug  8 13:46:24 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 8 Aug 2016 21:46:24 +0800
Subject: RFR 8162739: Create new keytool option to access cacerts file
Message-ID: <6775374d-e095-179b-c5db-f29916b9a273@oracle.com>

Please review the code changes at

    http://cr.openjdk.java.net/~weijun/8162739/webrev.00/

A new -cacerts option is added to keytool so there is no need to provide 
the full cacerts path on the command line. lib/security/cacerts is 
considered an implementation detail and subject to change.

The conf/security/cacerts file in src/ is moved to lib/security/cacerts, 
which matches its destination path. A small change in make/ is needed.

Thanks
Max


From erik.joelsson at oracle.com  Mon Aug  8 13:54:40 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 8 Aug 2016 15:54:40 +0200
Subject: RFR 8162739: Create new keytool option to access cacerts file
In-Reply-To: <6775374d-e095-179b-c5db-f29916b9a273@oracle.com>
References: <6775374d-e095-179b-c5db-f29916b9a273@oracle.com>
Message-ID: <11e97489-6ae1-4ed1-5d0b-2fc9abbd0b84@oracle.com>

Build change looks fine.

/Erik


On 2016-08-08 15:46, Weijun Wang wrote:
> Please review the code changes at
>
>    http://cr.openjdk.java.net/~weijun/8162739/webrev.00/
>
> A new -cacerts option is added to keytool so there is no need to 
> provide the full cacerts path on the command line. 
> lib/security/cacerts is considered an implementation detail and 
> subject to change.
>
> The conf/security/cacerts file in src/ is moved to 
> lib/security/cacerts, which matches its destination path. A small 
> change in make/ is needed.
>
> Thanks
> Max



From vincent.x.ryan at oracle.com  Mon Aug  8 17:37:14 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Mon, 8 Aug 2016 18:37:14 +0100
Subject: RFR 8162739: Create new keytool option to access cacerts file
In-Reply-To: <6775374d-e095-179b-c5db-f29916b9a273@oracle.com>
References: <6775374d-e095-179b-c5db-f29916b9a273@oracle.com>
Message-ID: <E0BF9A6F-9374-497D-B89B-46D145911980@oracle.com>

Your changes look good to me.
Thanks.


> On 8 Aug 2016, at 14:46, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please review the code changes at
> 
>   http://cr.openjdk.java.net/~weijun/8162739/webrev.00/
> 
> A new -cacerts option is added to keytool so there is no need to provide the full cacerts path on the command line. lib/security/cacerts is considered an implementation detail and subject to change.
> 
> The conf/security/cacerts file in src/ is moved to lib/security/cacerts, which matches its destination path. A small change in make/ is needed.
> 
> Thanks
> Max



From jamil.j.nimeh at oracle.com  Mon Aug  8 21:50:52 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 8 Aug 2016 14:50:52 -0700
Subject: [Update] RFR 8132943: ServerHandshaker may select non-empty
	OCSPStatusRequest structures when Responder ID selection is not
	supported
In-Reply-To: <4f2937f4-ba59-ffec-92d3-409b9e420bf9@oracle.com>
References: <4f2937f4-ba59-ffec-92d3-409b9e420bf9@oracle.com>
Message-ID: <d6ae82ac-1b75-63e9-eee5-0a2905841916@oracle.com>

Hello all, this update removes an unnecessary change in 
test/javax/net/ssl, adds in some additional logging, and an early exit 
condition from the loop if an acceptable status_request_v2 item is found 
(favoring OCSP_MULTI over OCSP).  Also an additional test case that 
exercises this exit condition was added.

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

Thanks,

--Jamil


On 08/05/2016 09:56 PM, Jamil Nimeh wrote:
> Hello all,
>
> This fixes an issue with OCSPStatusRequest selection by the server 
> when doing OCSP stapling.  Since we currently do not support responder 
> ID filtering, the server should not select an OCSPStatusRequest with 
> responder IDs in it, else it could potentially return OCSP responses 
> that the client has already stated it would not trust.  This fix takes 
> care of that.  If the server cannot find an OCSPStatusRequest that is 
> suitable (in this case, one that has an empty responder ID list) it 
> will not do stapling for that handshake.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8132943
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132943/webrev.01
>
> Thanks,
> --Jamil



From valerie.peng at oracle.com  Mon Aug  8 23:51:37 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 8 Aug 2016 16:51:37 -0700
Subject: [9] RFR 8154113: java.security.AccessControlException: access
	denied ("java.security.SecurityPermission" "authProvider.SunMSCAPI")
In-Reply-To: <445729BB-05DA-4B93-9831-AC7BD06ECEDA@oracle.com>
References: <47578eb2-3adc-acb5-fe6a-330978edc4e8@oracle.com>
	<a7a1eddf-66d0-2196-34b5-026d06528245@oracle.com>
	<5576A0CD-A802-42FD-A38F-2AC4BB7FFC7F@oracle.com>
	<43c5db63-c57c-6741-4820-4f316d84ce96@oracle.com>
	<445729BB-05DA-4B93-9831-AC7BD06ECEDA@oracle.com>
Message-ID: <12e10330-f9b5-16a7-5029-802929ec9549@oracle.com>

Thanks for the comment, I made the updates and will verify with JPRT.

Valerie


On 8/4/2016 9:07 PM, Mandy Chung wrote:
>> On Aug 4, 2016, at 7:20 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 08/04/2016 12:42 AM, Mandy Chung wrote:
>>> A passing comment:
>>>
>>> The test can simply specify @modules jdk.crypto.mscapi and this test will only run when jdk.crypto.mscapi is present; in other words, line 45-48 are no longer needed.
>> Does that also mean line 27 can be removed:
>>
>> 27  * @requires os.family == ?windows"
>>
> I think it should also be removed but you should verify it to make sure jtreg selects this test on windows only (where jdk.crypto.mscap1 is present).
>
> Mandy
>



From sibabrata.sahoo at oracle.com  Tue Aug  9 06:16:37 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Mon, 8 Aug 2016 23:16:37 -0700 (PDT)
Subject: [9] RFR: 8159964: Update Tests to verify JDK build for
	"JDK-8159488 Deprivilege java.xml.crypto"
In-Reply-To: <e5624c68-40e8-40fc-a366-38581939c751@default>
References: <e2c41364-77bf-43db-9991-82f85a39d132@default>
	<d1551d01-adc3-1a78-561f-bed585bb4989@oracle.com>
	<e5624c68-40e8-40fc-a366-38581939c751@default>
Message-ID: <6f4cb691-e0f6-46da-88ae-7624ccaafa33@default>

Ping..

-----Original Message-----
From: Sibabrata Sahoo 
Sent: Friday, August 05, 2016 7:28 PM
To: Weijun Wang; security-dev at openjdk.java.net; Valerie Peng
Subject: RE: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"

Hi Max,

Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.01/

Thanks,
Siba

-----Original Message-----
From: Weijun Wang
Sent: Friday, August 05, 2016 4:19 PM
To: Sibabrata Sahoo; security-dev at openjdk.java.net; Valerie Peng
Subject: Re: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"

I'm looking at DeprivilegedModuleLoaderTest.java.

Why not just call

    classes.add(XMLSignatureFactory.class);

--Max

On 8/5/2016 18:00, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for "deprivilege java.xml.crypto, 
> java.security.jgss, jdk.security.jgss and jdk.security.auth" modules.
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8159964
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.00/
>
>
>
> Description:
>
> This includes a new Test which verifies the classes from 
> "java.xml.crypto, java.security.jgss, jdk.security.jgss and 
> jdk.security.auth" modules get loaded through Platform Classloader. It 
> also includes modifying few existing test to run with Security manager 
> enabled.
>
>
>
> Thanks,
>
> Siba
>
>
>


From sha.jiang at oracle.com  Tue Aug  9 06:35:10 2016
From: sha.jiang at oracle.com (John Jiang)
Date: Tue, 9 Aug 2016 14:35:10 +0800
Subject: [9]RFR 8163435: Update issue number for SupportedDHKeys.java and
	UnsupportedDHKeys.java in ProblemList
Message-ID: <1115cde9-2248-4d63-68d2-72aaed7b3efb@oracle.com>

Hi,
In ProblemList.txt, the tests 
sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java and 
sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java are tracked by 
8154910. However, JDK-8154910 had been closed as the duplicate of 
JDK-8077138.
So, it has to associate both of the above tests to JDK-8077138.

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

Best regards,
John Jiang



From weijun.wang at oracle.com  Tue Aug  9 07:37:37 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 9 Aug 2016 15:37:37 +0800
Subject: RFR 8133910: Some sun/security/tools tests failed.
Message-ID: <5C5B7CA0-4133-49F3-8DE9-10D4F46BF8F1@oracle.com>

Please review the fix at

  http://cr.openjdk.java.net/~weijun/8133910/webrev.00/

Basically, "-J-Duser.language=en -J-Duser.country=US" is added to keytool and jarsigner calls wherever output needs to be compared to some English text.

*Siba*: I modified quite some tests by you. Please confirm it's OK.

Thanks
Max



From weijun.wang at oracle.com  Tue Aug  9 07:51:21 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 9 Aug 2016 15:51:21 +0800
Subject: [9] RFR: 8159964: Update Tests to verify JDK build for
	"JDK-8159488 Deprivilege java.xml.crypto"
In-Reply-To: <6f4cb691-e0f6-46da-88ae-7624ccaafa33@default>
References: <e2c41364-77bf-43db-9991-82f85a39d132@default>
	<d1551d01-adc3-1a78-561f-bed585bb4989@oracle.com>
	<e5624c68-40e8-40fc-a366-38581939c751@default>
	<6f4cb691-e0f6-46da-88ae-7624ccaafa33@default>
Message-ID: <334FB775-E3E9-4A8A-A49F-E1B6D661E3A0@oracle.com>

DeprivilegedModuleLoaderTest.java looks good to me.

I am not sure why you picked those 2 javax.xml.crypto tests. Have they have covered the common functions? I'll let someone else to judge it.

BTW, I would prefer "java.security.policy==test.policy" (or just policy=test.policy) to "java.security.policy=test.policy".

Thanks
Max

> On 2016?8?9?, at ??2:16, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> Ping..
> 
> -----Original Message-----
> From: Sibabrata Sahoo 
> Sent: Friday, August 05, 2016 7:28 PM
> To: Weijun Wang; security-dev at openjdk.java.net; Valerie Peng
> Subject: RE: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"
> 
> Hi Max,
> 
> Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.01/
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Weijun Wang
> Sent: Friday, August 05, 2016 4:19 PM
> To: Sibabrata Sahoo; security-dev at openjdk.java.net; Valerie Peng
> Subject: Re: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"
> 
> I'm looking at DeprivilegedModuleLoaderTest.java.
> 
> Why not just call
> 
>    classes.add(XMLSignatureFactory.class);
> 
> --Max
> 
> On 8/5/2016 18:00, Sibabrata Sahoo wrote:
>> Hi,
>> 
>> 
>> 
>> Please review the patch for "deprivilege java.xml.crypto, 
>> java.security.jgss, jdk.security.jgss and jdk.security.auth" modules.
>> 
>> 
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159964
>> 
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.00/
>> 
>> 
>> 
>> Description:
>> 
>> This includes a new Test which verifies the classes from 
>> "java.xml.crypto, java.security.jgss, jdk.security.jgss and 
>> jdk.security.auth" modules get loaded through Platform Classloader. It 
>> also includes modifying few existing test to run with Security manager 
>> enabled.
>> 
>> 
>> 
>> Thanks,
>> 
>> Siba
>> 
>> 
>> 



From ivan.gerasimov at oracle.com  Tue Aug  9 09:27:26 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 9 Aug 2016 12:27:26 +0300
Subject: [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart card"
	popup windows
Message-ID: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>

Hello!

In order to reduce the number of popup dialog windows during accessing 
the smartcard, it is proposed to first do a silent "probe" step.
Only if this probe succeeded, or if it failed due to that SILENT flag, 
we'll try to re-acquire the key normally (i.e. not silently).

Would you please help review this proposal?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153438
WEBREV: http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/

With kind regards,
Ivan



From sean.coffey at oracle.com  Tue Aug  9 10:33:03 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 9 Aug 2016 11:33:03 +0100
Subject: JDK-8152524
In-Reply-To: <1467657865.2758173.1468450659825.JavaMail.yahoo@mail.yahoo.com>
References: <1467657865.2758173.1468450659825.JavaMail.yahoo.ref@mail.yahoo.com>
	<1467657865.2758173.1468450659825.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <e3fbce52-cbec-d9aa-a43d-cc48dcd23d88@oracle.com>

Hi Sheon,

only see your mail now. The issue turned out to be a McAfee issue. They 
issued a new patch. You'll have to contact them.

Regards,
Sean.

On 13/07/2016 23:57, sheon banks wrote:
> Hi All,
>
> This message is actually for Sean Coffey in relation to the 
> JDK-8152524.  I saw the incident on the Web.  I am having a similar 
> issue.  In the post, it is stated that this is being tracked 
> elsewhere. Can you tell me where?  I would like to know if it is being 
> treated as an MS or McAfee issue.
>
> Sheon Banks

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

From sean.mullan at oracle.com  Tue Aug  9 13:38:26 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 9 Aug 2016 09:38:26 -0400
Subject: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed
	on solaris12(sparcv9 and x86)
In-Reply-To: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>
References: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>
Message-ID: <42279da0-e45a-9809-c1f2-f3fcaaf58951@oracle.com>

Is there any way to split the Ucrypto MessageDigest implementation into 
2 classes, one that implements Cloneable and the other which doesn't, 
and use the appropriate one depending on which OS version you are on?

This way, instead of calling clone and catching 
CloneNotSupportedException, you could just check each MessageDigest 
object to see if it implements Cloneable.

--Sean


On 08/04/2016 10:01 PM, Valerie Peng wrote:
>
> Anyone has time to review this fix? The code change is in only one file
> and straightforward if you agree with the approach.
> Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto
> APIs for message digest operations and there is no clone support.
> This affects the MAC impls of SunJCE provider which delegates the digest
> operation to the most preferred provider.
> To ensure the clone support, I will switch to getting the digest impl
> from SUN provider if the most preferred one does not.
> In the case of SUN provider is not available, it will then goes through
> provider list.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8157579
> Webrev: http://cr.openjdk.java.net/~valeriep/8157579/webrev.00/
>
> No new test as it's covered by existing regression test.
>
> Thanks,
> Valerie
>
>


From weijun.wang at oracle.com  Tue Aug  9 15:37:56 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 9 Aug 2016 23:37:56 +0800
Subject: RFR 8163489: Avoid using Utils.getFreePort() in
	TsacertOptionTest.java test
Message-ID: <d5c26d79-7c3a-5059-038d-82211f5146d2@oracle.com>

http://cr.openjdk.java.net/~weijun/8163489/webrev.00


From weijun.wang at oracle.com  Tue Aug  9 15:39:36 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 9 Aug 2016 23:39:36 +0800
Subject: RFR 8133910: Some sun/security/tools tests failed.
In-Reply-To: <5C5B7CA0-4133-49F3-8DE9-10D4F46BF8F1@oracle.com>
References: <5C5B7CA0-4133-49F3-8DE9-10D4F46BF8F1@oracle.com>
Message-ID: <86277a3c-aba6-de44-d09d-a9b3a585184a@oracle.com>

I was wrong. The test were written by Artem.

--Max

On 8/9/2016 15:37, Wang Weijun wrote:
> Please review the fix at
>
>   http://cr.openjdk.java.net/~weijun/8133910/webrev.00/
>
> Basically, "-J-Duser.language=en -J-Duser.country=US" is added to keytool and jarsigner calls wherever output needs to be compared to some English text.
>
> *Siba*: I modified quite some tests by you. Please confirm it's OK.
>
> Thanks
> Max
>


From chris.hegarty at oracle.com  Tue Aug  9 15:46:16 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 9 Aug 2016 16:46:16 +0100
Subject: RFR 8163489: Avoid using Utils.getFreePort() in
	TsacertOptionTest.java test
In-Reply-To: <d5c26d79-7c3a-5059-038d-82211f5146d2@oracle.com>
References: <d5c26d79-7c3a-5059-038d-82211f5146d2@oracle.com>
Message-ID: <E6643547-D876-4FC4-9C38-9B2CC14754AE@oracle.com>

On 9 Aug 2016, at 16:37, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~weijun/8163489/webrev.00

Thanks Max, this looks good( one less use of the get free port anti-pattern! ).

-Chris.

From sean.mullan at oracle.com  Tue Aug  9 17:43:22 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 9 Aug 2016 13:43:22 -0400
Subject: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed
	on solaris12(sparcv9 and x86)
In-Reply-To: <42279da0-e45a-9809-c1f2-f3fcaaf58951@oracle.com>
References: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>
	<42279da0-e45a-9809-c1f2-f3fcaaf58951@oracle.com>
Message-ID: <62772189-4c08-8ffc-10e5-26dcf57d92ef@oracle.com>

Or better yet, just change the ucrypto impl to not implement Cloneable 
regardless what Solaris version you are on. Then you can just check each 
MessageDigest impl to see if it is an instanceof Cloneable rather than 
calling clone on each.

--Sean

On 08/09/2016 09:38 AM, Sean Mullan wrote:
> Is there any way to split the Ucrypto MessageDigest implementation into
> 2 classes, one that implements Cloneable and the other which doesn't,
> and use the appropriate one depending on which OS version you are on?
>
> This way, instead of calling clone and catching
> CloneNotSupportedException, you could just check each MessageDigest
> object to see if it implements Cloneable.
>
> --Sean
>
>
> On 08/04/2016 10:01 PM, Valerie Peng wrote:
>>
>> Anyone has time to review this fix? The code change is in only one file
>> and straightforward if you agree with the approach.
>> Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto
>> APIs for message digest operations and there is no clone support.
>> This affects the MAC impls of SunJCE provider which delegates the digest
>> operation to the most preferred provider.
>> To ensure the clone support, I will switch to getting the digest impl
>> from SUN provider if the most preferred one does not.
>> In the case of SUN provider is not available, it will then goes through
>> provider list.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157579
>> Webrev: http://cr.openjdk.java.net/~valeriep/8157579/webrev.00/
>>
>> No new test as it's covered by existing regression test.
>>
>> Thanks,
>> Valerie
>>
>>


From artem.smotrakov at oracle.com  Tue Aug  9 17:49:39 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 9 Aug 2016 10:49:39 -0700
Subject: RFR 8163489: Avoid using Utils.getFreePort() in
	TsacertOptionTest.java test
In-Reply-To: <E6643547-D876-4FC4-9C38-9B2CC14754AE@oracle.com>
References: <d5c26d79-7c3a-5059-038d-82211f5146d2@oracle.com>
	<E6643547-D876-4FC4-9C38-9B2CC14754AE@oracle.com>
Message-ID: <2bc5dbc8-532b-7e0d-674e-2c6a8be5d108@oracle.com>

+1

Minor: no need a semicolon in "try" block, I originally added it by 
mistake. You also may want to update a copyright year.

Artem


On 08/09/2016 08:46 AM, Chris Hegarty wrote:
> On 9 Aug 2016, at 16:37, Weijun Wang <weijun.wang at oracle.com> wrote:
>> http://cr.openjdk.java.net/~weijun/8163489/webrev.00
> Thanks Max, this looks good( one less use of the get free port anti-pattern! ).
>
> -Chris.



From artem.smotrakov at oracle.com  Tue Aug  9 17:58:04 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Tue, 9 Aug 2016 10:58:04 -0700
Subject: RFR 8133910: Some sun/security/tools tests failed.
In-Reply-To: <86277a3c-aba6-de44-d09d-a9b3a585184a@oracle.com>
References: <5C5B7CA0-4133-49F3-8DE9-10D4F46BF8F1@oracle.com>
	<86277a3c-aba6-de44-d09d-a9b3a585184a@oracle.com>
Message-ID: <ca54156f-4728-5477-2ec7-e5a78e0f7c06@oracle.com>

Hi Max,

The update looks good to me.

Artem


On 08/09/2016 08:39 AM, Weijun Wang wrote:
> I was wrong. The test were written by Artem.
>
> --Max
>
> On 8/9/2016 15:37, Wang Weijun wrote:
>> Please review the fix at
>>
>>   http://cr.openjdk.java.net/~weijun/8133910/webrev.00/
>>
>> Basically, "-J-Duser.language=en -J-Duser.country=US" is added to 
>> keytool and jarsigner calls wherever output needs to be compared to 
>> some English text.
>>
>> *Siba*: I modified quite some tests by you. Please confirm it's OK.
>>
>> Thanks
>> Max
>>



From vincent.x.ryan at oracle.com  Tue Aug  9 18:14:14 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Tue, 9 Aug 2016 19:14:14 +0100
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509 certificates
Message-ID: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>

Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore.
The PKCS12 keystore implementation supports storing only X509Certificate objects but the KeyStore API allows Certificate objects.
This fix rejects attempts to store non-X.509 certificates and throws a KeyStoreException.

Thanks.

Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/




From sean.mullan at oracle.com  Tue Aug  9 19:19:21 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 9 Aug 2016 15:19:21 -0400
Subject: RFR 8162739: Create new keytool option to access cacerts file
In-Reply-To: <6775374d-e095-179b-c5db-f29916b9a273@oracle.com>
References: <6775374d-e095-179b-c5db-f29916b9a273@oracle.com>
Message-ID: <faf6a9be-132b-e2f8-ed4e-d83e358f1579@oracle.com>

- src/java.base/share/classes/sun/security/tools/keytool/Resources.java

131                 "operates on the cacerts keystore"}, // -cacerts

"operates" sounds a little odd. How about "access the cacerts keystore" 
(so it is consistent with the warning below).

133                 "Warning: use -cacerts option to access cacerts 
keystore"},

Warning: use the -cacerts option to access the cacerts keystore

--Sean

On 08/08/2016 09:46 AM, Weijun Wang wrote:
> Please review the code changes at
>
>    http://cr.openjdk.java.net/~weijun/8162739/webrev.00/
>
> A new -cacerts option is added to keytool so there is no need to provide
> the full cacerts path on the command line. lib/security/cacerts is
> considered an implementation detail and subject to change.
>
> The conf/security/cacerts file in src/ is moved to lib/security/cacerts,
> which matches its destination path. A small change in make/ is needed.
>
> Thanks
> Max


From xuelei.fan at oracle.com  Tue Aug  9 23:29:09 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 10 Aug 2016 07:29:09 +0800
Subject: [Update] RFR 8132943: ServerHandshaker may select non-empty
	OCSPStatusRequest structures when Responder ID selection is not
	supported
In-Reply-To: <d6ae82ac-1b75-63e9-eee5-0a2905841916@oracle.com>
References: <4f2937f4-ba59-ffec-92d3-409b9e420bf9@oracle.com>
	<d6ae82ac-1b75-63e9-eee5-0a2905841916@oracle.com>
Message-ID: <e6e10778-6d50-69b8-2cbe-d40316810310@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 8/9/2016 5:50 AM, Jamil Nimeh wrote:
> Hello all, this update removes an unnecessary change in
> test/javax/net/ssl, adds in some additional logging, and an early exit
> condition from the loop if an acceptable status_request_v2 item is found
> (favoring OCSP_MULTI over OCSP).  Also an additional test case that
> exercises this exit condition was added.
> 
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132943/webrev.02
> 
> Thanks,
> 
> --Jamil
> 
> 
> On 08/05/2016 09:56 PM, Jamil Nimeh wrote:
>> Hello all,
>>
>> This fixes an issue with OCSPStatusRequest selection by the server
>> when doing OCSP stapling.  Since we currently do not support responder
>> ID filtering, the server should not select an OCSPStatusRequest with
>> responder IDs in it, else it could potentially return OCSP responses
>> that the client has already stated it would not trust.  This fix takes
>> care of that.  If the server cannot find an OCSPStatusRequest that is
>> suitable (in this case, one that has an empty responder ID list) it
>> will not do stapling for that handshake.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132943
>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8132943/webrev.01
>>
>> Thanks,
>> --Jamil
> 



From valerie.peng at oracle.com  Wed Aug 10 00:25:41 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 9 Aug 2016 17:25:41 -0700
Subject: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed
	on solaris12(sparcv9 and x86)
In-Reply-To: <F4F24844-63AA-4A03-B1C1-64DD64BA2FB0@oracle.com>
References: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>
	<F4F24844-63AA-4A03-B1C1-64DD64BA2FB0@oracle.com>
Message-ID: <d4c0a012-37bf-abbf-b44d-08baaa25dead@oracle.com>

Thanks for the review~

Your point is valid for default configuration. But in the rare case 
where the new jdk.security.provider.preferred property is set, the most 
preferred provider may not be the one which supplied the digest object 
for the generic getInstance() call.

So, instead of removing the first provider, I added a check to skip 
calling getInstance() if the provider name comparison matched.
Webrev updated at: http://cr.openjdk.java.net/~valeriep/8157579/webrev.01/

Thanks,
Valerie

On 8/5/2016 4:02 AM, Vincent Ryan wrote:
> Your fix looks good. One comment is that you could trim the Provider[] to exclude the most-preferred provider (at index=0).
> Thanks.
>
>
>> On 5 Aug 2016, at 03:01, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>>
>> Anyone has time to review this fix? The code change is in only one file and straightforward if you agree with the approach.
>> Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto APIs for message digest operations and there is no clone support.
>> This affects the MAC impls of SunJCE provider which delegates the digest operation to the most preferred provider.
>> To ensure the clone support, I will switch to getting the digest impl from SUN provider if the most preferred one does not.
>> In the case of SUN provider is not available, it will then goes through provider list.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157579
>> Webrev: http://cr.openjdk.java.net/~valeriep/8157579/webrev.00/
>>
>> No new test as it's covered by existing regression test.
>>
>> Thanks,
>> Valerie
>>
>>



From weijun.wang at oracle.com  Wed Aug 10 00:38:14 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 10 Aug 2016 08:38:14 +0800
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
Message-ID: <7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>

I thought I've seen this webrev before.

Why not just throw a KeyStoreException in validateChain()?

--Max

On 8/10/2016 2:14, Vincent Ryan wrote:
> Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore.
> The PKCS12 keystore implementation supports storing only X509Certificate objects but the KeyStore API allows Certificate objects.
> This fix rejects attempts to store non-X.509 certificates and throws a KeyStoreException.
>
> Thanks.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>
>


From xuelei.fan at oracle.com  Wed Aug 10 01:04:44 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 10 Aug 2016 09:04:44 +0800
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
Message-ID: <c1eb3632-6ae0-dca7-2773-281222bbc71e@oracle.com>

The for loop at line 1507 and 1520 may be merged together.

Xuelei

On 8/10/2016 8:38 AM, Weijun Wang wrote:
> I thought I've seen this webrev before.
> 
> Why not just throw a KeyStoreException in validateChain()?
> 
> --Max
> 
> On 8/10/2016 2:14, Vincent Ryan wrote:
>> Please review this fix to improve the error handling for attempts to
>> store a Certificate object in PKCS12 keystore.
>> The PKCS12 keystore implementation supports storing only
>> X509Certificate objects but the KeyStore API allows Certificate objects.
>> This fix rejects attempts to store non-X.509 certificates and throws a
>> KeyStoreException.
>>
>> Thanks.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>>
>>



From valerie.peng at oracle.com  Wed Aug 10 02:00:04 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 9 Aug 2016 19:00:04 -0700
Subject: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed
	on solaris12(sparcv9 and x86)
In-Reply-To: <62772189-4c08-8ffc-10e5-26dcf57d92ef@oracle.com>
References: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>
	<42279da0-e45a-9809-c1f2-f3fcaaf58951@oracle.com>
	<62772189-4c08-8ffc-10e5-26dcf57d92ef@oracle.com>
Message-ID: <6681bdab-e019-ea5b-1b17-723019839357@oracle.com>


OracleUcrypto provider already separates them in two classes: The 
cloneable libMD digest impls are encapsulated by a class which 
implements Cloneable and the new un-cloneable Ucrypto digest impls are 
in a class which does not.
I wasn't sure if we can safely assume that an instance supports clone 
when it implements Cloneable. So I thought better call clone() to be 
sure. Given your feedback, I have replaced the clone() calls with 
instanceof checks.

Webrev updated: http://cr.openjdk.java.net/~valeriep/8157579/webrev.02

Thanks,
Valerie


On 8/9/2016 10:43 AM, Sean Mullan wrote:
> Or better yet, just change the ucrypto impl to not implement Cloneable 
> regardless what Solaris version you are on. Then you can just check 
> each MessageDigest impl to see if it is an instanceof Cloneable rather 
> than calling clone on each.
>
> --Sean
>
> On 08/09/2016 09:38 AM, Sean Mullan wrote:
>> Is there any way to split the Ucrypto MessageDigest implementation into
>> 2 classes, one that implements Cloneable and the other which doesn't,
>> and use the appropriate one depending on which OS version you are on?
>>
>> This way, instead of calling clone and catching
>> CloneNotSupportedException, you could just check each MessageDigest
>> object to see if it implements Cloneable.
>>
>> --Sean
>>
>>
>> On 08/04/2016 10:01 PM, Valerie Peng wrote:
>>>
>>> Anyone has time to review this fix? The code change is in only one file
>>> and straightforward if you agree with the approach.
>>> Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto
>>> APIs for message digest operations and there is no clone support.
>>> This affects the MAC impls of SunJCE provider which delegates the 
>>> digest
>>> operation to the most preferred provider.
>>> To ensure the clone support, I will switch to getting the digest impl
>>> from SUN provider if the most preferred one does not.
>>> In the case of SUN provider is not available, it will then goes through
>>> provider list.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157579
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8157579/webrev.00/
>>>
>>> No new test as it's covered by existing regression test.
>>>
>>> Thanks,
>>> Valerie
>>>
>>>



From weijun.wang at oracle.com  Wed Aug 10 03:43:47 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 10 Aug 2016 11:43:47 +0800
Subject: 8163104: Unexpected NPE still possible on some Kerberos ticket
	calls
In-Reply-To: <57A4A1D7.5040203@oracle.com>
References: <57A4A1D7.5040203@oracle.com>
Message-ID: <fa5cfaf5-73ad-df07-7f2d-20e34d95222e@oracle.com>

Change looks fine. Sorry for the late reply.

Thanks
Max

On 8/5/2016 22:25, Se?n Coffey wrote:
> Post JDK-8147772 <https://bugs.openjdk.java.net/browse/JDK-8147772>, I
> think we still have a possibility of hitting an NPE in Kerberos ticket
> management.
>
> Could only find one method affected.
> bug report : https://bugs.openjdk.java.net/browse/JDK-8163104
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8163104.jdk9/webrev/
>
> --
> Regards,
> Sean.
>


From sibabrata.sahoo at oracle.com  Wed Aug 10 09:08:57 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Wed, 10 Aug 2016 09:08:57 +0000 (UTC)
Subject: [9] RFR: 8159964: Update Tests to verify JDK build for
	"JDK-8159488 Deprivilege java.xml.crypto"
In-Reply-To: <334FB775-E3E9-4A8A-A49F-E1B6D661E3A0@oracle.com>
References: <e2c41364-77bf-43db-9991-82f85a39d132@default>
	<d1551d01-adc3-1a78-561f-bed585bb4989@oracle.com>
	<e5624c68-40e8-40fc-a366-38581939c751@default>
	<6f4cb691-e0f6-46da-88ae-7624ccaafa33@default>
	<334FB775-E3E9-4A8A-A49F-E1B6D661E3A0@oracle.com>
Message-ID: <0542fdf7-61d5-4b19-b3a1-319b212cc4ae@default>

Hi Valerie,

I have addressed the suggestion provided by Max to add "==" for the test policy files because " lib/security/default.policy" file is included by default. I am waiting for your suggestion to complete this review.

Here is the latest webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.02/


Thanks,
Siba

-----Original Message-----
From: Wang Weijun 
Sent: Tuesday, August 09, 2016 1:21 PM
To: Sibabrata Sahoo
Cc: security-dev at openjdk.java.net; Valerie Peng
Subject: Re: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"

DeprivilegedModuleLoaderTest.java looks good to me.

I am not sure why you picked those 2 javax.xml.crypto tests. Have they have covered the common functions? I'll let someone else to judge it.

BTW, I would prefer "java.security.policy==test.policy" (or just policy=test.policy) to "java.security.policy=test.policy".

Thanks
Max

> On 2016?8?9?, at ??2:16, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> Ping..
> 
> -----Original Message-----
> From: Sibabrata Sahoo
> Sent: Friday, August 05, 2016 7:28 PM
> To: Weijun Wang; security-dev at openjdk.java.net; Valerie Peng
> Subject: RE: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"
> 
> Hi Max,
> 
> Here is the updated webrev: 
> http://cr.openjdk.java.net/~ssahoo/8159964/webrev.01/
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Weijun Wang
> Sent: Friday, August 05, 2016 4:19 PM
> To: Sibabrata Sahoo; security-dev at openjdk.java.net; Valerie Peng
> Subject: Re: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"
> 
> I'm looking at DeprivilegedModuleLoaderTest.java.
> 
> Why not just call
> 
>    classes.add(XMLSignatureFactory.class);
> 
> --Max
> 
> On 8/5/2016 18:00, Sibabrata Sahoo wrote:
>> Hi,
>> 
>> 
>> 
>> Please review the patch for "deprivilege java.xml.crypto, 
>> java.security.jgss, jdk.security.jgss and jdk.security.auth" modules.
>> 
>> 
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159964
>> 
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.00/
>> 
>> 
>> 
>> Description:
>> 
>> This includes a new Test which verifies the classes from 
>> "java.xml.crypto, java.security.jgss, jdk.security.jgss and 
>> jdk.security.auth" modules get loaded through Platform Classloader. 
>> It also includes modifying few existing test to run with Security 
>> manager enabled.
>> 
>> 
>> 
>> Thanks,
>> 
>> Siba
>> 
>> 
>> 



From sean.coffey at oracle.com  Wed Aug 10 09:59:05 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 10 Aug 2016 10:59:05 +0100
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
Message-ID: <57AAFAE9.6050106@oracle.com>

It would be good if we can print the cert class type in the new 
exception if the instanceof check fails.

Regards,
Sean.

On 09/08/16 19:14, Vincent Ryan wrote:
> Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore.
> The PKCS12 keystore implementation supports storing only X509Certificate objects but the KeyStore API allows Certificate objects.
> This fix rejects attempts to store non-X.509 certificates and throws a KeyStoreException.
>
> Thanks.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>
>



From sean.coffey at oracle.com  Wed Aug 10 13:48:54 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 10 Aug 2016 14:48:54 +0100
Subject: RFR : 8147772, 8163104
Message-ID: <57AB30C6.6020600@oracle.com>

Looking to backport the following two bug fixes to jdk8u-dev :

JDK-8147772 Update KerberosTicket to describe behavior if it has been 
destroyed and fix NullPointerExceptions
JDK-8163104 Unexpected NPE still possible on some Kerberos ticket calls

The changes are similar to JDK 9 expect that the @implNote and javadoc 
edits have been omitted from jdk8u for the 8147772 port.

webrev : 
http://cr.openjdk.java.net/~coffeys/webrev.8147772.8163104.jdk8u/webrev/

-- 
Regards,
Sean.



From weijun.wang at oracle.com  Wed Aug 10 14:31:40 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 10 Aug 2016 22:31:40 +0800
Subject: RFR : 8147772, 8163104
In-Reply-To: <57AB30C6.6020600@oracle.com>
References: <57AB30C6.6020600@oracle.com>
Message-ID: <DFB15EC2-C5E7-494E-A06D-0BD5B9AAEA33@oracle.com>

The changes look fine.

Thanks
Max

> On 2016?8?10?, at ??9:48, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Looking to backport the following two bug fixes to jdk8u-dev :
> 
> JDK-8147772 Update KerberosTicket to describe behavior if it has been destroyed and fix NullPointerExceptions
> JDK-8163104 Unexpected NPE still possible on some Kerberos ticket calls
> 
> The changes are similar to JDK 9 expect that the @implNote and javadoc edits have been omitted from jdk8u for the 8147772 port.
> 
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8147772.8163104.jdk8u/webrev/
> 
> -- 
> Regards,
> Sean.
> 



From chris.hegarty at oracle.com  Wed Aug 10 15:42:08 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 10 Aug 2016 16:42:08 +0100
Subject: RFR [9] 8156841: sun.security.pkcs11.SunPKCS11 poller thread retains
	a strong reference to the context class loader
Message-ID: <FEB9CC36-CA29-430F-B941-B03441CC4821@oracle.com>

The SunPKCS11 poller thread has no need of any user defined class loader,
so should set its context class loader to null before starting, so as to not
inadvertently retain a reference to the creating thread?s context class loader.

In other areas that suffered from a similar issue we changed to use an
InnocuousThread, but I cannot fully satisfy myself that this is a safe
substation here, so I opted for the safest minimal fix. A future refactoring
exercise should consider using InnocuousThread. 

diff -r 92c31ec731eb src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java
--- a/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java	Wed Aug 10 11:54:12 2016 +0100
+++ b/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java	Wed Aug 10 16:32:41 2016 +0100
@@ -809,20 +809,21 @@
         }
     }
 
     // create the poller thread, if not already active
     private void createPoller() {
         if (poller != null) {
             return;
         }
         final TokenPoller poller = new TokenPoller(this);
         Thread t = new Thread(null, poller, "Poller " + getName(), 0, false);
+        t.setContextClassLoader(null);
         t.setDaemon(true);
         t.setPriority(Thread.MIN_PRIORITY);
         t.start();
         this.poller = poller;
     }
 
     // destroy the poller thread, if active
     private void destroyPoller() {
         if (poller != null) {
             poller.disable();

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

-Chris.

From sean.mullan at oracle.com  Wed Aug 10 16:04:08 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 10 Aug 2016 12:04:08 -0400
Subject: [9]RFR 8163435: Update issue number for SupportedDHKeys.java and
	UnsupportedDHKeys.java in ProblemList
In-Reply-To: <1115cde9-2248-4d63-68d2-72aaed7b3efb@oracle.com>
References: <1115cde9-2248-4d63-68d2-72aaed7b3efb@oracle.com>
Message-ID: <571da676-c49c-6f4d-fe4d-c618cac3013c@oracle.com>

Looks fine to me. Please add a noreg-trivial or noreg-cleanup label to 
the bug.

--Sean

On 08/09/2016 02:35 AM, John Jiang wrote:
> Hi,
> In ProblemList.txt, the tests
> sun/security/pkcs11/KeyAgreement/SupportedDHKeys.java and
> sun/security/pkcs11/KeyAgreement/UnsupportedDHKeys.java are tracked by
> 8154910. However, JDK-8154910 had been closed as the duplicate of
> JDK-8077138.
> So, it has to associate both of the above tests to JDK-8077138.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8163435
> Webrev: http://cr.openjdk.java.net/~jjiang/8163435/webrev.00
>
> Best regards,
> John Jiang
>


From vincent.x.ryan at oracle.com  Wed Aug 10 16:39:36 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 10 Aug 2016 17:39:36 +0100
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
Message-ID: <91EFA7E5-0B58-4EC7-9902-EFA9EBCC2798@oracle.com>

You?re right. This same issue had been reported as an obscure JCK test failure.
I created this new bug to clarify the issue.

I?ve updated the webrev to include your suggestion:
  http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/

Thanks.


> On 10 Aug 2016, at 01:38, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> I thought I've seen this webrev before.
> 
> Why not just throw a KeyStoreException in validateChain()?
> 
> --Max
> 
> On 8/10/2016 2:14, Vincent Ryan wrote:
>> Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore.
>> The PKCS12 keystore implementation supports storing only X509Certificate objects but the KeyStore API allows Certificate objects.
>> This fix rejects attempts to store non-X.509 certificates and throws a KeyStoreException.
>> 
>> Thanks.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>> 
>> 



From vincent.x.ryan at oracle.com  Wed Aug 10 16:39:41 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 10 Aug 2016 17:39:41 +0100
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <c1eb3632-6ae0-dca7-2773-281222bbc71e@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
	<c1eb3632-6ae0-dca7-2773-281222bbc71e@oracle.com>
Message-ID: <965F1A6E-D41B-4061-A6D9-F21004F95020@oracle.com>

Yes they could be merged but the first loop iterates over all the certs and the second one iterates over all but the final cert.
And the special case of a 1-cert chain also needs to be handled. I think it?s a little clearer to leave them separate.

An updated webrev is at:
  http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/

Thanks.

> On 10 Aug 2016, at 02:04, Xuelei Fan <Xuelei.Fan at Oracle.Com> wrote:
> 
> The for loop at line 1507 and 1520 may be merged together.
> 
> Xuelei
> 
> On 8/10/2016 8:38 AM, Weijun Wang wrote:
>> I thought I've seen this webrev before.
>> 
>> Why not just throw a KeyStoreException in validateChain()?
>> 
>> --Max
>> 
>> On 8/10/2016 2:14, Vincent Ryan wrote:
>>> Please review this fix to improve the error handling for attempts to
>>> store a Certificate object in PKCS12 keystore.
>>> The PKCS12 keystore implementation supports storing only
>>> X509Certificate objects but the KeyStore API allows Certificate objects.
>>> This fix rejects attempts to store non-X.509 certificates and throws a
>>> KeyStoreException.
>>> 
>>> Thanks.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>>> 
>>> 
> 



From vincent.x.ryan at oracle.com  Wed Aug 10 16:39:47 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 10 Aug 2016 17:39:47 +0100
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <57AAFAE9.6050106@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<57AAFAE9.6050106@oracle.com>
Message-ID: <DDF71474-EDE6-42D3-8893-569BA63CE445@oracle.com>

I?ve updated the webrev to include your suggestion:
  http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/

Thanks.

> On 10 Aug 2016, at 10:59, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> It would be good if we can print the cert class type in the new exception if the instanceof check fails.
> 
> Regards,
> Sean.
> 
> On 09/08/16 19:14, Vincent Ryan wrote:
>> Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore.
>> The PKCS12 keystore implementation supports storing only X509Certificate objects but the KeyStore API allows Certificate objects.
>> This fix rejects attempts to store non-X.509 certificates and throws a KeyStoreException.
>> 
>> Thanks.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>> 
>> 
> 



From sean.coffey at oracle.com  Wed Aug 10 16:43:52 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 10 Aug 2016 17:43:52 +0100
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <DDF71474-EDE6-42D3-8893-569BA63CE445@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<57AAFAE9.6050106@oracle.com>
	<DDF71474-EDE6-42D3-8893-569BA63CE445@oracle.com>
Message-ID: <57AB59C8.5020906@oracle.com>

Looks good. Thanks.

Regards,
Sean.

On 10/08/16 17:39, Vincent Ryan wrote:
> I?ve updated the webrev to include your suggestion:
>    http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/
>
> Thanks.
>
>> On 10 Aug 2016, at 10:59, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>
>> It would be good if we can print the cert class type in the new exception if the instanceof check fails.
>>
>> Regards,
>> Sean.
>>
>> On 09/08/16 19:14, Vincent Ryan wrote:
>>> Please review this fix to improve the error handling for attempts to store a Certificate object in PKCS12 keystore.
>>> The PKCS12 keystore implementation supports storing only X509Certificate objects but the KeyStore API allows Certificate objects.
>>> This fix rejects attempts to store non-X.509 certificates and throws a KeyStoreException.
>>>
>>> Thanks.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>>>
>>>



From valerie.peng at oracle.com  Wed Aug 10 16:51:48 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 10 Aug 2016 09:51:48 -0700
Subject: [9] RFR: 8159964: Update Tests to verify JDK build for
	"JDK-8159488 Deprivilege java.xml.crypto"
In-Reply-To: <0542fdf7-61d5-4b19-b3a1-319b212cc4ae@default>
References: <e2c41364-77bf-43db-9991-82f85a39d132@default>
	<d1551d01-adc3-1a78-561f-bed585bb4989@oracle.com>
	<e5624c68-40e8-40fc-a366-38581939c751@default>
	<6f4cb691-e0f6-46da-88ae-7624ccaafa33@default>
	<334FB775-E3E9-4A8A-A49F-E1B6D661E3A0@oracle.com>
	<0542fdf7-61d5-4b19-b3a1-319b212cc4ae@default>
Message-ID: <072eb311-c86e-f659-7328-9b77bfaec84e@oracle.com>


Changes look fine.
Thanks,
Valerie

On 8/10/2016 2:08 AM, Sibabrata Sahoo wrote:
> Hi Valerie,
>
> I have addressed the suggestion provided by Max to add "==" for the test policy files because " lib/security/default.policy" file is included by default. I am waiting for your suggestion to complete this review.
>
> Here is the latest webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.02/
>
>
> Thanks,
> Siba
>
> -----Original Message-----
> From: Wang Weijun
> Sent: Tuesday, August 09, 2016 1:21 PM
> To: Sibabrata Sahoo
> Cc: security-dev at openjdk.java.net; Valerie Peng
> Subject: Re: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"
>
> DeprivilegedModuleLoaderTest.java looks good to me.
>
> I am not sure why you picked those 2 javax.xml.crypto tests. Have they have covered the common functions? I'll let someone else to judge it.
>
> BTW, I would prefer "java.security.policy==test.policy" (or just policy=test.policy) to "java.security.policy=test.policy".
>
> Thanks
> Max
>
>> On 2016?8?9?, at ??2:16, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
>>
>> Ping..
>>
>> -----Original Message-----
>> From: Sibabrata Sahoo
>> Sent: Friday, August 05, 2016 7:28 PM
>> To: Weijun Wang; security-dev at openjdk.java.net; Valerie Peng
>> Subject: RE: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"
>>
>> Hi Max,
>>
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~ssahoo/8159964/webrev.01/
>>
>> Thanks,
>> Siba
>>
>> -----Original Message-----
>> From: Weijun Wang
>> Sent: Friday, August 05, 2016 4:19 PM
>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; Valerie Peng
>> Subject: Re: [9] RFR: 8159964: Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml.crypto"
>>
>> I'm looking at DeprivilegedModuleLoaderTest.java.
>>
>> Why not just call
>>
>>     classes.add(XMLSignatureFactory.class);
>>
>> --Max
>>
>> On 8/5/2016 18:00, Sibabrata Sahoo wrote:
>>> Hi,
>>>
>>>
>>>
>>> Please review the patch for "deprivilege java.xml.crypto,
>>> java.security.jgss, jdk.security.jgss and jdk.security.auth" modules.
>>>
>>>
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8159964
>>>
>>> Webrev: http://cr.openjdk.java.net/~ssahoo/8159964/webrev.00/
>>>
>>>
>>>
>>> Description:
>>>
>>> This includes a new Test which verifies the classes from
>>> "java.xml.crypto, java.security.jgss, jdk.security.jgss and
>>> jdk.security.auth" modules get loaded through Platform Classloader.
>>> It also includes modifying few existing test to run with Security
>>> manager enabled.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Siba
>>>
>>>
>>>



From jamil.j.nimeh at oracle.com  Wed Aug 10 18:12:51 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 10 Aug 2016 11:12:51 -0700
Subject: RFR [9] 8156841: sun.security.pkcs11.SunPKCS11 poller thread
	retains a strong reference to the context class loader
In-Reply-To: <FEB9CC36-CA29-430F-B941-B03441CC4821@oracle.com>
References: <FEB9CC36-CA29-430F-B941-B03441CC4821@oracle.com>
Message-ID: <c8d8db91-bf5b-14cb-dfc0-47fbdfdba294@oracle.com>

Hi Chris, I am not an official reviewer, but this looks pretty 
straightforward to me.

--Jamil


On 08/10/2016 08:42 AM, Chris Hegarty wrote:
> The SunPKCS11 poller thread has no need of any user defined class loader,
> so should set its context class loader to null before starting, so as to not
> inadvertently retain a reference to the creating thread?s context class loader.
>
> In other areas that suffered from a similar issue we changed to use an
> InnocuousThread, but I cannot fully satisfy myself that this is a safe
> substation here, so I opted for the safest minimal fix. A future refactoring
> exercise should consider using InnocuousThread.
>
> diff -r 92c31ec731eb src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java
> --- a/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java	Wed Aug 10 11:54:12 2016 +0100
> +++ b/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java	Wed Aug 10 16:32:41 2016 +0100
> @@ -809,20 +809,21 @@
>           }
>       }
>   
>       // create the poller thread, if not already active
>       private void createPoller() {
>           if (poller != null) {
>               return;
>           }
>           final TokenPoller poller = new TokenPoller(this);
>           Thread t = new Thread(null, poller, "Poller " + getName(), 0, false);
> +        t.setContextClassLoader(null);
>           t.setDaemon(true);
>           t.setPriority(Thread.MIN_PRIORITY);
>           t.start();
>           this.poller = poller;
>       }
>   
>       // destroy the poller thread, if active
>       private void destroyPoller() {
>           if (poller != null) {
>               poller.disable();
>
> https://bugs.openjdk.java.net/browse/JDK-8156841
>
> -Chris.



From sean.mullan at oracle.com  Wed Aug 10 18:19:39 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 10 Aug 2016 14:19:39 -0400
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
Message-ID: <53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>

Hi Brad,

Looks pretty good. You should also send this to build-dev to review the 
Makefile changes. Just a few comments:

- src/java.base/share/conf/security/policy/README.txt

17 contain no restrictions on cryptographic strengths, but they must

s/must/must be/

18 specifically activated by updating the "crypto.policy" entry in the

s/entry/Security property/

33 Please see The Java(TM) Cryptography Architecture (JCA) Reference

Is "TM" really necessary here?

- 
src/java.base/share/conf/security/policy/unlimited/default_US_export.policy

1 // Manufacturing policy file.

The term "Manufacturing" is odd. Can we just say this is the "Default 
local policy file"?

- src/java.base/share/conf/security/java.security

854 crypto.policy=policydir-tbd

The policydir-tbd value is a little confusing in that it isn't a real 
value. What about just setting this to the empty string?

- src/java.base/share/classes/javax/crypto/JceSecurity.java

  255         String cryptoPolicyDir = 
Security.getProperty("crypto.policy");
  256         Path cryptoPolicyPath = Paths.get(cryptoPolicyDir);

What happens if crypto.policy is not set or is set to ""?

302             // I/O error encounted during the iteration,

s/encounted/encountered/

--Sean

On 08/04/2016 03:35 PM, Bradford Wetmore wrote:
> https://bugs.openjdk.java.net/browse/JDK-8061842
> http://cr.openjdk.java.net/~wetmore/8061842/webrev.00/
>
> The proposal is to move the configuration files from the jar files in
> <java-home>/lib/security to a series of subdirectories under a new
> "policy" subdirectory in <java-home>/conf/security.  Each subdirectory
> within that directory will represent a complete policy configuration.
> The existing jar files will be split into flat text files such that the
> current/existing policies remain.
>
> The default set of policy files (i.e. directory) is configured using a
> new java.security.Security property called "crypto.policy" which will be
> added to the <java-home>/conf/security/java.security file.  The default
> initial options are "limited" or "unlimited", however additional
> directories could potentially be created that specify other
> as-yet-unknown policies.
>
> The default value of this property will be "limited" which corresponds
> to our current policy for JRE/JDK export/import around the world.
> However, the build respects the following "configure" option:
>
>     --enable-unlimited-crypto
>                         Enable unlimited crypto policy [disabled]
>
> Within the directory, our implementation will look for files using the
> standard filename prefix above ("default_" or "exempt_"), thus new
> additional policy restrictions/abstractions can be added with a simple
> file addition.
>
> Brad
>


From sean.mullan at oracle.com  Wed Aug 10 20:15:33 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 10 Aug 2016 16:15:33 -0400
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <965F1A6E-D41B-4061-A6D9-F21004F95020@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
	<c1eb3632-6ae0-dca7-2773-281222bbc71e@oracle.com>
	<965F1A6E-D41B-4061-A6D9-F21004F95020@oracle.com>
Message-ID: <a71707c1-5fa7-9084-5f43-ea579857263c@oracle.com>

On 08/10/2016 12:39 PM, Vincent Ryan wrote:
> Yes they could be merged but the first loop iterates over all the certs and the second one iterates over all but the final cert.
> And the special case of a 1-cert chain also needs to be handled. I think it?s a little clearer to leave them separate.

Agreed, but it's probably better to check these earlier and bail out if 
they are not all X509Certificates, for example, right at the beginning 
of engineSetKeyEntry. There is no need to proceed with decoding keys, 
etc since it is already a violation of the supported API parameters.

--Sean

>
> An updated webrev is at:
>   http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/
>
> Thanks.
>
>> On 10 Aug 2016, at 02:04, Xuelei Fan <Xuelei.Fan at Oracle.Com> wrote:
>>
>> The for loop at line 1507 and 1520 may be merged together.
>>
>> Xuelei
>>
>> On 8/10/2016 8:38 AM, Weijun Wang wrote:
>>> I thought I've seen this webrev before.
>>>
>>> Why not just throw a KeyStoreException in validateChain()?
>>>
>>> --Max
>>>
>>> On 8/10/2016 2:14, Vincent Ryan wrote:
>>>> Please review this fix to improve the error handling for attempts to
>>>> store a Certificate object in PKCS12 keystore.
>>>> The PKCS12 keystore implementation supports storing only
>>>> X509Certificate objects but the KeyStore API allows Certificate objects.
>>>> This fix rejects attempts to store non-X.509 certificates and throws a
>>>> KeyStoreException.
>>>>
>>>> Thanks.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>>>>
>>>>
>>
>


From valerie.peng at oracle.com  Wed Aug 10 20:27:35 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 10 Aug 2016 13:27:35 -0700
Subject: RFR [9] 8156841: sun.security.pkcs11.SunPKCS11 poller thread
	retains a strong reference to the context class loader
In-Reply-To: <FEB9CC36-CA29-430F-B941-B03441CC4821@oracle.com>
References: <FEB9CC36-CA29-430F-B941-B03441CC4821@oracle.com>
Message-ID: <ed461825-3b8a-7f1b-245a-e7817f48e944@oracle.com>


Changes look fine.
Thanks,
Valerie

On 8/10/2016 8:42 AM, Chris Hegarty wrote:
> The SunPKCS11 poller thread has no need of any user defined class loader,
> so should set its context class loader to null before starting, so as to not
> inadvertently retain a reference to the creating thread?s context class loader.
>
> In other areas that suffered from a similar issue we changed to use an
> InnocuousThread, but I cannot fully satisfy myself that this is a safe
> substation here, so I opted for the safest minimal fix. A future refactoring
> exercise should consider using InnocuousThread.
>
> diff -r 92c31ec731eb src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java
> --- a/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java	Wed Aug 10 11:54:12 2016 +0100
> +++ b/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java	Wed Aug 10 16:32:41 2016 +0100
> @@ -809,20 +809,21 @@
>           }
>       }
>   
>       // create the poller thread, if not already active
>       private void createPoller() {
>           if (poller != null) {
>               return;
>           }
>           final TokenPoller poller = new TokenPoller(this);
>           Thread t = new Thread(null, poller, "Poller " + getName(), 0, false);
> +        t.setContextClassLoader(null);
>           t.setDaemon(true);
>           t.setPriority(Thread.MIN_PRIORITY);
>           t.start();
>           this.poller = poller;
>       }
>   
>       // destroy the poller thread, if active
>       private void destroyPoller() {
>           if (poller != null) {
>               poller.disable();
>
> https://bugs.openjdk.java.net/browse/JDK-8156841
>
> -Chris.



From sean.mullan at oracle.com  Wed Aug 10 20:32:31 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 10 Aug 2016 16:32:31 -0400
Subject: [9] RFR 8157579: com/sun/crypto/provider/Mac/MacClone.java failed
	on solaris12(sparcv9 and x86)
In-Reply-To: <6681bdab-e019-ea5b-1b17-723019839357@oracle.com>
References: <e9c6a0c3-9d4d-2a04-822b-471c311b9b5a@oracle.com>
	<42279da0-e45a-9809-c1f2-f3fcaaf58951@oracle.com>
	<62772189-4c08-8ffc-10e5-26dcf57d92ef@oracle.com>
	<6681bdab-e019-ea5b-1b17-723019839357@oracle.com>
Message-ID: <e41bdc43-ce55-28b3-0170-4f232376bd51@oracle.com>

On 08/09/2016 10:00 PM, Valerie Peng wrote:
>
> OracleUcrypto provider already separates them in two classes: The
> cloneable libMD digest impls are encapsulated by a class which
> implements Cloneable and the new un-cloneable Ucrypto digest impls are
> in a class which does not.
> I wasn't sure if we can safely assume that an instance supports clone
> when it implements Cloneable.

True, but I think those would be considered bad Cloneable implementations.

> So I thought better call clone() to be
> sure. Given your feedback, I have replaced the clone() calls with
> instanceof checks.

> Webrev updated: http://cr.openjdk.java.net/~valeriep/8157579/webrev.02

Looks good.

--Sean

>
> Thanks,
> Valerie
>
>
> On 8/9/2016 10:43 AM, Sean Mullan wrote:
>> Or better yet, just change the ucrypto impl to not implement Cloneable
>> regardless what Solaris version you are on. Then you can just check
>> each MessageDigest impl to see if it is an instanceof Cloneable rather
>> than calling clone on each.
>>
>> --Sean
>>
>> On 08/09/2016 09:38 AM, Sean Mullan wrote:
>>> Is there any way to split the Ucrypto MessageDigest implementation into
>>> 2 classes, one that implements Cloneable and the other which doesn't,
>>> and use the appropriate one depending on which OS version you are on?
>>>
>>> This way, instead of calling clone and catching
>>> CloneNotSupportedException, you could just check each MessageDigest
>>> object to see if it implements Cloneable.
>>>
>>> --Sean
>>>
>>>
>>> On 08/04/2016 10:01 PM, Valerie Peng wrote:
>>>>
>>>> Anyone has time to review this fix? The code change is in only one file
>>>> and straightforward if you agree with the approach.
>>>> Starting S11.3 and S12, OracleUcrypto provider switched to new Ucrypto
>>>> APIs for message digest operations and there is no clone support.
>>>> This affects the MAC impls of SunJCE provider which delegates the
>>>> digest
>>>> operation to the most preferred provider.
>>>> To ensure the clone support, I will switch to getting the digest impl
>>>> from SUN provider if the most preferred one does not.
>>>> In the case of SUN provider is not available, it will then goes through
>>>> provider list.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157579
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8157579/webrev.00/
>>>>
>>>> No new test as it's covered by existing regression test.
>>>>
>>>> Thanks,
>>>> Valerie
>>>>
>>>>
>


From artem.smotrakov at oracle.com  Wed Aug 10 22:44:09 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 10 Aug 2016 15:44:09 -0700
Subject: [9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java
	test fails intermittently with "Address already in use" error
Message-ID: <c18375fb-04ca-9f3c-c75d-33c5f1f34532@oracle.com>

Hello,

Please review this update for OCSP stapling tests.

The tests use test/java/security/testlibrary/SimpleOCSPServer.java which 
try to re-use a server port if the server restarted. Looks like 
sometimes it may cause "Address already in use" error.

The patch updates OCSP stapling tests with the following:
- updated SSLSocketWithStapling.java test not to restart OCSP responders
- updated SimpleOCSPServer to be able to reject incoming connections
- updated SimpleOCSPServer to be able to reproduce a delay without 
restarting

Jamil,

Could you please take a look at this update, and confirm if this update 
doesn't break the original test scenarios?

Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/

Artem


From jamil.j.nimeh at oracle.com  Wed Aug 10 23:16:12 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 10 Aug 2016 16:16:12 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <c18375fb-04ca-9f3c-c75d-33c5f1f34532@oracle.com>
References: <c18375fb-04ca-9f3c-c75d-33c5f1f34532@oracle.com>
Message-ID: <6f25548c-70df-8b24-147c-f61ce89a125a@oracle.com>

Hi Artem,

I'm not an official reviewer but the solution for making the servers 
reject connections rather than stop and start looks pretty fair to me 
and seems like a nice way to simulate a downed OCSP responder instead of 
having to bounce it.  A couple comments/questions:

I'm a bit surprised that you get the "Address already in use" error 
though.  Isn't servSocket.setReuseAddress(true) on line 214 supposed to 
set the SO_REUSEADDR at the system call level and prevent EADDRINUSE 
when listening or binding?

When you create the new ServerSocket on line 212, you're now binding it 
to the port now where originally it started as an unbound socket.  By 
doing so, the behavior of setReuseAddress() on line 214 is now 
undefined.  While this test no longer stops/starts the server, other 
tests may wish to do so and their behavior may not be consistent (though 
apparently it wasn't consistent even in the old scheme where the socket 
was unbound, then setReuseAddress() was called...)

--Jamil


On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
> Hello,
>
> Please review this update for OCSP stapling tests.
>
> The tests use test/java/security/testlibrary/SimpleOCSPServer.java 
> which try to re-use a server port if the server restarted. Looks like 
> sometimes it may cause "Address already in use" error.
>
> The patch updates OCSP stapling tests with the following:
> - updated SSLSocketWithStapling.java test not to restart OCSP responders
> - updated SimpleOCSPServer to be able to reject incoming connections
> - updated SimpleOCSPServer to be able to reproduce a delay without 
> restarting
>
> Jamil,
>
> Could you please take a look at this update, and confirm if this 
> update doesn't break the original test scenarios?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>
> Artem



From xuelei.fan at oracle.com  Wed Aug 10 23:36:59 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 11 Aug 2016 07:36:59 +0800
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <a71707c1-5fa7-9084-5f43-ea579857263c@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
	<c1eb3632-6ae0-dca7-2773-281222bbc71e@oracle.com>
	<965F1A6E-D41B-4061-A6D9-F21004F95020@oracle.com>
	<a71707c1-5fa7-9084-5f43-ea579857263c@oracle.com>
Message-ID: <e61fede0-9abc-55c3-005e-80697e3bf70a@oracle.com>

On 8/11/2016 4:15 AM, Sean Mullan wrote:
> On 08/10/2016 12:39 PM, Vincent Ryan wrote:
>> Yes they could be merged but the first loop iterates over all the
>> certs and the second one iterates over all but the final cert.
>> And the special case of a 1-cert chain also needs to be handled. I
>> think it?s a little clearer to leave them separate.
> 
> Agreed, but it's probably better to check these earlier and bail out if
> they are not all X509Certificates, for example, right at the beginning
> of engineSetKeyEntry. There is no need to proceed with decoding keys,
> etc since it is already a violation of the supported API parameters.
> 
Good!

Xuelei

> --Sean
> 
>>
>> An updated webrev is at:
>>   http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/
>>
>> Thanks.
>>
>>> On 10 Aug 2016, at 02:04, Xuelei Fan <Xuelei.Fan at Oracle.Com> wrote:
>>>
>>> The for loop at line 1507 and 1520 may be merged together.
>>>
>>> Xuelei
>>>
>>> On 8/10/2016 8:38 AM, Weijun Wang wrote:
>>>> I thought I've seen this webrev before.
>>>>
>>>> Why not just throw a KeyStoreException in validateChain()?
>>>>
>>>> --Max
>>>>
>>>> On 8/10/2016 2:14, Vincent Ryan wrote:
>>>>> Please review this fix to improve the error handling for attempts to
>>>>> store a Certificate object in PKCS12 keystore.
>>>>> The PKCS12 keystore implementation supports storing only
>>>>> X509Certificate objects but the KeyStore API allows Certificate
>>>>> objects.
>>>>> This fix rejects attempts to store non-X.509 certificates and throws a
>>>>> KeyStoreException.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>>>>>
>>>>>
>>>
>>



From weijun.wang at oracle.com  Thu Aug 11 03:31:06 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 11 Aug 2016 11:31:06 +0800
Subject: RFR 8133910: Some sun/security/tools tests failed.
In-Reply-To: <5C5B7CA0-4133-49F3-8DE9-10D4F46BF8F1@oracle.com>
References: <5C5B7CA0-4133-49F3-8DE9-10D4F46BF8F1@oracle.com>
Message-ID: <4a997619-dffb-f5bb-74ba-469d9f99d92b@oracle.com>

Ping again. Thanks. --Max

On 8/9/2016 15:37, Wang Weijun wrote:
> Please review the fix at
>
>   http://cr.openjdk.java.net/~weijun/8133910/webrev.00/
>
> Basically, "-J-Duser.language=en -J-Duser.country=US" is added to keytool and jarsigner calls wherever output needs to be compared to some English text.
>


From xuelei.fan at oracle.com  Thu Aug 11 03:52:17 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 11 Aug 2016 11:52:17 +0800
Subject: RFR 8133910: Some sun/security/tools tests failed.
In-Reply-To: <4a997619-dffb-f5bb-74ba-469d9f99d92b@oracle.com>
References: <5C5B7CA0-4133-49F3-8DE9-10D4F46BF8F1@oracle.com>
	<4a997619-dffb-f5bb-74ba-469d9f99d92b@oracle.com>
Message-ID: <74dd3ff3-6e6e-31af-c283-e0366b61b6b4@oracle.com>

Looks fine.

Xuelei

On 8/11/2016 11:31 AM, Weijun Wang wrote:
> Ping again. Thanks. --Max
> 
> On 8/9/2016 15:37, Wang Weijun wrote:
>> Please review the fix at
>>
>>   http://cr.openjdk.java.net/~weijun/8133910/webrev.00/
>>
>> Basically, "-J-Duser.language=en -J-Duser.country=US" is added to
>> keytool and jarsigner calls wherever output needs to be compared to
>> some English text.
>>



From sha.jiang at oracle.com  Thu Aug 11 06:47:21 2016
From: sha.jiang at oracle.com (John Jiang)
Date: Thu, 11 Aug 2016 14:47:21 +0800
Subject: [9] RFR 8161340: ProblemList.txt update for
	sun/security/tools/keytool/autotest.sh
Message-ID: <36f81412-dea3-fb0c-b07f-84a8049dec60@oracle.com>

Hi,
Please review this patch for removing 
sun/security/tools/keytool/autotest.sh from ProblemList.txt.
Because the associated issue JDK-8130302 has been resolved.

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

Best regards,
John Jiang



From weijun.wang at oracle.com  Thu Aug 11 07:23:00 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 11 Aug 2016 15:23:00 +0800
Subject: [9] RFR 8161340: ProblemList.txt update for
	sun/security/tools/keytool/autotest.sh
In-Reply-To: <36f81412-dea3-fb0c-b07f-84a8049dec60@oracle.com>
References: <36f81412-dea3-fb0c-b07f-84a8049dec60@oracle.com>
Message-ID: <eb92ff3f-0b5b-71de-0469-ca624fd2e4e7@oracle.com>

Change looks fine. Thanks for taking care of it. I should have removed 
it in my fix.

--Max

On 8/11/2016 14:47, John Jiang wrote:
> Hi,
> Please review this patch for removing
> sun/security/tools/keytool/autotest.sh from ProblemList.txt.
> Because the associated issue JDK-8130302 has been resolved.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8161340
> Webrev: http://cr.openjdk.java.net/~jjiang/8161340/webrev.00/
>
> Best regards,
> John Jiang
>


From jamil.j.nimeh at oracle.com  Thu Aug 11 07:51:09 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 11 Aug 2016 00:51:09 -0700
Subject: RFR 8162808: References to the standard JSSE cipher suite names
Message-ID: <c65b0e0b-7b96-1961-2f32-6853a3bc6da2@oracle.com>

Hello all,

This javadoc-only change adds references to the JSSE cipher suite list 
in the Standard Names documentation for those methods which return or 
can set lists of cipher suites by their String names.

JBS: https://bugs.openjdk.java.net/browse/JDK-8162808
Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8162808/webrev.01

Thanks,
--Jamil


From xuelei.fan at oracle.com  Thu Aug 11 08:47:43 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 11 Aug 2016 16:47:43 +0800
Subject: RFR 8162808: References to the standard JSSE cipher suite names
In-Reply-To: <c65b0e0b-7b96-1961-2f32-6853a3bc6da2@oracle.com>
References: <c65b0e0b-7b96-1961-2f32-6853a3bc6da2@oracle.com>
Message-ID: <7ccd2a11-4994-5ec7-a599-4d779c383024@oracle.com>

SSLParameters.java
May be better to use the same words in the constructors
SSLParameters(String[]) and SSLParameters(String[], String[]).

Otherwise, looks fine to me.

Thanks,
Xuelei

On 8/11/2016 3:51 PM, Jamil Nimeh wrote:
> Hello all,
> 
> This javadoc-only change adds references to the JSSE cipher suite list
> in the Standard Names documentation for those methods which return or
> can set lists of cipher suites by their String names.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8162808
> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8162808/webrev.01
> 
> Thanks,
> --Jamil



From vincent.x.ryan at oracle.com  Thu Aug 11 11:55:20 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 11 Aug 2016 12:55:20 +0100
Subject: [9] RFR 6877937: The SunJCE PBKDF2KeyImpl is requiring the MAC
	instance also be from SunJCE.
Message-ID: <75EC098D-BE36-410D-AE23-D7BC75021283@oracle.com>

Please review this change to unpin the Mac implementation from the SunJCE provider.
Since the Mac is a private field there are no issues regarding Clonable implementations for Mac or its MessageDigest.
Thanks.

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

diff --git a/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java b/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
--- a/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
+++ b/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
@@ -107,7 +107,7 @@
             throw new InvalidKeySpecException("Key length is negative");
         }
         try {
-            this.prf = Mac.getInstance(prfAlgo, SunJCE.getInstance());
+            this.prf = Mac.getInstance(prfAlgo);
         } catch (NoSuchAlgorithmException nsae) {
             // not gonna happen; re-throw just in case
             InvalidKeySpecException ike = new InvalidKeySpecException();
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160811/3467c681/attachment.htm>

From xuelei.fan at oracle.com  Thu Aug 11 12:54:04 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 11 Aug 2016 20:54:04 +0800
Subject: [9] RFR 6877937: The SunJCE PBKDF2KeyImpl is requiring the MAC
	instance also be from SunJCE.
In-Reply-To: <75EC098D-BE36-410D-AE23-D7BC75021283@oracle.com>
References: <75EC098D-BE36-410D-AE23-D7BC75021283@oracle.com>
Message-ID: <0a338cc5-3238-e348-383b-abc5907c2ec1@oracle.com>

Looks fine to me.

Xuelei

On 8/11/2016 7:55 PM, Vincent Ryan wrote:
> Please review this change to unpin the Mac implementation from the
> SunJCE provider.
> Since the Mac is a private field there are no issues
> regarding Clonable implementations for Mac or its MessageDigest.
> Thanks.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-6977937
> 
> *diff --git
> a/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
> b/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java*
> *---
> a/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java*
> *+++
> b/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java*
> @@ -107,7 +107,7 @@
>              throw new InvalidKeySpecException("Key length is negative");
>          }
>          try {
> -            this.prf = Mac.getInstance(prfAlgo, SunJCE.getInstance());
> +            this.prf = Mac.getInstance(prfAlgo);
>          } catch (NoSuchAlgorithmException nsae) {
>              // not gonna happen; re-throw just in case
>              InvalidKeySpecException ike = new InvalidKeySpecException();



From jamil.j.nimeh at oracle.com  Thu Aug 11 14:05:56 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 11 Aug 2016 07:05:56 -0700
Subject: RFR 8162808: References to the standard JSSE cipher suite names
In-Reply-To: <7ccd2a11-4994-5ec7-a599-4d779c383024@oracle.com>
References: <c65b0e0b-7b96-1961-2f32-6853a3bc6da2@oracle.com>
	<7ccd2a11-4994-5ec7-a599-4d779c383024@oracle.com>
Message-ID: <8124b559-2233-e6e8-8d66-93fd213ef47e@oracle.com>

No problem, I'll get that fixed and remake the Javadocs to sanity check.

--Jamil

On 8/11/2016 1:47 AM, Xuelei Fan wrote:
> SSLParameters.java
> May be better to use the same words in the constructors
> SSLParameters(String[]) and SSLParameters(String[], String[]).
>
> Otherwise, looks fine to me.
>
> Thanks,
> Xuelei
>
> On 8/11/2016 3:51 PM, Jamil Nimeh wrote:
>> Hello all,
>>
>> This javadoc-only change adds references to the JSSE cipher suite list
>> in the Standard Names documentation for those methods which return or
>> can set lists of cipher suites by their String names.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8162808
>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8162808/webrev.01
>>
>> Thanks,
>> --Jamil



From artem.smotrakov at oracle.com  Thu Aug 11 18:46:39 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 11 Aug 2016 11:46:39 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <6f25548c-70df-8b24-147c-f61ce89a125a@oracle.com>
References: <c18375fb-04ca-9f3c-c75d-33c5f1f34532@oracle.com>
	<6f25548c-70df-8b24-147c-f61ce89a125a@oracle.com>
Message-ID: <eea0ab8a-398a-d481-85f1-5823634e794a@oracle.com>

Hi Jamil,

Thank you for review. Please see inline.


On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
> Hi Artem,
>
> I'm not an official reviewer but the solution for making the servers 
> reject connections rather than stop and start looks pretty fair to me 
> and seems like a nice way to simulate a downed OCSP responder instead 
> of having to bounce it.  A couple comments/questions:
>
> I'm a bit surprised that you get the "Address already in use" error 
> though. 
Well, to be honest, I was not able to reproduce this failure locally. I 
was running the test in a loop for a couple of days, and it didn't fail. 
But the test has been observed to fail in other test runs (jprt, CI, etc).

I am not an expert in networking, and I would appreciate if someone more 
knowledgeable gives an advise how these intermittent failures can be 
avoided.

> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set the 
> SO_REUSEADDR at the system call level and prevent EADDRINUSE when 
> listening or binding?
If I am not missing something, the test has been observed to fails while 
re-binding. I am wondering if it's possible that the port becomes busy 
after the server socket was closed, but before bind() is called again. 
The probability of this situation seems to be very low which has been 
actually seen - the test fails very rare.

If this is the case, it seems like servSocket.setReuseAddress(true) 
doesn't help because the port is taken by another process (I am not sure 
that SO_REUSEADDR prevents from this). Again, this is only my guess, and 
I may be wrong.
>
> When you create the new ServerSocket on line 212, you're now binding 
> it to the port now where originally it started as an unbound socket.  
> By doing so, the behavior of setReuseAddress() on line 214 is now 
> undefined.
This setReuseAddress() call looks unnecessary now. I'll update the test.
> While this test no longer stops/starts the server, other tests may 
> wish to do so and their behavior may not be consistent (though 
> apparently it wasn't consistent even in the old scheme where the 
> socket was unbound, then setReuseAddress() was called...)
Correct. I checked other code which depend on SimpleOCSPServer

javax/net/ssl/Stapling/HttpsUrlConnClient.java
javax/net/ssl/Stapling/SSLEngineWithStapling.java
javax/net/ssl/Stapling/SSLSocketWithStapling.java
javax/net/ssl/Stapling/StapleEnableProps.java
sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java
sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java
artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate 
javax/net/ssl/Stapling/HttpsUrlConnClient.java 
javax/net/ssl/Stapling/SSLEngineWithStapling.java 
javax/net/ssl/Stapling/SSLSocketWithStapling.java 
javax/net/ssl/Stapling/StapleEnableProps.java 
sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 


These tests call stop() only once when actual testcases are done. 
Actually, some of them don't even call stop(), but it seems to work 
fine. As an enhancement, I would add stop() calls to finally blocks, but 
it seems to work fine without it anyway.

Here is an updated webrev:

http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/

Artem


>
> --Jamil
>
>
> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>> Hello,
>>
>> Please review this update for OCSP stapling tests.
>>
>> The tests use test/java/security/testlibrary/SimpleOCSPServer.java 
>> which try to re-use a server port if the server restarted. Looks like 
>> sometimes it may cause "Address already in use" error.
>>
>> The patch updates OCSP stapling tests with the following:
>> - updated SSLSocketWithStapling.java test not to restart OCSP responders
>> - updated SimpleOCSPServer to be able to reject incoming connections
>> - updated SimpleOCSPServer to be able to reproduce a delay without 
>> restarting
>>
>> Jamil,
>>
>> Could you please take a look at this update, and confirm if this 
>> update doesn't break the original test scenarios?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>>
>> Artem
>



From ecki at zusammenkunft.net  Thu Aug 11 22:00:43 2016
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 12 Aug 2016 00:00:43 +0200
Subject: RFC7525 mapped to JSSE
In-Reply-To: <0ff9135c-dd24-cf99-0913-47939d07fd03@oracle.com>
References: <20160802001302.00005374.ecki@zusammenkunft.net>
	<0ff9135c-dd24-cf99-0913-47939d07fd03@oracle.com>
Message-ID: <20160812000043.00006c16.ecki@zusammenkunft.net>

Hello,

thank you Xuelei and Jamil. I updated the sheet and added an actual
column for Java 9. There are still some todos left (mostly for digging
up the detauls), but it starts to look complete now.

There are only two real non-compliances (for Java 9), that is the
support for HSTS in client code (not related to JSSE) and the fallback
signalling cipher (with limited usefullness).

For Java 8 the EC keySize < 224, can it be added?

For OCSP, the status_request(_v2), does it also support the multi
certificate variant?

https://docs.google.com/spreadsheets/d/135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE

Gruss
Bernd


 Am Mon, 8 Aug 2016 08:57:29 +0800
schrieb Xuelei Fan <xuelei.fan at oracle.com>:

> Hi Bernd,
> 
> Thanks for the summary of the compliance.  The following comments are
> mainly about the items marked with "TODO" or "???".
> 
> JDK 9 will support DTLS 1.0/1.2 and OCSP stapling (both RFC 6066 and
> RFC 6961).
> 
> The server preference of cipher suites can be configurable.
> 
> JDK uses uncompressed EC point format only.
> 
> JDK does not use EC curves < 224 bits for EC key exchange, default
> 256+ bits.
> 
> For TLS 1.2, SHA2 is requested in the signature algorithm extension.
> 
> JDK does not implement the truncted HMAC extension.
> 
> JDK supports hostname verification APIs for HTTPS, and support
> hostname verification during handshaking for HTTPS and LDAP.
> 
> JDK tests the DH public keys.
> 
> Thanks & Regards,
> Xuelei
> 
> On 8/2/2016 6:13 AM, Bernd Eckenfels wrote:
> > Hello,
> > 
> > because I was asked by a customer I started to map the RFC7525
> > 
> > https://tools.ietf.org/html/rfc7525
> > 
> > recommendations for TLS to JSSE implementation.
> > 
> > 
> > It is not complete yet but I think I at least have extraced all
> > "normative" requirements from the RFC into this table:
> > 
> > https://docs.google.com/spreadsheets/d/135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE
> > 
> > would like to get your feedback.
> > 
> > Gruss
> > Bernd
> > 
> 



From jamil.j.nimeh at oracle.com  Thu Aug 11 23:10:11 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 11 Aug 2016 16:10:11 -0700
Subject: RFC7525 mapped to JSSE
Message-ID: <dax6l8t7x3jnna1oxl6mym9a.1470957011194@email.android.com>

Hi Bernd,
For the status_request_v2 extension, both ocsp and ocsp_multi forms are supported, with preference on the latter type. ?The only feature we currently don't support right now is Responder ID selection, ?and that will hopefully come in a 9 update.
--Jamil
-------- Original message --------From: Bernd Eckenfels <ecki at zusammenkunft.net> Date: 8/11/16  3:00 PM  (GMT-08:00) To: security-dev at openjdk.java.net Subject: Re: RFC7525 mapped to JSSE 
Hello,

thank you Xuelei and Jamil. I updated the sheet and added an actual
column for Java 9. There are still some todos left (mostly for digging
up the detauls), but it starts to look complete now.

There are only two real non-compliances (for Java 9), that is the
support for HSTS in client code (not related to JSSE) and the fallback
signalling cipher (with limited usefullness).

For Java 8 the EC keySize < 224, can it be added?

For OCSP, the status_request(_v2), does it also support the multi
certificate variant?

https://docs.google.com/spreadsheets/d/135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE

Gruss
Bernd


 Am Mon, 8 Aug 2016 08:57:29 +0800
schrieb Xuelei Fan <xuelei.fan at oracle.com>:

> Hi Bernd,
> 
> Thanks for the summary of the compliance.? The following comments are
> mainly about the items marked with "TODO" or "???".
> 
> JDK 9 will support DTLS 1.0/1.2 and OCSP stapling (both RFC 6066 and
> RFC 6961).
> 
> The server preference of cipher suites can be configurable.
> 
> JDK uses uncompressed EC point format only.
> 
> JDK does not use EC curves < 224 bits for EC key exchange, default
> 256+ bits.
> 
> For TLS 1.2, SHA2 is requested in the signature algorithm extension.
> 
> JDK does not implement the truncted HMAC extension.
> 
> JDK supports hostname verification APIs for HTTPS, and support
> hostname verification during handshaking for HTTPS and LDAP.
> 
> JDK tests the DH public keys.
> 
> Thanks & Regards,
> Xuelei
> 
> On 8/2/2016 6:13 AM, Bernd Eckenfels wrote:
> > Hello,
> > 
> > because I was asked by a customer I started to map the RFC7525
> > 
> > https://tools.ietf.org/html/rfc7525
> > 
> > recommendations for TLS to JSSE implementation.
> > 
> > 
> > It is not complete yet but I think I at least have extraced all
> > "normative" requirements from the RFC into this table:
> > 
> > https://docs.google.com/spreadsheets/d/135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE
> > 
> > would like to get your feedback.
> > 
> > Gruss
> > Bernd
> > 
> 

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

From xuelei.fan at oracle.com  Thu Aug 11 23:48:23 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 12 Aug 2016 07:48:23 +0800
Subject: RFC7525 mapped to JSSE
In-Reply-To: <dax6l8t7x3jnna1oxl6mym9a.1470957011194@email.android.com>
References: <dax6l8t7x3jnna1oxl6mym9a.1470957011194@email.android.com>
Message-ID: <a850b67e-0f8a-a5eb-c948-470ab0dacf84@oracle.com>

Thank you, Bernd.

> For Java 8 the EC keySize < 224, can it be added?
It's a plan of mine.

> the fallback signalling cipher (with limited usefullness).
It's a plan of mine, too.  Note that JDK does not support fallback by
default.

DH items:  JDK does not reuse DH exponents and check the received public
keys.

Thanks,
Xuelei

On 8/12/2016 7:10 AM, Jamil Nimeh wrote:
> Hi Bernd,
> 
> For the status_request_v2 extension, both ocsp and ocsp_multi forms are
> supported, with preference on the latter type.  The only feature we
> currently don't support right now is Responder ID selection,  and that
> will hopefully come in a 9 update.
> 
> --Jamil
> 
> -------- Original message --------
> From: Bernd Eckenfels <ecki at zusammenkunft.net>
> Date: 8/11/16 3:00 PM (GMT-08:00)
> To: security-dev at openjdk.java.net
> Subject: Re: RFC7525 mapped to JSSE
> 
> Hello,
> 
> thank you Xuelei and Jamil. I updated the sheet and added an actual
> column for Java 9. There are still some todos left (mostly for digging
> up the detauls), but it starts to look complete now.
> 
> There are only two real non-compliances (for Java 9), that is the
> support for HSTS in client code (not related to JSSE) and the fallback
> signalling cipher (with limited usefullness).
> 
> For Java 8 the EC keySize < 224, can it be added?
> 
> For OCSP, the status_request(_v2), does it also support the multi
> certificate variant?
> 
> https://docs.google.com/spreadsheets/d/135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE
> 
> Gruss
> Bernd
> 
> 
> Am Mon, 8 Aug 2016 08:57:29 +0800
> schrieb Xuelei Fan <xuelei.fan at oracle.com>:
> 
>> Hi Bernd,
>>
>> Thanks for the summary of the compliance.  The following comments are
>> mainly about the items marked with "TODO" or "???".
>>
>> JDK 9 will support DTLS 1.0/1.2 and OCSP stapling (both RFC 6066 and
>> RFC 6961).
>>
>> The server preference of cipher suites can be configurable.
>>
>> JDK uses uncompressed EC point format only.
>>
>> JDK does not use EC curves < 224 bits for EC key exchange, default
>> 256+ bits.
>>
>> For TLS 1.2, SHA2 is requested in the signature algorithm extension.
>>
>> JDK does not implement the truncted HMAC extension.
>>
>> JDK supports hostname verification APIs for HTTPS, and support
>> hostname verification during handshaking for HTTPS and LDAP.
>>
>> JDK tests the DH public keys.
>>
>> Thanks & Regards,
>> Xuelei
>>
>> On 8/2/2016 6:13 AM, Bernd Eckenfels wrote:
>> > Hello,
>> >
>> > because I was asked by a customer I started to map the RFC7525
>> >
>> > https://tools.ietf.org/html/rfc7525
>> >
>> > recommendations for TLS to JSSE implementation.
>> >
>> >
>> > It is not complete yet but I think I at least have extraced all
>> > "normative" requirements from the RFC into this table:
>> >
>> >
> https://docs.google.com/spreadsheets/d/135Eqf3RCpYLcmVHOIPb_Q7pzFde9yqJI_oD2jvpnKPE
>> >
>> > would like to get your feedback.
>> >
>> > Gruss
>> > Bernd
>> >
>>
> 



From vincent.x.ryan at oracle.com  Fri Aug 12 15:07:51 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 12 Aug 2016 16:07:51 +0100
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <a71707c1-5fa7-9084-5f43-ea579857263c@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
	<c1eb3632-6ae0-dca7-2773-281222bbc71e@oracle.com>
	<965F1A6E-D41B-4061-A6D9-F21004F95020@oracle.com>
	<a71707c1-5fa7-9084-5f43-ea579857263c@oracle.com>
Message-ID: <BC18C8A7-F1A3-4088-8B9A-A37417298548@oracle.com>

I?ve moved the X.509 check to earlier in the code and reverted the changes to the validateChain method.
Updated webrev is at:
   http://cr.openjdk.java.net/~vinnie/8163503/webrev.02/



> On 10 Aug 2016, at 21:15, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 08/10/2016 12:39 PM, Vincent Ryan wrote:
>> Yes they could be merged but the first loop iterates over all the certs and the second one iterates over all but the final cert.
>> And the special case of a 1-cert chain also needs to be handled. I think it?s a little clearer to leave them separate.
> 
> Agreed, but it's probably better to check these earlier and bail out if they are not all X509Certificates, for example, right at the beginning of engineSetKeyEntry. There is no need to proceed with decoding keys, etc since it is already a violation of the supported API parameters.
> 
> --Sean
> 
>> 
>> An updated webrev is at:
>>  http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/
>> 
>> Thanks.
>> 
>>> On 10 Aug 2016, at 02:04, Xuelei Fan <Xuelei.Fan at Oracle.Com> wrote:
>>> 
>>> The for loop at line 1507 and 1520 may be merged together.
>>> 
>>> Xuelei
>>> 
>>> On 8/10/2016 8:38 AM, Weijun Wang wrote:
>>>> I thought I've seen this webrev before.
>>>> 
>>>> Why not just throw a KeyStoreException in validateChain()?
>>>> 
>>>> --Max
>>>> 
>>>> On 8/10/2016 2:14, Vincent Ryan wrote:
>>>>> Please review this fix to improve the error handling for attempts to
>>>>> store a Certificate object in PKCS12 keystore.
>>>>> The PKCS12 keystore implementation supports storing only
>>>>> X509Certificate objects but the KeyStore API allows Certificate objects.
>>>>> This fix rejects attempts to store non-X.509 certificates and throws a
>>>>> KeyStoreException.
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>>>>> 
>>>>> 
>>> 
>> 



From jamil.j.nimeh at oracle.com  Fri Aug 12 16:13:22 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 12 Aug 2016 09:13:22 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <eea0ab8a-398a-d481-85f1-5823634e794a@oracle.com>
References: <c18375fb-04ca-9f3c-c75d-33c5f1f34532@oracle.com>
	<6f25548c-70df-8b24-147c-f61ce89a125a@oracle.com>
	<eea0ab8a-398a-d481-85f1-5823634e794a@oracle.com>
Message-ID: <db93cb12-aea1-dfa7-8a2f-d1435bfe608a@oracle.com>

Hi Artem, more comments in-line


On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
> Hi Jamil,
>
> Thank you for review. Please see inline.
>
>
> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
>> Hi Artem,
>>
>> I'm not an official reviewer but the solution for making the servers 
>> reject connections rather than stop and start looks pretty fair to me 
>> and seems like a nice way to simulate a downed OCSP responder instead 
>> of having to bounce it.  A couple comments/questions:
>>
>> I'm a bit surprised that you get the "Address already in use" error 
>> though. 
> Well, to be honest, I was not able to reproduce this failure locally. 
> I was running the test in a loop for a couple of days, and it didn't 
> fail. But the test has been observed to fail in other test runs (jprt, 
> CI, etc).
>
> I am not an expert in networking, and I would appreciate if someone 
> more knowledgeable gives an advise how these intermittent failures can 
> be avoided.
>
>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set 
>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE when 
>> listening or binding?
> If I am not missing something, the test has been observed to fails 
> while re-binding. I am wondering if it's possible that the port 
> becomes busy after the server socket was closed, but before bind() is 
> called again. The probability of this situation seems to be very low 
> which has been actually seen - the test fails very rare.
>
> If this is the case, it seems like servSocket.setReuseAddress(true) 
> doesn't help because the port is taken by another process (I am not 
> sure that SO_REUSEADDR prevents from this). Again, this is only my 
> guess, and I may be wrong.
You know, I hadn't thought of that.  I've never been able to reproduce 
that problem either, but I'm running on a local virtual box VM on a 
laptop, and usually the tests are running sequentially. I could 
definitely see the case where other processes are soaking up the OCSP 
responder's port.  With those tests, I kind of need the port to remain 
the same since I'm putting that server and port in the AIA extensions of 
the certs for which it answers.  Given this particular case, it seems 
like your solution of keeping the server bound but just chopping 
connections off is the best way to go.
>>
>> When you create the new ServerSocket on line 212, you're now binding 
>> it to the port now where originally it started as an unbound socket.  
>> By doing so, the behavior of setReuseAddress() on line 214 is now 
>> undefined.
> This setReuseAddress() call looks unnecessary now. I'll update the test.
>> While this test no longer stops/starts the server, other tests may 
>> wish to do so and their behavior may not be consistent (though 
>> apparently it wasn't consistent even in the old scheme where the 
>> socket was unbound, then setReuseAddress() was called...)
> Correct. I checked other code which depend on SimpleOCSPServer
>
> javax/net/ssl/Stapling/HttpsUrlConnClient.java
> javax/net/ssl/Stapling/SSLEngineWithStapling.java
> javax/net/ssl/Stapling/SSLSocketWithStapling.java
> javax/net/ssl/Stapling/StapleEnableProps.java
> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>
> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>
> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate 
> javax/net/ssl/Stapling/HttpsUrlConnClient.java 
> javax/net/ssl/Stapling/SSLEngineWithStapling.java 
> javax/net/ssl/Stapling/SSLSocketWithStapling.java 
> javax/net/ssl/Stapling/StapleEnableProps.java 
> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>
>
> These tests call stop() only once when actual testcases are done. 
> Actually, some of them don't even call stop(), but it seems to work 
> fine. As an enhancement, I would add stop() calls to finally blocks, 
> but it seems to work fine without it anyway.
I liked your solution with the stop() calls in finally blocks and I 
agree that they should have them.  I think we get away with it because 
in most if not all of those cases they are running as othervm tests 
(because we have properties that we set specific to the tests).  So when 
the JVM exits resources like sockets are closed by the OS.  Still, it's 
better to have the try/finally guards and explicitly and gracefully 
shutdown the OCSP responders.
>
> Here is an updated webrev:
>
> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
I realize that in many of these test cases we're going to move away from 
a start/stop approach to your accept/reject one, but in general sockets 
designed to be listening should start unbound, set the SO_REUSEADDR 
sockopt, then bind and listen.  Was there a specific reason to change 
that code, or was it just to streamline it?  Aside from fewer lines of 
code, I'm not sure what it buys us.
>
> Artem
>
>
>>
>> --Jamil
>>
>>
>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>>> Hello,
>>>
>>> Please review this update for OCSP stapling tests.
>>>
>>> The tests use test/java/security/testlibrary/SimpleOCSPServer.java 
>>> which try to re-use a server port if the server restarted. Looks 
>>> like sometimes it may cause "Address already in use" error.
>>>
>>> The patch updates OCSP stapling tests with the following:
>>> - updated SSLSocketWithStapling.java test not to restart OCSP 
>>> responders
>>> - updated SimpleOCSPServer to be able to reject incoming connections
>>> - updated SimpleOCSPServer to be able to reproduce a delay without 
>>> restarting
>>>
>>> Jamil,
>>>
>>> Could you please take a look at this update, and confirm if this 
>>> update doesn't break the original test scenarios?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>>>
>>> Artem
>>
>



From artem.smotrakov at oracle.com  Fri Aug 12 18:30:06 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Fri, 12 Aug 2016 11:30:06 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <db93cb12-aea1-dfa7-8a2f-d1435bfe608a@oracle.com>
References: <c18375fb-04ca-9f3c-c75d-33c5f1f34532@oracle.com>
	<6f25548c-70df-8b24-147c-f61ce89a125a@oracle.com>
	<eea0ab8a-398a-d481-85f1-5823634e794a@oracle.com>
	<db93cb12-aea1-dfa7-8a2f-d1435bfe608a@oracle.com>
Message-ID: <fbe414b0-4d06-4c41-c243-cbd0098c975f@oracle.com>

Hi Jamil,

There was no any specific reason to remove ServerSocket.bind() call. 
ServerSocket(0) constructor creates a server socket, automatically bound 
to a random free port. If I am not missing something, it doesn't look 
necessary to set the SO_REUSEADDR socket options if the server is not 
going to restart. The code is just shorter if we use ServerSocket(0) 
constructor to open a server socket, but I can revert it to use bind() 
with 0 port number if you think it's better.

Artem


On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
> Hi Artem, more comments in-line
>
>
> On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
>> Hi Jamil,
>>
>> Thank you for review. Please see inline.
>>
>>
>> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
>>> Hi Artem,
>>>
>>> I'm not an official reviewer but the solution for making the servers 
>>> reject connections rather than stop and start looks pretty fair to 
>>> me and seems like a nice way to simulate a downed OCSP responder 
>>> instead of having to bounce it.  A couple comments/questions:
>>>
>>> I'm a bit surprised that you get the "Address already in use" error 
>>> though. 
>> Well, to be honest, I was not able to reproduce this failure locally. 
>> I was running the test in a loop for a couple of days, and it didn't 
>> fail. But the test has been observed to fail in other test runs 
>> (jprt, CI, etc).
>>
>> I am not an expert in networking, and I would appreciate if someone 
>> more knowledgeable gives an advise how these intermittent failures 
>> can be avoided.
>>
>>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set 
>>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE 
>>> when listening or binding?
>> If I am not missing something, the test has been observed to fails 
>> while re-binding. I am wondering if it's possible that the port 
>> becomes busy after the server socket was closed, but before bind() is 
>> called again. The probability of this situation seems to be very low 
>> which has been actually seen - the test fails very rare.
>>
>> If this is the case, it seems like servSocket.setReuseAddress(true) 
>> doesn't help because the port is taken by another process (I am not 
>> sure that SO_REUSEADDR prevents from this). Again, this is only my 
>> guess, and I may be wrong.
> You know, I hadn't thought of that.  I've never been able to reproduce 
> that problem either, but I'm running on a local virtual box VM on a 
> laptop, and usually the tests are running sequentially. I could 
> definitely see the case where other processes are soaking up the OCSP 
> responder's port.  With those tests, I kind of need the port to remain 
> the same since I'm putting that server and port in the AIA extensions 
> of the certs for which it answers.  Given this particular case, it 
> seems like your solution of keeping the server bound but just chopping 
> connections off is the best way to go.
>>>
>>> When you create the new ServerSocket on line 212, you're now binding 
>>> it to the port now where originally it started as an unbound 
>>> socket.  By doing so, the behavior of setReuseAddress() on line 214 
>>> is now undefined.
>> This setReuseAddress() call looks unnecessary now. I'll update the test.
>>> While this test no longer stops/starts the server, other tests may 
>>> wish to do so and their behavior may not be consistent (though 
>>> apparently it wasn't consistent even in the old scheme where the 
>>> socket was unbound, then setReuseAddress() was called...)
>> Correct. I checked other code which depend on SimpleOCSPServer
>>
>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>> javax/net/ssl/Stapling/StapleEnableProps.java
>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>>
>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>>
>> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate 
>> javax/net/ssl/Stapling/HttpsUrlConnClient.java 
>> javax/net/ssl/Stapling/SSLEngineWithStapling.java 
>> javax/net/ssl/Stapling/SSLSocketWithStapling.java 
>> javax/net/ssl/Stapling/StapleEnableProps.java 
>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>>
>>
>> These tests call stop() only once when actual testcases are done. 
>> Actually, some of them don't even call stop(), but it seems to work 
>> fine. As an enhancement, I would add stop() calls to finally blocks, 
>> but it seems to work fine without it anyway.
> I liked your solution with the stop() calls in finally blocks and I 
> agree that they should have them.  I think we get away with it because 
> in most if not all of those cases they are running as othervm tests 
> (because we have properties that we set specific to the tests).  So 
> when the JVM exits resources like sockets are closed by the OS.  
> Still, it's better to have the try/finally guards and explicitly and 
> gracefully shutdown the OCSP responders.
>>
>> Here is an updated webrev:
>>
>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
> I realize that in many of these test cases we're going to move away 
> from a start/stop approach to your accept/reject one, but in general 
> sockets designed to be listening should start unbound, set the 
> SO_REUSEADDR sockopt, then bind and listen.  Was there a specific 
> reason to change that code, or was it just to streamline it?  Aside 
> from fewer lines of code, I'm not sure what it buys us.
>>
>> Artem
>>
>>
>>>
>>> --Jamil
>>>
>>>
>>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>>>> Hello,
>>>>
>>>> Please review this update for OCSP stapling tests.
>>>>
>>>> The tests use test/java/security/testlibrary/SimpleOCSPServer.java 
>>>> which try to re-use a server port if the server restarted. Looks 
>>>> like sometimes it may cause "Address already in use" error.
>>>>
>>>> The patch updates OCSP stapling tests with the following:
>>>> - updated SSLSocketWithStapling.java test not to restart OCSP 
>>>> responders
>>>> - updated SimpleOCSPServer to be able to reject incoming connections
>>>> - updated SimpleOCSPServer to be able to reproduce a delay without 
>>>> restarting
>>>>
>>>> Jamil,
>>>>
>>>> Could you please take a look at this update, and confirm if this 
>>>> update doesn't break the original test scenarios?
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>>>>
>>>> Artem
>>>
>>
>



From sean.mullan at oracle.com  Fri Aug 12 18:53:17 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 12 Aug 2016 14:53:17 -0400
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <BC18C8A7-F1A3-4088-8B9A-A37417298548@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
	<c1eb3632-6ae0-dca7-2773-281222bbc71e@oracle.com>
	<965F1A6E-D41B-4061-A6D9-F21004F95020@oracle.com>
	<a71707c1-5fa7-9084-5f43-ea579857263c@oracle.com>
	<BC18C8A7-F1A3-4088-8B9A-A37417298548@oracle.com>
Message-ID: <70ee579b-a506-8c37-4941-093c142c9468@oracle.com>

Looks fine, although I would probably avoid calling checkX509Certs on 
line 970 and just checking the cert right there to avoid creating the 
array which is not needed.

--Sean

On 08/12/2016 11:07 AM, Vincent Ryan wrote:
> I?ve moved the X.509 check to earlier in the code and reverted the changes to the validateChain method.
> Updated webrev is at:
>    http://cr.openjdk.java.net/~vinnie/8163503/webrev.02/
>
>
>
>> On 10 Aug 2016, at 21:15, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 08/10/2016 12:39 PM, Vincent Ryan wrote:
>>> Yes they could be merged but the first loop iterates over all the certs and the second one iterates over all but the final cert.
>>> And the special case of a 1-cert chain also needs to be handled. I think it?s a little clearer to leave them separate.
>>
>> Agreed, but it's probably better to check these earlier and bail out if they are not all X509Certificates, for example, right at the beginning of engineSetKeyEntry. There is no need to proceed with decoding keys, etc since it is already a violation of the supported API parameters.
>>
>> --Sean
>>
>>>
>>> An updated webrev is at:
>>>  http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/
>>>
>>> Thanks.
>>>
>>>> On 10 Aug 2016, at 02:04, Xuelei Fan <Xuelei.Fan at Oracle.Com> wrote:
>>>>
>>>> The for loop at line 1507 and 1520 may be merged together.
>>>>
>>>> Xuelei
>>>>
>>>> On 8/10/2016 8:38 AM, Weijun Wang wrote:
>>>>> I thought I've seen this webrev before.
>>>>>
>>>>> Why not just throw a KeyStoreException in validateChain()?
>>>>>
>>>>> --Max
>>>>>
>>>>> On 8/10/2016 2:14, Vincent Ryan wrote:
>>>>>> Please review this fix to improve the error handling for attempts to
>>>>>> store a Certificate object in PKCS12 keystore.
>>>>>> The PKCS12 keystore implementation supports storing only
>>>>>> X509Certificate objects but the KeyStore API allows Certificate objects.
>>>>>> This fix rejects attempts to store non-X.509 certificates and throws a
>>>>>> KeyStoreException.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>>>>>>
>>>>>>
>>>>
>>>
>


From jamil.j.nimeh at oracle.com  Fri Aug 12 19:02:18 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 12 Aug 2016 12:02:18 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <fbe414b0-4d06-4c41-c243-cbd0098c975f@oracle.com>
References: <c18375fb-04ca-9f3c-c75d-33c5f1f34532@oracle.com>
	<6f25548c-70df-8b24-147c-f61ce89a125a@oracle.com>
	<eea0ab8a-398a-d481-85f1-5823634e794a@oracle.com>
	<db93cb12-aea1-dfa7-8a2f-d1435bfe608a@oracle.com>
	<fbe414b0-4d06-4c41-c243-cbd0098c975f@oracle.com>
Message-ID: <2c1072d4-85d2-7a8b-5729-d77ded672fa0@oracle.com>

For the tests as we use them today we don't intend the server to 
restart.  The intent of SimpleOCSPServer was to be of use for a variety 
of testing purposes.  I don't know that we can say for all intended uses 
that we'll *never* need to restart it.  That's why I'd like to keep the 
unbound socket/set sockopt/bind/listen behavior.  I don't think 
ServerSocket(0) achieves that.

--Jamil

On 8/12/2016 11:30 AM, Artem Smotrakov wrote:
> Hi Jamil,
>
> There was no any specific reason to remove ServerSocket.bind() call. 
> ServerSocket(0) constructor creates a server socket, automatically 
> bound to a random free port. If I am not missing something, it doesn't 
> look necessary to set the SO_REUSEADDR socket options if the server is 
> not going to restart. The code is just shorter if we use 
> ServerSocket(0) constructor to open a server socket, but I can revert 
> it to use bind() with 0 port number if you think it's better.
>
> Artem
>
>
> On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
>> Hi Artem, more comments in-line
>>
>>
>> On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
>>> Hi Jamil,
>>>
>>> Thank you for review. Please see inline.
>>>
>>>
>>> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
>>>> Hi Artem,
>>>>
>>>> I'm not an official reviewer but the solution for making the 
>>>> servers reject connections rather than stop and start looks pretty 
>>>> fair to me and seems like a nice way to simulate a downed OCSP 
>>>> responder instead of having to bounce it.  A couple 
>>>> comments/questions:
>>>>
>>>> I'm a bit surprised that you get the "Address already in use" error 
>>>> though. 
>>> Well, to be honest, I was not able to reproduce this failure 
>>> locally. I was running the test in a loop for a couple of days, and 
>>> it didn't fail. But the test has been observed to fail in other test 
>>> runs (jprt, CI, etc).
>>>
>>> I am not an expert in networking, and I would appreciate if someone 
>>> more knowledgeable gives an advise how these intermittent failures 
>>> can be avoided.
>>>
>>>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set 
>>>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE 
>>>> when listening or binding?
>>> If I am not missing something, the test has been observed to fails 
>>> while re-binding. I am wondering if it's possible that the port 
>>> becomes busy after the server socket was closed, but before bind() 
>>> is called again. The probability of this situation seems to be very 
>>> low which has been actually seen - the test fails very rare.
>>>
>>> If this is the case, it seems like servSocket.setReuseAddress(true) 
>>> doesn't help because the port is taken by another process (I am not 
>>> sure that SO_REUSEADDR prevents from this). Again, this is only my 
>>> guess, and I may be wrong.
>> You know, I hadn't thought of that.  I've never been able to 
>> reproduce that problem either, but I'm running on a local virtual box 
>> VM on a laptop, and usually the tests are running sequentially. I 
>> could definitely see the case where other processes are soaking up 
>> the OCSP responder's port.  With those tests, I kind of need the port 
>> to remain the same since I'm putting that server and port in the AIA 
>> extensions of the certs for which it answers.  Given this particular 
>> case, it seems like your solution of keeping the server bound but 
>> just chopping connections off is the best way to go.
>>>>
>>>> When you create the new ServerSocket on line 212, you're now 
>>>> binding it to the port now where originally it started as an 
>>>> unbound socket.  By doing so, the behavior of setReuseAddress() on 
>>>> line 214 is now undefined.
>>> This setReuseAddress() call looks unnecessary now. I'll update the 
>>> test.
>>>> While this test no longer stops/starts the server, other tests may 
>>>> wish to do so and their behavior may not be consistent (though 
>>>> apparently it wasn't consistent even in the old scheme where the 
>>>> socket was unbound, then setReuseAddress() was called...)
>>> Correct. I checked other code which depend on SimpleOCSPServer
>>>
>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>>> javax/net/ssl/Stapling/StapleEnableProps.java
>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>>>
>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>>>
>>> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate 
>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java 
>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java 
>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java 
>>> javax/net/ssl/Stapling/StapleEnableProps.java 
>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>>>
>>>
>>> These tests call stop() only once when actual testcases are done. 
>>> Actually, some of them don't even call stop(), but it seems to work 
>>> fine. As an enhancement, I would add stop() calls to finally blocks, 
>>> but it seems to work fine without it anyway.
>> I liked your solution with the stop() calls in finally blocks and I 
>> agree that they should have them.  I think we get away with it 
>> because in most if not all of those cases they are running as othervm 
>> tests (because we have properties that we set specific to the 
>> tests).  So when the JVM exits resources like sockets are closed by 
>> the OS.  Still, it's better to have the try/finally guards and 
>> explicitly and gracefully shutdown the OCSP responders.
>>>
>>> Here is an updated webrev:
>>>
>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
>> I realize that in many of these test cases we're going to move away 
>> from a start/stop approach to your accept/reject one, but in general 
>> sockets designed to be listening should start unbound, set the 
>> SO_REUSEADDR sockopt, then bind and listen. Was there a specific 
>> reason to change that code, or was it just to streamline it?  Aside 
>> from fewer lines of code, I'm not sure what it buys us.
>>>
>>> Artem
>>>
>>>
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review this update for OCSP stapling tests.
>>>>>
>>>>> The tests use test/java/security/testlibrary/SimpleOCSPServer.java 
>>>>> which try to re-use a server port if the server restarted. Looks 
>>>>> like sometimes it may cause "Address already in use" error.
>>>>>
>>>>> The patch updates OCSP stapling tests with the following:
>>>>> - updated SSLSocketWithStapling.java test not to restart OCSP 
>>>>> responders
>>>>> - updated SimpleOCSPServer to be able to reject incoming connections
>>>>> - updated SimpleOCSPServer to be able to reproduce a delay without 
>>>>> restarting
>>>>>
>>>>> Jamil,
>>>>>
>>>>> Could you please take a look at this update, and confirm if this 
>>>>> update doesn't break the original test scenarios?
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>>>>>
>>>>> Artem
>>>>
>>>
>>
>



From vincent.x.ryan at oracle.com  Fri Aug 12 19:23:50 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 12 Aug 2016 20:23:50 +0100
Subject: [9] RFR 8163503: PKCS12 keystore cannot store non-X.509
	certificates
In-Reply-To: <70ee579b-a506-8c37-4941-093c142c9468@oracle.com>
References: <A6FA0098-68F8-4B62-B77A-064BE3D5B769@oracle.com>
	<7d5347f8-d01f-bd22-19a7-1590200f4ac7@oracle.com>
	<c1eb3632-6ae0-dca7-2773-281222bbc71e@oracle.com>
	<965F1A6E-D41B-4061-A6D9-F21004F95020@oracle.com>
	<a71707c1-5fa7-9084-5f43-ea579857263c@oracle.com>
	<BC18C8A7-F1A3-4088-8B9A-A37417298548@oracle.com>
	<70ee579b-a506-8c37-4941-093c142c9468@oracle.com>
Message-ID: <CDCF243B-E122-4C55-96E1-10AB3FD2817F@oracle.com>

I?ve made that change at l.970 and updated webrev.02 in-place.
Thanks.

> On 12 Aug 2016, at 19:53, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Looks fine, although I would probably avoid calling checkX509Certs on line 970 and just checking the cert right there to avoid creating the array which is not needed.
> 
> --Sean
> 
> On 08/12/2016 11:07 AM, Vincent Ryan wrote:
>> I?ve moved the X.509 check to earlier in the code and reverted the changes to the validateChain method.
>> Updated webrev is at:
>>   http://cr.openjdk.java.net/~vinnie/8163503/webrev.02/
>> 
>> 
>> 
>>> On 10 Aug 2016, at 21:15, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> On 08/10/2016 12:39 PM, Vincent Ryan wrote:
>>>> Yes they could be merged but the first loop iterates over all the certs and the second one iterates over all but the final cert.
>>>> And the special case of a 1-cert chain also needs to be handled. I think it?s a little clearer to leave them separate.
>>> 
>>> Agreed, but it's probably better to check these earlier and bail out if they are not all X509Certificates, for example, right at the beginning of engineSetKeyEntry. There is no need to proceed with decoding keys, etc since it is already a violation of the supported API parameters.
>>> 
>>> --Sean
>>> 
>>>> 
>>>> An updated webrev is at:
>>>> http://cr.openjdk.java.net/~vinnie/8163503/webrev.01/
>>>> 
>>>> Thanks.
>>>> 
>>>>> On 10 Aug 2016, at 02:04, Xuelei Fan <Xuelei.Fan at Oracle.Com> wrote:
>>>>> 
>>>>> The for loop at line 1507 and 1520 may be merged together.
>>>>> 
>>>>> Xuelei
>>>>> 
>>>>> On 8/10/2016 8:38 AM, Weijun Wang wrote:
>>>>>> I thought I've seen this webrev before.
>>>>>> 
>>>>>> Why not just throw a KeyStoreException in validateChain()?
>>>>>> 
>>>>>> --Max
>>>>>> 
>>>>>> On 8/10/2016 2:14, Vincent Ryan wrote:
>>>>>>> Please review this fix to improve the error handling for attempts to
>>>>>>> store a Certificate object in PKCS12 keystore.
>>>>>>> The PKCS12 keystore implementation supports storing only
>>>>>>> X509Certificate objects but the KeyStore API allows Certificate objects.
>>>>>>> This fix rejects attempts to store non-X.509 certificates and throws a
>>>>>>> KeyStoreException.
>>>>>>> 
>>>>>>> Thanks.
>>>>>>> 
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163503
>>>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8163503/webrev.00/
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>> 



From artem.smotrakov at oracle.com  Fri Aug 12 20:07:11 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Fri, 12 Aug 2016 13:07:11 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <2c1072d4-85d2-7a8b-5729-d77ded672fa0@oracle.com>
References: <c18375fb-04ca-9f3c-c75d-33c5f1f34532@oracle.com>
	<6f25548c-70df-8b24-147c-f61ce89a125a@oracle.com>
	<eea0ab8a-398a-d481-85f1-5823634e794a@oracle.com>
	<db93cb12-aea1-dfa7-8a2f-d1435bfe608a@oracle.com>
	<fbe414b0-4d06-4c41-c243-cbd0098c975f@oracle.com>
	<2c1072d4-85d2-7a8b-5729-d77ded672fa0@oracle.com>
Message-ID: <badea4e7-c100-5b64-37ad-4dd0e7d24199@oracle.com>

No problem.

http://cr.openjdk.java.net/~asmotrak/8162484/webrev.02/

Artem


On 08/12/2016 12:02 PM, Jamil Nimeh wrote:
> For the tests as we use them today we don't intend the server to 
> restart.  The intent of SimpleOCSPServer was to be of use for a 
> variety of testing purposes.  I don't know that we can say for all 
> intended uses that we'll *never* need to restart it. That's why I'd 
> like to keep the unbound socket/set sockopt/bind/listen behavior.  I 
> don't think ServerSocket(0) achieves that.
>
> --Jamil
>
> On 8/12/2016 11:30 AM, Artem Smotrakov wrote:
>> Hi Jamil,
>>
>> There was no any specific reason to remove ServerSocket.bind() call. 
>> ServerSocket(0) constructor creates a server socket, automatically 
>> bound to a random free port. If I am not missing something, it 
>> doesn't look necessary to set the SO_REUSEADDR socket options if the 
>> server is not going to restart. The code is just shorter if we use 
>> ServerSocket(0) constructor to open a server socket, but I can revert 
>> it to use bind() with 0 port number if you think it's better.
>>
>> Artem
>>
>>
>> On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
>>> Hi Artem, more comments in-line
>>>
>>>
>>> On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
>>>> Hi Jamil,
>>>>
>>>> Thank you for review. Please see inline.
>>>>
>>>>
>>>> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
>>>>> Hi Artem,
>>>>>
>>>>> I'm not an official reviewer but the solution for making the 
>>>>> servers reject connections rather than stop and start looks pretty 
>>>>> fair to me and seems like a nice way to simulate a downed OCSP 
>>>>> responder instead of having to bounce it.  A couple 
>>>>> comments/questions:
>>>>>
>>>>> I'm a bit surprised that you get the "Address already in use" 
>>>>> error though. 
>>>> Well, to be honest, I was not able to reproduce this failure 
>>>> locally. I was running the test in a loop for a couple of days, and 
>>>> it didn't fail. But the test has been observed to fail in other 
>>>> test runs (jprt, CI, etc).
>>>>
>>>> I am not an expert in networking, and I would appreciate if someone 
>>>> more knowledgeable gives an advise how these intermittent failures 
>>>> can be avoided.
>>>>
>>>>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set 
>>>>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE 
>>>>> when listening or binding?
>>>> If I am not missing something, the test has been observed to fails 
>>>> while re-binding. I am wondering if it's possible that the port 
>>>> becomes busy after the server socket was closed, but before bind() 
>>>> is called again. The probability of this situation seems to be very 
>>>> low which has been actually seen - the test fails very rare.
>>>>
>>>> If this is the case, it seems like servSocket.setReuseAddress(true) 
>>>> doesn't help because the port is taken by another process (I am not 
>>>> sure that SO_REUSEADDR prevents from this). Again, this is only my 
>>>> guess, and I may be wrong.
>>> You know, I hadn't thought of that.  I've never been able to 
>>> reproduce that problem either, but I'm running on a local virtual 
>>> box VM on a laptop, and usually the tests are running sequentially. 
>>> I could definitely see the case where other processes are soaking up 
>>> the OCSP responder's port.  With those tests, I kind of need the 
>>> port to remain the same since I'm putting that server and port in 
>>> the AIA extensions of the certs for which it answers.  Given this 
>>> particular case, it seems like your solution of keeping the server 
>>> bound but just chopping connections off is the best way to go.
>>>>>
>>>>> When you create the new ServerSocket on line 212, you're now 
>>>>> binding it to the port now where originally it started as an 
>>>>> unbound socket.  By doing so, the behavior of setReuseAddress() on 
>>>>> line 214 is now undefined.
>>>> This setReuseAddress() call looks unnecessary now. I'll update the 
>>>> test.
>>>>> While this test no longer stops/starts the server, other tests may 
>>>>> wish to do so and their behavior may not be consistent (though 
>>>>> apparently it wasn't consistent even in the old scheme where the 
>>>>> socket was unbound, then setReuseAddress() was called...)
>>>> Correct. I checked other code which depend on SimpleOCSPServer
>>>>
>>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>>>> javax/net/ssl/Stapling/StapleEnableProps.java
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>>>>
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>>>>
>>>> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate 
>>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java 
>>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java 
>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java 
>>>> javax/net/ssl/Stapling/StapleEnableProps.java 
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>>>>
>>>>
>>>> These tests call stop() only once when actual testcases are done. 
>>>> Actually, some of them don't even call stop(), but it seems to work 
>>>> fine. As an enhancement, I would add stop() calls to finally 
>>>> blocks, but it seems to work fine without it anyway.
>>> I liked your solution with the stop() calls in finally blocks and I 
>>> agree that they should have them.  I think we get away with it 
>>> because in most if not all of those cases they are running as 
>>> othervm tests (because we have properties that we set specific to 
>>> the tests).  So when the JVM exits resources like sockets are closed 
>>> by the OS.  Still, it's better to have the try/finally guards and 
>>> explicitly and gracefully shutdown the OCSP responders.
>>>>
>>>> Here is an updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
>>> I realize that in many of these test cases we're going to move away 
>>> from a start/stop approach to your accept/reject one, but in general 
>>> sockets designed to be listening should start unbound, set the 
>>> SO_REUSEADDR sockopt, then bind and listen. Was there a specific 
>>> reason to change that code, or was it just to streamline it?  Aside 
>>> from fewer lines of code, I'm not sure what it buys us.
>>>>
>>>> Artem
>>>>
>>>>
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review this update for OCSP stapling tests.
>>>>>>
>>>>>> The tests use 
>>>>>> test/java/security/testlibrary/SimpleOCSPServer.java which try to 
>>>>>> re-use a server port if the server restarted. Looks like 
>>>>>> sometimes it may cause "Address already in use" error.
>>>>>>
>>>>>> The patch updates OCSP stapling tests with the following:
>>>>>> - updated SSLSocketWithStapling.java test not to restart OCSP 
>>>>>> responders
>>>>>> - updated SimpleOCSPServer to be able to reject incoming connections
>>>>>> - updated SimpleOCSPServer to be able to reproduce a delay 
>>>>>> without restarting
>>>>>>
>>>>>> Jamil,
>>>>>>
>>>>>> Could you please take a look at this update, and confirm if this 
>>>>>> update doesn't break the original test scenarios?
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>>>>>>
>>>>>> Artem
>>>>>
>>>>
>>>
>>
>



From jamil.j.nimeh at oracle.com  Fri Aug 12 21:38:08 2016
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 12 Aug 2016 14:38:08 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
Message-ID: <72walb7qsg2a2j6l62xtybpd.1471037888111@email.android.com>

Thank you Artem. ?The fix looks good. ?You just need a +1 from an official reviewer.


--Jamil
-------- Original message --------From: Artem Smotrakov <artem.smotrakov at oracle.com> Date: 8/12/16  1:07 PM  (GMT-08:00) To: Jamil Nimeh <jamil.j.nimeh at oracle.com>, Security Dev OpenJDK <security-dev at openjdk.java.net> Subject: Re: [9] RFR: 8162484: javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermittently with "Address already in use" error 
No problem.

http://cr.openjdk.java.net/~asmotrak/8162484/webrev.02/

Artem


On 08/12/2016 12:02 PM, Jamil Nimeh wrote:
> For the tests as we use them today we don't intend the server to 
> restart.? The intent of SimpleOCSPServer was to be of use for a 
> variety of testing purposes.? I don't know that we can say for all 
> intended uses that we'll *never* need to restart it. That's why I'd 
> like to keep the unbound socket/set sockopt/bind/listen behavior.? I 
> don't think ServerSocket(0) achieves that.
>
> --Jamil
>
> On 8/12/2016 11:30 AM, Artem Smotrakov wrote:
>> Hi Jamil,
>>
>> There was no any specific reason to remove ServerSocket.bind() call. 
>> ServerSocket(0) constructor creates a server socket, automatically 
>> bound to a random free port. If I am not missing something, it 
>> doesn't look necessary to set the SO_REUSEADDR socket options if the 
>> server is not going to restart. The code is just shorter if we use 
>> ServerSocket(0) constructor to open a server socket, but I can revert 
>> it to use bind() with 0 port number if you think it's better.
>>
>> Artem
>>
>>
>> On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
>>> Hi Artem, more comments in-line
>>>
>>>
>>> On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
>>>> Hi Jamil,
>>>>
>>>> Thank you for review. Please see inline.
>>>>
>>>>
>>>> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
>>>>> Hi Artem,
>>>>>
>>>>> I'm not an official reviewer but the solution for making the 
>>>>> servers reject connections rather than stop and start looks pretty 
>>>>> fair to me and seems like a nice way to simulate a downed OCSP 
>>>>> responder instead of having to bounce it.? A couple 
>>>>> comments/questions:
>>>>>
>>>>> I'm a bit surprised that you get the "Address already in use" 
>>>>> error though. 
>>>> Well, to be honest, I was not able to reproduce this failure 
>>>> locally. I was running the test in a loop for a couple of days, and 
>>>> it didn't fail. But the test has been observed to fail in other 
>>>> test runs (jprt, CI, etc).
>>>>
>>>> I am not an expert in networking, and I would appreciate if someone 
>>>> more knowledgeable gives an advise how these intermittent failures 
>>>> can be avoided.
>>>>
>>>>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set 
>>>>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE 
>>>>> when listening or binding?
>>>> If I am not missing something, the test has been observed to fails 
>>>> while re-binding. I am wondering if it's possible that the port 
>>>> becomes busy after the server socket was closed, but before bind() 
>>>> is called again. The probability of this situation seems to be very 
>>>> low which has been actually seen - the test fails very rare.
>>>>
>>>> If this is the case, it seems like servSocket.setReuseAddress(true) 
>>>> doesn't help because the port is taken by another process (I am not 
>>>> sure that SO_REUSEADDR prevents from this). Again, this is only my 
>>>> guess, and I may be wrong.
>>> You know, I hadn't thought of that.? I've never been able to 
>>> reproduce that problem either, but I'm running on a local virtual 
>>> box VM on a laptop, and usually the tests are running sequentially. 
>>> I could definitely see the case where other processes are soaking up 
>>> the OCSP responder's port.? With those tests, I kind of need the 
>>> port to remain the same since I'm putting that server and port in 
>>> the AIA extensions of the certs for which it answers.? Given this 
>>> particular case, it seems like your solution of keeping the server 
>>> bound but just chopping connections off is the best way to go.
>>>>>
>>>>> When you create the new ServerSocket on line 212, you're now 
>>>>> binding it to the port now where originally it started as an 
>>>>> unbound socket.? By doing so, the behavior of setReuseAddress() on 
>>>>> line 214 is now undefined.
>>>> This setReuseAddress() call looks unnecessary now. I'll update the 
>>>> test.
>>>>> While this test no longer stops/starts the server, other tests may 
>>>>> wish to do so and their behavior may not be consistent (though 
>>>>> apparently it wasn't consistent even in the old scheme where the 
>>>>> socket was unbound, then setReuseAddress() was called...)
>>>> Correct. I checked other code which depend on SimpleOCSPServer
>>>>
>>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>>>> javax/net/ssl/Stapling/StapleEnableProps.java
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>>>>
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>>>>
>>>> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate 
>>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java 
>>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java 
>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java 
>>>> javax/net/ssl/Stapling/StapleEnableProps.java 
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>>>>
>>>>
>>>> These tests call stop() only once when actual testcases are done. 
>>>> Actually, some of them don't even call stop(), but it seems to work 
>>>> fine. As an enhancement, I would add stop() calls to finally 
>>>> blocks, but it seems to work fine without it anyway.
>>> I liked your solution with the stop() calls in finally blocks and I 
>>> agree that they should have them.? I think we get away with it 
>>> because in most if not all of those cases they are running as 
>>> othervm tests (because we have properties that we set specific to 
>>> the tests).? So when the JVM exits resources like sockets are closed 
>>> by the OS.? Still, it's better to have the try/finally guards and 
>>> explicitly and gracefully shutdown the OCSP responders.
>>>>
>>>> Here is an updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
>>> I realize that in many of these test cases we're going to move away 
>>> from a start/stop approach to your accept/reject one, but in general 
>>> sockets designed to be listening should start unbound, set the 
>>> SO_REUSEADDR sockopt, then bind and listen. Was there a specific 
>>> reason to change that code, or was it just to streamline it?? Aside 
>>> from fewer lines of code, I'm not sure what it buys us.
>>>>
>>>> Artem
>>>>
>>>>
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review this update for OCSP stapling tests.
>>>>>>
>>>>>> The tests use 
>>>>>> test/java/security/testlibrary/SimpleOCSPServer.java which try to 
>>>>>> re-use a server port if the server restarted. Looks like 
>>>>>> sometimes it may cause "Address already in use" error.
>>>>>>
>>>>>> The patch updates OCSP stapling tests with the following:
>>>>>> - updated SSLSocketWithStapling.java test not to restart OCSP 
>>>>>> responders
>>>>>> - updated SimpleOCSPServer to be able to reject incoming connections
>>>>>> - updated SimpleOCSPServer to be able to reproduce a delay 
>>>>>> without restarting
>>>>>>
>>>>>> Jamil,
>>>>>>
>>>>>> Could you please take a look at this update, and confirm if this 
>>>>>> update doesn't break the original test scenarios?
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>>>>>>
>>>>>> Artem
>>>>>
>>>>
>>>
>>
>

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

From artem.smotrakov at oracle.com  Fri Aug 12 22:25:03 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Fri, 12 Aug 2016 15:25:03 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <72walb7qsg2a2j6l62xtybpd.1471037888111@email.android.com>
References: <72walb7qsg2a2j6l62xtybpd.1471037888111@email.android.com>
Message-ID: <90a30187-9739-8bdc-7b25-10ea4fae42a7@oracle.com>

Thank you for review Jamil.

Xuelei,

Could you please take a look?

Artem


On 08/12/2016 02:38 PM, Jamil Nimeh wrote:
> Thank you Artem.  The fix looks good.  You just need a +1 from an 
> official reviewer.
>
>
>
> --Jamil
>
> -------- Original message --------
> From: Artem Smotrakov <artem.smotrakov at oracle.com>
> Date: 8/12/16 1:07 PM (GMT-08:00)
> To: Jamil Nimeh <jamil.j.nimeh at oracle.com>, Security Dev OpenJDK 
> <security-dev at openjdk.java.net>
> Subject: Re: [9] RFR: 8162484: 
> javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails 
> intermittently with "Address already in use" error
>
> No problem.
>
> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.02/
>
> Artem
>
>
> On 08/12/2016 12:02 PM, Jamil Nimeh wrote:
> > For the tests as we use them today we don't intend the server to
> > restart.  The intent of SimpleOCSPServer was to be of use for a
> > variety of testing purposes.  I don't know that we can say for all
> > intended uses that we'll *never* need to restart it. That's why I'd
> > like to keep the unbound socket/set sockopt/bind/listen behavior.  I
> > don't think ServerSocket(0) achieves that.
> >
> > --Jamil
> >
> > On 8/12/2016 11:30 AM, Artem Smotrakov wrote:
> >> Hi Jamil,
> >>
> >> There was no any specific reason to remove ServerSocket.bind() call.
> >> ServerSocket(0) constructor creates a server socket, automatically
> >> bound to a random free port. If I am not missing something, it
> >> doesn't look necessary to set the SO_REUSEADDR socket options if the
> >> server is not going to restart. The code is just shorter if we use
> >> ServerSocket(0) constructor to open a server socket, but I can revert
> >> it to use bind() with 0 port number if you think it's better.
> >>
> >> Artem
> >>
> >>
> >> On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
> >>> Hi Artem, more comments in-line
> >>>
> >>>
> >>> On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
> >>>> Hi Jamil,
> >>>>
> >>>> Thank you for review. Please see inline.
> >>>>
> >>>>
> >>>> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
> >>>>> Hi Artem,
> >>>>>
> >>>>> I'm not an official reviewer but the solution for making the
> >>>>> servers reject connections rather than stop and start looks pretty
> >>>>> fair to me and seems like a nice way to simulate a downed OCSP
> >>>>> responder instead of having to bounce it.  A couple
> >>>>> comments/questions:
> >>>>>
> >>>>> I'm a bit surprised that you get the "Address already in use"
> >>>>> error though.
> >>>> Well, to be honest, I was not able to reproduce this failure
> >>>> locally. I was running the test in a loop for a couple of days, and
> >>>> it didn't fail. But the test has been observed to fail in other
> >>>> test runs (jprt, CI, etc).
> >>>>
> >>>> I am not an expert in networking, and I would appreciate if someone
> >>>> more knowledgeable gives an advise how these intermittent failures
> >>>> can be avoided.
> >>>>
> >>>>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set
> >>>>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE
> >>>>> when listening or binding?
> >>>> If I am not missing something, the test has been observed to fails
> >>>> while re-binding. I am wondering if it's possible that the port
> >>>> becomes busy after the server socket was closed, but before bind()
> >>>> is called again. The probability of this situation seems to be very
> >>>> low which has been actually seen - the test fails very rare.
> >>>>
> >>>> If this is the case, it seems like servSocket.setReuseAddress(true)
> >>>> doesn't help because the port is taken by another process (I am not
> >>>> sure that SO_REUSEADDR prevents from this). Again, this is only my
> >>>> guess, and I may be wrong.
> >>> You know, I hadn't thought of that.  I've never been able to
> >>> reproduce that problem either, but I'm running on a local virtual
> >>> box VM on a laptop, and usually the tests are running sequentially.
> >>> I could definitely see the case where other processes are soaking up
> >>> the OCSP responder's port.  With those tests, I kind of need the
> >>> port to remain the same since I'm putting that server and port in
> >>> the AIA extensions of the certs for which it answers.  Given this
> >>> particular case, it seems like your solution of keeping the server
> >>> bound but just chopping connections off is the best way to go.
> >>>>>
> >>>>> When you create the new ServerSocket on line 212, you're now
> >>>>> binding it to the port now where originally it started as an
> >>>>> unbound socket.  By doing so, the behavior of setReuseAddress() on
> >>>>> line 214 is now undefined.
> >>>> This setReuseAddress() call looks unnecessary now. I'll update the
> >>>> test.
> >>>>> While this test no longer stops/starts the server, other tests may
> >>>>> wish to do so and their behavior may not be consistent (though
> >>>>> apparently it wasn't consistent even in the old scheme where the
> >>>>> socket was unbound, then setReuseAddress() was called...)
> >>>> Correct. I checked other code which depend on SimpleOCSPServer
> >>>>
> >>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
> >>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
> >>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
> >>>> javax/net/ssl/Stapling/StapleEnableProps.java
> >>>> 
> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>
> >>>>
> >>>> 
> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>
> >>>>
> >>>> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate
> >>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
> >>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
> >>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
> >>>> javax/net/ssl/Stapling/StapleEnableProps.java
> >>>> 
> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java 
>
> >>>> 
> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java 
>
> >>>>
> >>>>
> >>>> These tests call stop() only once when actual testcases are done.
> >>>> Actually, some of them don't even call stop(), but it seems to work
> >>>> fine. As an enhancement, I would add stop() calls to finally
> >>>> blocks, but it seems to work fine without it anyway.
> >>> I liked your solution with the stop() calls in finally blocks and I
> >>> agree that they should have them.  I think we get away with it
> >>> because in most if not all of those cases they are running as
> >>> othervm tests (because we have properties that we set specific to
> >>> the tests).  So when the JVM exits resources like sockets are closed
> >>> by the OS.  Still, it's better to have the try/finally guards and
> >>> explicitly and gracefully shutdown the OCSP responders.
> >>>>
> >>>> Here is an updated webrev:
> >>>>
> >>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
> >>> I realize that in many of these test cases we're going to move away
> >>> from a start/stop approach to your accept/reject one, but in general
> >>> sockets designed to be listening should start unbound, set the
> >>> SO_REUSEADDR sockopt, then bind and listen. Was there a specific
> >>> reason to change that code, or was it just to streamline it?  Aside
> >>> from fewer lines of code, I'm not sure what it buys us.
> >>>>
> >>>> Artem
> >>>>
> >>>>
> >>>>>
> >>>>> --Jamil
> >>>>>
> >>>>>
> >>>>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> Please review this update for OCSP stapling tests.
> >>>>>>
> >>>>>> The tests use
> >>>>>> test/java/security/testlibrary/SimpleOCSPServer.java which try to
> >>>>>> re-use a server port if the server restarted. Looks like
> >>>>>> sometimes it may cause "Address already in use" error.
> >>>>>>
> >>>>>> The patch updates OCSP stapling tests with the following:
> >>>>>> - updated SSLSocketWithStapling.java test not to restart OCSP
> >>>>>> responders
> >>>>>> - updated SimpleOCSPServer to be able to reject incoming 
> connections
> >>>>>> - updated SimpleOCSPServer to be able to reproduce a delay
> >>>>>> without restarting
> >>>>>>
> >>>>>> Jamil,
> >>>>>>
> >>>>>> Could you please take a look at this update, and confirm if this
> >>>>>> update doesn't break the original test scenarios?
> >>>>>>
> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
> >>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
> >>>>>>
> >>>>>> Artem
> >>>>>
> >>>>
> >>>
> >>
> >
>

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

From ivan.gerasimov at oracle.com  Sat Aug 13 01:15:42 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 13 Aug 2016 04:15:42 +0300
Subject: [jdk9] RFR: 8163896: Finalizing one key of a KeyPair invalidates the
	other key
Message-ID: <4330543b-37ed-93fb-ea05-1e61ad071bd3@oracle.com>

Hello!

It was noticed, that SunMSCAPI implementation of a KeyPair has a 
problem: The public and the private keys share the same native handles.

As the result, when one of the keys is finalized, and its resources are 
freed, the second key becomes invalid.

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163896
WEBREV: http://cr.openjdk.java.net/~igerasim/8163896/00/webrev/

With kind regards,
Ivan



From xuelei.fan at oracle.com  Sat Aug 13 01:17:21 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 13 Aug 2016 09:17:21 +0800
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <90a30187-9739-8bdc-7b25-10ea4fae42a7@oracle.com>
References: <72walb7qsg2a2j6l62xtybpd.1471037888111@email.android.com>
	<90a30187-9739-8bdc-7b25-10ea4fae42a7@oracle.com>
Message-ID: <97b081a2-b982-41fc-cf46-bb59f6eebbf0@oracle.com>

It's a nice find of the port reuse issues.

This update will turn into expected connection failure into
reading/writing interruption as the server simulate the failure by
closing the incoming connections.  It's fine for this test,  I think.

For lines like:
 288         intOcsp.rejectConnections();
 289         rootOcsp.rejectConnections();
 290         Thread.sleep(1000);

I was wondering as the server does not need to bootup again, is the
delay still needed?

Otherwise, looks fine to me.

Thanks,
Xuelei

On 8/13/2016 6:25 AM, Artem Smotrakov wrote:
> Thank you for review Jamil.
> 
> Xuelei,
> 
> Could you please take a look?
> 
> Artem
> 
> 
> On 08/12/2016 02:38 PM, Jamil Nimeh wrote:
>> Thank you Artem.  The fix looks good.  You just need a +1 from an
>> official reviewer.
>>
>>
>>
>> --Jamil
>>
>> -------- Original message --------
>> From: Artem Smotrakov <artem.smotrakov at oracle.com>
>> Date: 8/12/16 1:07 PM (GMT-08:00)
>> To: Jamil Nimeh <jamil.j.nimeh at oracle.com>, Security Dev OpenJDK
>> <security-dev at openjdk.java.net>
>> Subject: Re: [9] RFR: 8162484:
>> javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
>> intermittently with "Address already in use" error
>>
>> No problem.
>>
>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.02/
>>
>> Artem
>>
>>
>> On 08/12/2016 12:02 PM, Jamil Nimeh wrote:
>> > For the tests as we use them today we don't intend the server to
>> > restart.  The intent of SimpleOCSPServer was to be of use for a
>> > variety of testing purposes.  I don't know that we can say for all
>> > intended uses that we'll *never* need to restart it. That's why I'd
>> > like to keep the unbound socket/set sockopt/bind/listen behavior.  I
>> > don't think ServerSocket(0) achieves that.
>> >
>> > --Jamil
>> >
>> > On 8/12/2016 11:30 AM, Artem Smotrakov wrote:
>> >> Hi Jamil,
>> >>
>> >> There was no any specific reason to remove ServerSocket.bind() call.
>> >> ServerSocket(0) constructor creates a server socket, automatically
>> >> bound to a random free port. If I am not missing something, it
>> >> doesn't look necessary to set the SO_REUSEADDR socket options if the
>> >> server is not going to restart. The code is just shorter if we use
>> >> ServerSocket(0) constructor to open a server socket, but I can revert
>> >> it to use bind() with 0 port number if you think it's better.
>> >>
>> >> Artem
>> >>
>> >>
>> >> On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
>> >>> Hi Artem, more comments in-line
>> >>>
>> >>>
>> >>> On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
>> >>>> Hi Jamil,
>> >>>>
>> >>>> Thank you for review. Please see inline.
>> >>>>
>> >>>>
>> >>>> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
>> >>>>> Hi Artem,
>> >>>>>
>> >>>>> I'm not an official reviewer but the solution for making the
>> >>>>> servers reject connections rather than stop and start looks pretty
>> >>>>> fair to me and seems like a nice way to simulate a downed OCSP
>> >>>>> responder instead of having to bounce it.  A couple
>> >>>>> comments/questions:
>> >>>>>
>> >>>>> I'm a bit surprised that you get the "Address already in use"
>> >>>>> error though.
>> >>>> Well, to be honest, I was not able to reproduce this failure
>> >>>> locally. I was running the test in a loop for a couple of days, and
>> >>>> it didn't fail. But the test has been observed to fail in other
>> >>>> test runs (jprt, CI, etc).
>> >>>>
>> >>>> I am not an expert in networking, and I would appreciate if someone
>> >>>> more knowledgeable gives an advise how these intermittent failures
>> >>>> can be avoided.
>> >>>>
>> >>>>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set
>> >>>>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE
>> >>>>> when listening or binding?
>> >>>> If I am not missing something, the test has been observed to fails
>> >>>> while re-binding. I am wondering if it's possible that the port
>> >>>> becomes busy after the server socket was closed, but before bind()
>> >>>> is called again. The probability of this situation seems to be very
>> >>>> low which has been actually seen - the test fails very rare.
>> >>>>
>> >>>> If this is the case, it seems like servSocket.setReuseAddress(true)
>> >>>> doesn't help because the port is taken by another process (I am not
>> >>>> sure that SO_REUSEADDR prevents from this). Again, this is only my
>> >>>> guess, and I may be wrong.
>> >>> You know, I hadn't thought of that.  I've never been able to
>> >>> reproduce that problem either, but I'm running on a local virtual
>> >>> box VM on a laptop, and usually the tests are running sequentially.
>> >>> I could definitely see the case where other processes are soaking up
>> >>> the OCSP responder's port.  With those tests, I kind of need the
>> >>> port to remain the same since I'm putting that server and port in
>> >>> the AIA extensions of the certs for which it answers.  Given this
>> >>> particular case, it seems like your solution of keeping the server
>> >>> bound but just chopping connections off is the best way to go.
>> >>>>>
>> >>>>> When you create the new ServerSocket on line 212, you're now
>> >>>>> binding it to the port now where originally it started as an
>> >>>>> unbound socket.  By doing so, the behavior of setReuseAddress() on
>> >>>>> line 214 is now undefined.
>> >>>> This setReuseAddress() call looks unnecessary now. I'll update the
>> >>>> test.
>> >>>>> While this test no longer stops/starts the server, other tests may
>> >>>>> wish to do so and their behavior may not be consistent (though
>> >>>>> apparently it wasn't consistent even in the old scheme where the
>> >>>>> socket was unbound, then setReuseAddress() was called...)
>> >>>> Correct. I checked other code which depend on SimpleOCSPServer
>> >>>>
>> >>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>> >>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>> >>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>> >>>> javax/net/ssl/Stapling/StapleEnableProps.java
>> >>>>
>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java
>>
>> >>>>
>> >>>>
>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java
>>
>> >>>>
>> >>>> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate
>> >>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>> >>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>> >>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>> >>>> javax/net/ssl/Stapling/StapleEnableProps.java
>> >>>>
>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java
>>
>> >>>>
>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java
>>
>> >>>>
>> >>>>
>> >>>> These tests call stop() only once when actual testcases are done.
>> >>>> Actually, some of them don't even call stop(), but it seems to work
>> >>>> fine. As an enhancement, I would add stop() calls to finally
>> >>>> blocks, but it seems to work fine without it anyway.
>> >>> I liked your solution with the stop() calls in finally blocks and I
>> >>> agree that they should have them.  I think we get away with it
>> >>> because in most if not all of those cases they are running as
>> >>> othervm tests (because we have properties that we set specific to
>> >>> the tests).  So when the JVM exits resources like sockets are closed
>> >>> by the OS.  Still, it's better to have the try/finally guards and
>> >>> explicitly and gracefully shutdown the OCSP responders.
>> >>>>
>> >>>> Here is an updated webrev:
>> >>>>
>> >>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
>> >>> I realize that in many of these test cases we're going to move away
>> >>> from a start/stop approach to your accept/reject one, but in general
>> >>> sockets designed to be listening should start unbound, set the
>> >>> SO_REUSEADDR sockopt, then bind and listen. Was there a specific
>> >>> reason to change that code, or was it just to streamline it?  Aside
>> >>> from fewer lines of code, I'm not sure what it buys us.
>> >>>>
>> >>>> Artem
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> --Jamil
>> >>>>>
>> >>>>>
>> >>>>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>> >>>>>> Hello,
>> >>>>>>
>> >>>>>> Please review this update for OCSP stapling tests.
>> >>>>>>
>> >>>>>> The tests use
>> >>>>>> test/java/security/testlibrary/SimpleOCSPServer.java which try to
>> >>>>>> re-use a server port if the server restarted. Looks like
>> >>>>>> sometimes it may cause "Address already in use" error.
>> >>>>>>
>> >>>>>> The patch updates OCSP stapling tests with the following:
>> >>>>>> - updated SSLSocketWithStapling.java test not to restart OCSP
>> >>>>>> responders
>> >>>>>> - updated SimpleOCSPServer to be able to reject incoming
>> connections
>> >>>>>> - updated SimpleOCSPServer to be able to reproduce a delay
>> >>>>>> without restarting
>> >>>>>>
>> >>>>>> Jamil,
>> >>>>>>
>> >>>>>> Could you please take a look at this update, and confirm if this
>> >>>>>> update doesn't break the original test scenarios?
>> >>>>>>
>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>> >>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>> >>>>>>
>> >>>>>> Artem
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
> 



From sibabrata.sahoo at oracle.com  Mon Aug 15 07:34:32 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Mon, 15 Aug 2016 00:34:32 -0700 (PDT)
Subject: [9] RFR: 8153146 & 8087144 for sun/security/krb5/auto/MaxRetries.java
Message-ID: <1c642c67-8d27-4c2a-929b-6d22a5388fe6@default>

Hi,

 

Please review the patch for 2 issues on "sun/security/krb5/auto/MaxRetries.java".

 

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

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

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

 

Description:

MaxRetries was failing frequently with "Retry count is -1 less". When a communication happens to an active KDC there is a chance of getting resent message in case of delayed acknowledgement. The test was expecting certain number of response message but the resent messages was making the count wrong. Due to that the failure was occurring. 

 

MaxRetries was a single test file including several test cases, such as tryLast, tryLess etc. I tried to split the cases to multiple files because the single test file was running longer. Now each individual test takes less time comparatively previous but I have observed that doing so  increases up to 7second of overall time.

 

About https://bugs.openjdk.java.net/browse/JDK-8087144, based on existing log that is available, it looks like the rare failure occurs when the timeout interval provided is very small(about 2 sec). I have tried to double the exiting timeout interval to avoid such problem for this particular case.

 

Few of difference in "BadKdc.java", is due to NetBeans IDE formatting.

 

Thanks,

Siba

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

From sean.coffey at oracle.com  Mon Aug 15 10:04:11 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 15 Aug 2016 11:04:11 +0100
Subject: [jdk9] RFR: 8163896: Finalizing one key of a KeyPair invalidates
	the other key
In-Reply-To: <4330543b-37ed-93fb-ea05-1e61ad071bd3@oracle.com>
References: <4330543b-37ed-93fb-ea05-1e61ad071bd3@oracle.com>
Message-ID: <57B1939B.9000703@oracle.com>

Not sure how you end up finding such issues Ivan!

The fix looks good. One suggestion on the testcase. Could you make it 
more generic ? i.e. don't just test the MSCAPI provider. Let's cycle 
through all providers available for KeyPairGenerator and ensure no other 
provider suffers (or introduces) the same issue.

Regards,
Sean.

On 13/08/16 02:15, Ivan Gerasimov wrote:
> Hello!
>
> It was noticed, that SunMSCAPI implementation of a KeyPair has a 
> problem: The public and the private keys share the same native handles.
>
> As the result, when one of the keys is finalized, and its resources 
> are freed, the second key becomes invalid.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163896
> WEBREV: http://cr.openjdk.java.net/~igerasim/8163896/00/webrev/
>
> With kind regards,
> Ivan
>



From ivan.gerasimov at oracle.com  Mon Aug 15 10:50:35 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 15 Aug 2016 13:50:35 +0300
Subject: [jdk9] RFR: 8163896: Finalizing one key of a KeyPair invalidates
	the other key
In-Reply-To: <57B1939B.9000703@oracle.com>
References: <4330543b-37ed-93fb-ea05-1e61ad071bd3@oracle.com>
	<57B1939B.9000703@oracle.com>
Message-ID: <084323cf-4ef5-b4ee-b5b7-782c891cb4e1@oracle.com>

Thank you Se?n for review!

It's a good point about making the testcase more generic; I'll modify it 
as you suggest.

With kind regards,
Ivan

On 15.08.2016 13:04, Se?n Coffey wrote:
> Not sure how you end up finding such issues Ivan!
>
> The fix looks good. One suggestion on the testcase. Could you make it 
> more generic ? i.e. don't just test the MSCAPI provider. Let's cycle 
> through all providers available for KeyPairGenerator and ensure no 
> other provider suffers (or introduces) the same issue.
>
> Regards,
> Sean.
>
> On 13/08/16 02:15, Ivan Gerasimov wrote:
>> Hello!
>>
>> It was noticed, that SunMSCAPI implementation of a KeyPair has a 
>> problem: The public and the private keys share the same native handles.
>>
>> As the result, when one of the keys is finalized, and its resources 
>> are freed, the second key becomes invalid.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163896
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163896/00/webrev/
>>
>> With kind regards,
>> Ivan
>>
>
>



From vincent.x.ryan at oracle.com  Mon Aug 15 16:13:15 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Mon, 15 Aug 2016 17:13:15 +0100
Subject: [jdk9] RFR: 8163896: Finalizing one key of a KeyPair invalidates
	the other key
In-Reply-To: <4330543b-37ed-93fb-ea05-1e61ad071bd3@oracle.com>
References: <4330543b-37ed-93fb-ea05-1e61ad071bd3@oracle.com>
Message-ID: <5C24EF10-AB61-4FD8-B897-38D2CEBAE4FB@oracle.com>

Thanks Ivan. Your fix looks good.


> On 13 Aug 2016, at 02:15, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hello!
> 
> It was noticed, that SunMSCAPI implementation of a KeyPair has a problem: The public and the private keys share the same native handles.
> 
> As the result, when one of the keys is finalized, and its resources are freed, the second key becomes invalid.
> 
> Would you please help review the fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163896
> WEBREV: http://cr.openjdk.java.net/~igerasim/8163896/00/webrev/
> 
> With kind regards,
> Ivan
> 



From artem.smotrakov at oracle.com  Mon Aug 15 17:31:19 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Mon, 15 Aug 2016 10:31:19 -0700
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <97b081a2-b982-41fc-cf46-bb59f6eebbf0@oracle.com>
References: <72walb7qsg2a2j6l62xtybpd.1471037888111@email.android.com>
	<90a30187-9739-8bdc-7b25-10ea4fae42a7@oracle.com>
	<97b081a2-b982-41fc-cf46-bb59f6eebbf0@oracle.com>
Message-ID: <f0ab2367-0900-5863-5df1-93b910ec8d17@oracle.com>

Hi Xuelei,

Makes sense to me, I removed those 1 second delays

http://cr.openjdk.java.net/~asmotrak/8162484/webrev.03/

Artem


On 08/12/2016 06:17 PM, Xuelei Fan wrote:
> It's a nice find of the port reuse issues.
>
> This update will turn into expected connection failure into
> reading/writing interruption as the server simulate the failure by
> closing the incoming connections.  It's fine for this test,  I think.
>
> For lines like:
>   288         intOcsp.rejectConnections();
>   289         rootOcsp.rejectConnections();
>   290         Thread.sleep(1000);
>
> I was wondering as the server does not need to bootup again, is the
> delay still needed?
>
> Otherwise, looks fine to me.
>
> Thanks,
> Xuelei
>
> On 8/13/2016 6:25 AM, Artem Smotrakov wrote:
>> Thank you for review Jamil.
>>
>> Xuelei,
>>
>> Could you please take a look?
>>
>> Artem
>>
>>
>> On 08/12/2016 02:38 PM, Jamil Nimeh wrote:
>>> Thank you Artem.  The fix looks good.  You just need a +1 from an
>>> official reviewer.
>>>
>>>
>>>
>>> --Jamil
>>>
>>> -------- Original message --------
>>> From: Artem Smotrakov <artem.smotrakov at oracle.com>
>>> Date: 8/12/16 1:07 PM (GMT-08:00)
>>> To: Jamil Nimeh <jamil.j.nimeh at oracle.com>, Security Dev OpenJDK
>>> <security-dev at openjdk.java.net>
>>> Subject: Re: [9] RFR: 8162484:
>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
>>> intermittently with "Address already in use" error
>>>
>>> No problem.
>>>
>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.02/
>>>
>>> Artem
>>>
>>>
>>> On 08/12/2016 12:02 PM, Jamil Nimeh wrote:
>>>> For the tests as we use them today we don't intend the server to
>>>> restart.  The intent of SimpleOCSPServer was to be of use for a
>>>> variety of testing purposes.  I don't know that we can say for all
>>>> intended uses that we'll *never* need to restart it. That's why I'd
>>>> like to keep the unbound socket/set sockopt/bind/listen behavior.  I
>>>> don't think ServerSocket(0) achieves that.
>>>>
>>>> --Jamil
>>>>
>>>> On 8/12/2016 11:30 AM, Artem Smotrakov wrote:
>>>>> Hi Jamil,
>>>>>
>>>>> There was no any specific reason to remove ServerSocket.bind() call.
>>>>> ServerSocket(0) constructor creates a server socket, automatically
>>>>> bound to a random free port. If I am not missing something, it
>>>>> doesn't look necessary to set the SO_REUSEADDR socket options if the
>>>>> server is not going to restart. The code is just shorter if we use
>>>>> ServerSocket(0) constructor to open a server socket, but I can revert
>>>>> it to use bind() with 0 port number if you think it's better.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
>>>>>> Hi Artem, more comments in-line
>>>>>>
>>>>>>
>>>>>> On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
>>>>>>> Hi Jamil,
>>>>>>>
>>>>>>> Thank you for review. Please see inline.
>>>>>>>
>>>>>>>
>>>>>>> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
>>>>>>>> Hi Artem,
>>>>>>>>
>>>>>>>> I'm not an official reviewer but the solution for making the
>>>>>>>> servers reject connections rather than stop and start looks pretty
>>>>>>>> fair to me and seems like a nice way to simulate a downed OCSP
>>>>>>>> responder instead of having to bounce it.  A couple
>>>>>>>> comments/questions:
>>>>>>>>
>>>>>>>> I'm a bit surprised that you get the "Address already in use"
>>>>>>>> error though.
>>>>>>> Well, to be honest, I was not able to reproduce this failure
>>>>>>> locally. I was running the test in a loop for a couple of days, and
>>>>>>> it didn't fail. But the test has been observed to fail in other
>>>>>>> test runs (jprt, CI, etc).
>>>>>>>
>>>>>>> I am not an expert in networking, and I would appreciate if someone
>>>>>>> more knowledgeable gives an advise how these intermittent failures
>>>>>>> can be avoided.
>>>>>>>
>>>>>>>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set
>>>>>>>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE
>>>>>>>> when listening or binding?
>>>>>>> If I am not missing something, the test has been observed to fails
>>>>>>> while re-binding. I am wondering if it's possible that the port
>>>>>>> becomes busy after the server socket was closed, but before bind()
>>>>>>> is called again. The probability of this situation seems to be very
>>>>>>> low which has been actually seen - the test fails very rare.
>>>>>>>
>>>>>>> If this is the case, it seems like servSocket.setReuseAddress(true)
>>>>>>> doesn't help because the port is taken by another process (I am not
>>>>>>> sure that SO_REUSEADDR prevents from this). Again, this is only my
>>>>>>> guess, and I may be wrong.
>>>>>> You know, I hadn't thought of that.  I've never been able to
>>>>>> reproduce that problem either, but I'm running on a local virtual
>>>>>> box VM on a laptop, and usually the tests are running sequentially.
>>>>>> I could definitely see the case where other processes are soaking up
>>>>>> the OCSP responder's port.  With those tests, I kind of need the
>>>>>> port to remain the same since I'm putting that server and port in
>>>>>> the AIA extensions of the certs for which it answers.  Given this
>>>>>> particular case, it seems like your solution of keeping the server
>>>>>> bound but just chopping connections off is the best way to go.
>>>>>>>> When you create the new ServerSocket on line 212, you're now
>>>>>>>> binding it to the port now where originally it started as an
>>>>>>>> unbound socket.  By doing so, the behavior of setReuseAddress() on
>>>>>>>> line 214 is now undefined.
>>>>>>> This setReuseAddress() call looks unnecessary now. I'll update the
>>>>>>> test.
>>>>>>>> While this test no longer stops/starts the server, other tests may
>>>>>>>> wish to do so and their behavior may not be consistent (though
>>>>>>>> apparently it wasn't consistent even in the old scheme where the
>>>>>>>> socket was unbound, then setReuseAddress() was called...)
>>>>>>> Correct. I checked other code which depend on SimpleOCSPServer
>>>>>>>
>>>>>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>>>>>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>>>>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>>>>>>> javax/net/ssl/Stapling/StapleEnableProps.java
>>>>>>>
>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java
>>>
>>>>>>>
>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java
>>>
>>>>>>> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate
>>>>>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>>>>>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>>>>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>>>>>>> javax/net/ssl/Stapling/StapleEnableProps.java
>>>>>>>
>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java
>>>
>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java
>>>
>>>>>>>
>>>>>>> These tests call stop() only once when actual testcases are done.
>>>>>>> Actually, some of them don't even call stop(), but it seems to work
>>>>>>> fine. As an enhancement, I would add stop() calls to finally
>>>>>>> blocks, but it seems to work fine without it anyway.
>>>>>> I liked your solution with the stop() calls in finally blocks and I
>>>>>> agree that they should have them.  I think we get away with it
>>>>>> because in most if not all of those cases they are running as
>>>>>> othervm tests (because we have properties that we set specific to
>>>>>> the tests).  So when the JVM exits resources like sockets are closed
>>>>>> by the OS.  Still, it's better to have the try/finally guards and
>>>>>> explicitly and gracefully shutdown the OCSP responders.
>>>>>>> Here is an updated webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
>>>>>> I realize that in many of these test cases we're going to move away
>>>>>> from a start/stop approach to your accept/reject one, but in general
>>>>>> sockets designed to be listening should start unbound, set the
>>>>>> SO_REUSEADDR sockopt, then bind and listen. Was there a specific
>>>>>> reason to change that code, or was it just to streamline it?  Aside
>>>>>> from fewer lines of code, I'm not sure what it buys us.
>>>>>>> Artem
>>>>>>>
>>>>>>>
>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review this update for OCSP stapling tests.
>>>>>>>>>
>>>>>>>>> The tests use
>>>>>>>>> test/java/security/testlibrary/SimpleOCSPServer.java which try to
>>>>>>>>> re-use a server port if the server restarted. Looks like
>>>>>>>>> sometimes it may cause "Address already in use" error.
>>>>>>>>>
>>>>>>>>> The patch updates OCSP stapling tests with the following:
>>>>>>>>> - updated SSLSocketWithStapling.java test not to restart OCSP
>>>>>>>>> responders
>>>>>>>>> - updated SimpleOCSPServer to be able to reject incoming
>>> connections
>>>>>>>>> - updated SimpleOCSPServer to be able to reproduce a delay
>>>>>>>>> without restarting
>>>>>>>>>
>>>>>>>>> Jamil,
>>>>>>>>>
>>>>>>>>> Could you please take a look at this update, and confirm if this
>>>>>>>>> update doesn't break the original test scenarios?
>>>>>>>>>
>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>>>>>>>>>
>>>>>>>>> Artem



From ivan.gerasimov at oracle.com  Mon Aug 15 20:52:16 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 15 Aug 2016 23:52:16 +0300
Subject: [jdk9] RFR: 8163896: Finalizing one key of a KeyPair invalidates
	the other key
In-Reply-To: <5C24EF10-AB61-4FD8-B897-38D2CEBAE4FB@oracle.com>
References: <4330543b-37ed-93fb-ea05-1e61ad071bd3@oracle.com>
	<5C24EF10-AB61-4FD8-B897-38D2CEBAE4FB@oracle.com>
Message-ID: <8934ceed-ac0a-ed0d-694a-55460cb8486a@oracle.com>

Thank you Vincent for review!

With kind regards,
Ivan


On 15.08.2016 19:13, Vincent Ryan wrote:
> Thanks Ivan. Your fix looks good.
>
>
>> On 13 Aug 2016, at 02:15, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> Hello!
>>
>> It was noticed, that SunMSCAPI implementation of a KeyPair has a problem: The public and the private keys share the same native handles.
>>
>> As the result, when one of the keys is finalized, and its resources are freed, the second key becomes invalid.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163896
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163896/00/webrev/
>>
>> With kind regards,
>> Ivan
>>
>



From xuelei.fan at oracle.com  Mon Aug 15 23:29:13 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 16 Aug 2016 07:29:13 +0800
Subject: [9] RFR: 8162484:
	javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
	intermittently with "Address already in use" error
In-Reply-To: <f0ab2367-0900-5863-5df1-93b910ec8d17@oracle.com>
References: <72walb7qsg2a2j6l62xtybpd.1471037888111@email.android.com>
	<90a30187-9739-8bdc-7b25-10ea4fae42a7@oracle.com>
	<97b081a2-b982-41fc-cf46-bb59f6eebbf0@oracle.com>
	<f0ab2367-0900-5863-5df1-93b910ec8d17@oracle.com>
Message-ID: <8675cd04-2a70-bebb-c202-9dfe6f9ad1bc@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 8/16/2016 1:31 AM, Artem Smotrakov wrote:
> Hi Xuelei,
> 
> Makes sense to me, I removed those 1 second delays
> 
> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.03/
> 
> Artem
> 
> 
> On 08/12/2016 06:17 PM, Xuelei Fan wrote:
>> It's a nice find of the port reuse issues.
>>
>> This update will turn into expected connection failure into
>> reading/writing interruption as the server simulate the failure by
>> closing the incoming connections.  It's fine for this test,  I think.
>>
>> For lines like:
>>   288         intOcsp.rejectConnections();
>>   289         rootOcsp.rejectConnections();
>>   290         Thread.sleep(1000);
>>
>> I was wondering as the server does not need to bootup again, is the
>> delay still needed?
>>
>> Otherwise, looks fine to me.
>>
>> Thanks,
>> Xuelei
>>
>> On 8/13/2016 6:25 AM, Artem Smotrakov wrote:
>>> Thank you for review Jamil.
>>>
>>> Xuelei,
>>>
>>> Could you please take a look?
>>>
>>> Artem
>>>
>>>
>>> On 08/12/2016 02:38 PM, Jamil Nimeh wrote:
>>>> Thank you Artem.  The fix looks good.  You just need a +1 from an
>>>> official reviewer.
>>>>
>>>>
>>>>
>>>> --Jamil
>>>>
>>>> -------- Original message --------
>>>> From: Artem Smotrakov <artem.smotrakov at oracle.com>
>>>> Date: 8/12/16 1:07 PM (GMT-08:00)
>>>> To: Jamil Nimeh <jamil.j.nimeh at oracle.com>, Security Dev OpenJDK
>>>> <security-dev at openjdk.java.net>
>>>> Subject: Re: [9] RFR: 8162484:
>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails
>>>> intermittently with "Address already in use" error
>>>>
>>>> No problem.
>>>>
>>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.02/
>>>>
>>>> Artem
>>>>
>>>>
>>>> On 08/12/2016 12:02 PM, Jamil Nimeh wrote:
>>>>> For the tests as we use them today we don't intend the server to
>>>>> restart.  The intent of SimpleOCSPServer was to be of use for a
>>>>> variety of testing purposes.  I don't know that we can say for all
>>>>> intended uses that we'll *never* need to restart it. That's why I'd
>>>>> like to keep the unbound socket/set sockopt/bind/listen behavior.  I
>>>>> don't think ServerSocket(0) achieves that.
>>>>>
>>>>> --Jamil
>>>>>
>>>>> On 8/12/2016 11:30 AM, Artem Smotrakov wrote:
>>>>>> Hi Jamil,
>>>>>>
>>>>>> There was no any specific reason to remove ServerSocket.bind() call.
>>>>>> ServerSocket(0) constructor creates a server socket, automatically
>>>>>> bound to a random free port. If I am not missing something, it
>>>>>> doesn't look necessary to set the SO_REUSEADDR socket options if the
>>>>>> server is not going to restart. The code is just shorter if we use
>>>>>> ServerSocket(0) constructor to open a server socket, but I can revert
>>>>>> it to use bind() with 0 port number if you think it's better.
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>>
>>>>>> On 08/12/2016 09:13 AM, Jamil Nimeh wrote:
>>>>>>> Hi Artem, more comments in-line
>>>>>>>
>>>>>>>
>>>>>>> On 8/11/2016 11:46 AM, Artem Smotrakov wrote:
>>>>>>>> Hi Jamil,
>>>>>>>>
>>>>>>>> Thank you for review. Please see inline.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/10/2016 04:16 PM, Jamil Nimeh wrote:
>>>>>>>>> Hi Artem,
>>>>>>>>>
>>>>>>>>> I'm not an official reviewer but the solution for making the
>>>>>>>>> servers reject connections rather than stop and start looks pretty
>>>>>>>>> fair to me and seems like a nice way to simulate a downed OCSP
>>>>>>>>> responder instead of having to bounce it.  A couple
>>>>>>>>> comments/questions:
>>>>>>>>>
>>>>>>>>> I'm a bit surprised that you get the "Address already in use"
>>>>>>>>> error though.
>>>>>>>> Well, to be honest, I was not able to reproduce this failure
>>>>>>>> locally. I was running the test in a loop for a couple of days, and
>>>>>>>> it didn't fail. But the test has been observed to fail in other
>>>>>>>> test runs (jprt, CI, etc).
>>>>>>>>
>>>>>>>> I am not an expert in networking, and I would appreciate if someone
>>>>>>>> more knowledgeable gives an advise how these intermittent failures
>>>>>>>> can be avoided.
>>>>>>>>
>>>>>>>>> Isn't servSocket.setReuseAddress(true) on line 214 supposed to set
>>>>>>>>> the SO_REUSEADDR at the system call level and prevent EADDRINUSE
>>>>>>>>> when listening or binding?
>>>>>>>> If I am not missing something, the test has been observed to fails
>>>>>>>> while re-binding. I am wondering if it's possible that the port
>>>>>>>> becomes busy after the server socket was closed, but before bind()
>>>>>>>> is called again. The probability of this situation seems to be very
>>>>>>>> low which has been actually seen - the test fails very rare.
>>>>>>>>
>>>>>>>> If this is the case, it seems like servSocket.setReuseAddress(true)
>>>>>>>> doesn't help because the port is taken by another process (I am not
>>>>>>>> sure that SO_REUSEADDR prevents from this). Again, this is only my
>>>>>>>> guess, and I may be wrong.
>>>>>>> You know, I hadn't thought of that.  I've never been able to
>>>>>>> reproduce that problem either, but I'm running on a local virtual
>>>>>>> box VM on a laptop, and usually the tests are running sequentially.
>>>>>>> I could definitely see the case where other processes are soaking up
>>>>>>> the OCSP responder's port.  With those tests, I kind of need the
>>>>>>> port to remain the same since I'm putting that server and port in
>>>>>>> the AIA extensions of the certs for which it answers.  Given this
>>>>>>> particular case, it seems like your solution of keeping the server
>>>>>>> bound but just chopping connections off is the best way to go.
>>>>>>>>> When you create the new ServerSocket on line 212, you're now
>>>>>>>>> binding it to the port now where originally it started as an
>>>>>>>>> unbound socket.  By doing so, the behavior of setReuseAddress() on
>>>>>>>>> line 214 is now undefined.
>>>>>>>> This setReuseAddress() call looks unnecessary now. I'll update the
>>>>>>>> test.
>>>>>>>>> While this test no longer stops/starts the server, other tests may
>>>>>>>>> wish to do so and their behavior may not be consistent (though
>>>>>>>>> apparently it wasn't consistent even in the old scheme where the
>>>>>>>>> socket was unbound, then setReuseAddress() was called...)
>>>>>>>> Correct. I checked other code which depend on SimpleOCSPServer
>>>>>>>>
>>>>>>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>>>>>>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>>>>>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>>>>>>>> javax/net/ssl/Stapling/StapleEnableProps.java
>>>>>>>>
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java
>>>>
>>>>
>>>>>>>>
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java
>>>>
>>>>
>>>>>>>> artem at artem-laptop:~/ws/jdk/jdk9_dev_stapling_test/jdk/test$ kate
>>>>>>>> javax/net/ssl/Stapling/HttpsUrlConnClient.java
>>>>>>>> javax/net/ssl/Stapling/SSLEngineWithStapling.java
>>>>>>>> javax/net/ssl/Stapling/SSLSocketWithStapling.java
>>>>>>>> javax/net/ssl/Stapling/StapleEnableProps.java
>>>>>>>>
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusReqSelection.java
>>>>
>>>>
>>>> sun/security/ssl/StatusStapling/java.base/sun/security/ssl/StatusResponseManagerTests.java
>>>>
>>>>
>>>>>>>>
>>>>>>>> These tests call stop() only once when actual testcases are done.
>>>>>>>> Actually, some of them don't even call stop(), but it seems to work
>>>>>>>> fine. As an enhancement, I would add stop() calls to finally
>>>>>>>> blocks, but it seems to work fine without it anyway.
>>>>>>> I liked your solution with the stop() calls in finally blocks and I
>>>>>>> agree that they should have them.  I think we get away with it
>>>>>>> because in most if not all of those cases they are running as
>>>>>>> othervm tests (because we have properties that we set specific to
>>>>>>> the tests).  So when the JVM exits resources like sockets are closed
>>>>>>> by the OS.  Still, it's better to have the try/finally guards and
>>>>>>> explicitly and gracefully shutdown the OCSP responders.
>>>>>>>> Here is an updated webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~asmotrak/8162484/webrev.01/
>>>>>>> I realize that in many of these test cases we're going to move away
>>>>>>> from a start/stop approach to your accept/reject one, but in general
>>>>>>> sockets designed to be listening should start unbound, set the
>>>>>>> SO_REUSEADDR sockopt, then bind and listen. Was there a specific
>>>>>>> reason to change that code, or was it just to streamline it?  Aside
>>>>>>> from fewer lines of code, I'm not sure what it buys us.
>>>>>>>> Artem
>>>>>>>>
>>>>>>>>
>>>>>>>>> --Jamil
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08/10/2016 03:44 PM, Artem Smotrakov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review this update for OCSP stapling tests.
>>>>>>>>>>
>>>>>>>>>> The tests use
>>>>>>>>>> test/java/security/testlibrary/SimpleOCSPServer.java which try to
>>>>>>>>>> re-use a server port if the server restarted. Looks like
>>>>>>>>>> sometimes it may cause "Address already in use" error.
>>>>>>>>>>
>>>>>>>>>> The patch updates OCSP stapling tests with the following:
>>>>>>>>>> - updated SSLSocketWithStapling.java test not to restart OCSP
>>>>>>>>>> responders
>>>>>>>>>> - updated SimpleOCSPServer to be able to reject incoming
>>>> connections
>>>>>>>>>> - updated SimpleOCSPServer to be able to reproduce a delay
>>>>>>>>>> without restarting
>>>>>>>>>>
>>>>>>>>>> Jamil,
>>>>>>>>>>
>>>>>>>>>> Could you please take a look at this update, and confirm if this
>>>>>>>>>> update doesn't break the original test scenarios?
>>>>>>>>>>
>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162484
>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~asmotrak/8162484/webrev.00/
>>>>>>>>>>
>>>>>>>>>> Artem
> 



From xuelei.fan at oracle.com  Mon Aug 15 23:57:26 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 16 Aug 2016 07:57:26 +0800
Subject: RFR: 8164052 Fix legal notices in JDK tests
In-Reply-To: <B8A645DA-88E2-4CE3-A2E6-B48AEAA2190C@oracle.com>
References: <B8A645DA-88E2-4CE3-A2E6-B48AEAA2190C@oracle.com>
Message-ID: <75b34d1c-de47-e43c-47e3-f80258e268e0@oracle.com>

CC security-dev.

The security part looks fine to me.

Thanks,
Xuelei

On 8/16/2016 2:39 AM, Alexandre (Shura) Iline wrote:
> Hi,
> 
> Please review this bulk update of JDK test sources which is fixing legal notices formatting and content.
> 
> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/
> 
> I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository.
> 
> Shura
> 



From li.jiang at oracle.com  Mon Aug  8 08:59:14 2016
From: li.jiang at oracle.com (Leo Jiang)
Date: Mon, 8 Aug 2016 16:59:14 +0800
Subject: RFR 8163303: Remove identity scope information from jarsigner
	-verbose output
In-Reply-To: <f84c78ee-3687-a6b7-4120-12a0515017e2@oracle.com>
References: <f84c78ee-3687-a6b7-4120-12a0515017e2@oracle.com>
Message-ID: <9fd222ac-b891-9329-81b0-da800c6c061d@oracle.com>

The change of L10n resource files looks good from L10n perspective.

Thanks,
Leo

On 08/08/2016 03:28 PM, Weijun Wang wrote:
> Hi All
>
> Please review the code change at
>
>    http://cr.openjdk.java.net/~weijun/8163303/webrev.00
>
> I removed the "@SuppressWarnings("deprecation")" at the beginning. I think this has been unnecessary for quite a while
> since calls to deprecated classes (ContentSigner and ContentSignerParameters) have been moved to the new JarSigner API.
>
> *Leo*: I take the chance to update localized Resourses.java files for Japanese and Chinese, since this is only about
> removing items. Please confirm this is OK.
>
> Thanks
> Max


From weijun.wang at oracle.com  Tue Aug 16 06:10:21 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 16 Aug 2016 14:10:21 +0800
Subject: RFR 8141411: keytool can wrongly parse the start date value given by
	the -startdate option
Message-ID: <53a6c6c6-5c45-4334-2ab8-19802e064bb4@oracle.com>

Please review the fix for this embarrassing bug:

    http://cr.openjdk.java.net/~weijun/8141411/webrev.00

Thanks
Max


From xuelei.fan at oracle.com  Tue Aug 16 08:44:34 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 16 Aug 2016 16:44:34 +0800
Subject: RFR 8141411: keytool can wrongly parse the start date value given
	by the -startdate option
In-Reply-To: <53a6c6c6-5c45-4334-2ab8-19802e064bb4@oracle.com>
References: <53a6c6c6-5c45-4334-2ab8-19802e064bb4@oracle.com>
Message-ID: <bb03c963-7631-45d5-74d5-e1d59055b98c@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 8/16/2016 2:10 PM, Weijun Wang wrote:
> Please review the fix for this embarrassing bug:
> 
>    http://cr.openjdk.java.net/~weijun/8141411/webrev.00
> 
> Thanks
> Max



From ivan.gerasimov at oracle.com  Tue Aug 16 12:56:41 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 16 Aug 2016 15:56:41 +0300
Subject: PING - [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart
	card" popup windows
In-Reply-To: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>
References: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>
Message-ID: <beb09678-d3c5-ffb1-bfb2-2ceace2027ed@oracle.com>

A gentle reminder.

Would you please help review at your convenience.

With kind regards,
Ivan


On 09.08.2016 12:27, Ivan Gerasimov wrote:
> Hello!
>
> In order to reduce the number of popup dialog windows during accessing 
> the smartcard, it is proposed to first do a silent "probe" step.
> Only if this probe succeeded, or if it failed due to that SILENT flag, 
> we'll try to re-acquire the key normally (i.e. not silently).
>
> Would you please help review this proposal?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153438
> WEBREV: http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/
>
> With kind regards,
> Ivan
>
>



From vincent.x.ryan at oracle.com  Tue Aug 16 13:27:20 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Tue, 16 Aug 2016 14:27:20 +0100
Subject: PING - [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart
	card" popup windows
In-Reply-To: <beb09678-d3c5-ffb1-bfb2-2ceace2027ed@oracle.com>
References: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>
	<beb09678-d3c5-ffb1-bfb2-2ceace2027ed@oracle.com>
Message-ID: <1A59DF96-4E31-4738-A70F-E499793879BF@oracle.com>

That fix looks fine. Is there any significant performance impact due to calling CryptAcquireCertificatePrivateKey twice?
Thanks.

> On 16 Aug 2016, at 13:56, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> A gentle reminder.
> 
> Would you please help review at your convenience.
> 
> With kind regards,
> Ivan
> 
> 
> On 09.08.2016 12:27, Ivan Gerasimov wrote:
>> Hello!
>> 
>> In order to reduce the number of popup dialog windows during accessing the smartcard, it is proposed to first do a silent "probe" step.
>> Only if this probe succeeded, or if it failed due to that SILENT flag, we'll try to re-acquire the key normally (i.e. not silently).
>> 
>> Would you please help review this proposal?
>> 
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153438
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/
>> 
>> With kind regards,
>> Ivan
>> 
>> 
> 



From weijun.wang at oracle.com  Tue Aug 16 15:52:07 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 16 Aug 2016 23:52:07 +0800
Subject: RFR 8087144/8153146: sun/security/krb5/auto/MaxRetries.java fails
Message-ID: <4a645b15-be96-841e-a4ae-409b8fec58ca@oracle.com>

Please take a review at

   http://cr.openjdk.java.net/~weijun/8087144/webrev.00/

for

    8087144: sun/security/krb5/auto/MaxRetries.java fails with Retry 
count is -1 less
    8153146: sun/security/krb5/auto/MaxRetries.java failed with timeout

The test fails because a timeout happens on a real KDC. If a retry is 
permitted, this retry is treated as unexpected (8087144), otherwise, a 
timeout exception is thrown (8153146).

The rewritten test does not always pursue for a single correct result. 
Instead, it encodes the test output into a string, and compares it to 
both an ideal exact result (real KDC never timeout) or a relaxed one 
(real KDC could timeout once for a while) and succeeds if either 
matches. The relaxed result is a regular expression.

Before this change, the stability of the test is guaranteed (although 
not successfully) by using a big timeout value (say, 5 seconds). Now 
that we have the relaxed match, I am thinking it can be smaller. The 
current code change uses BadKdc.setRatio() to change the effective 
timeout value to 1 second. The test execution time is reduced from 180s 
to 30s on my machine.

If the test still fails intermittently, maybe the relaxed match is not 
relaxed enough, or I should set a higher ratio. Let's wait and see.

Thanks
Max


From alexandre.iline at oracle.com  Tue Aug 16 17:17:27 2016
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 16 Aug 2016 10:17:27 -0700
Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests
Message-ID: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>

Hi.

Please review fixes related to module dependencies in a few jdk tests:
http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/index.html

The review contains a few cases where jdk.zipfs is added to the module list. This is happening because all TestNG tests which use compiler API require jdk.zipfs to be able to read the testng jar. This is unfortunate but there is no easy way around that. 

Shura





From valerie.peng at oracle.com  Tue Aug 16 19:18:45 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 16 Aug 2016 12:18:45 -0700
Subject: PING - [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart
	card" popup windows
In-Reply-To: <1A59DF96-4E31-4738-A70F-E499793879BF@oracle.com>
References: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>
	<beb09678-d3c5-ffb1-bfb2-2ceace2027ed@oracle.com>
	<1A59DF96-4E31-4738-A70F-E499793879BF@oracle.com>
Message-ID: <24339fa6-9f25-0863-6fff-3eca3d97e65b@oracle.com>


I am not familiar with the general behavior of 
CryptAcquireCertificatePrivateKey API.

Would the first CryptAcquireCertificatePrivateKey(.., 
CRYPT_ACQUIRE_SILENT_FLAG, ...) ever return TRUE?
If yes, then do we need to release the context and call 
CryptAcquireCertificatePrivateKey(..) again?

I'd expect the overall logic to be something like:

    if (::CryptAcquireCertificatePrivateKey(pCertContext,
    CRYPT_ACQUIRE_SILENT_FLAG, NULL,&hCryptProv, &dwKeySpec,
    &bCallerFreeProv) == FALSE) { if (GetLastError() ==
    NTE_SILENT_CONTEXT) { // Try acquiring the key normally (not
    silently)if (::CryptAcquireCertificatePrivateKey(pCertContext, 0,
    NULL, &hCryptProv, &dwKeySpec, &bCallerFreeProv) == FALSE)
    {bHasNoPrivateKey = TRUE;   } } else { bHasNoPrivateKey = TRUE; } }
    // Then proceed on different code paths based on bHasNoPrivateKey value


Anything that I missed?
Valerie

On 8/16/2016 6:27 AM, Vincent Ryan wrote:
> That fix looks fine. Is there any significant performance impact due to calling CryptAcquireCertificatePrivateKey twice?
> Thanks.
>
>> On 16 Aug 2016, at 13:56, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> A gentle reminder.
>>
>> Would you please help review at your convenience.
>>
>> With kind regards,
>> Ivan
>>
>>
>> On 09.08.2016 12:27, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> In order to reduce the number of popup dialog windows during accessing the smartcard, it is proposed to first do a silent "probe" step.
>>> Only if this probe succeeded, or if it failed due to that SILENT flag, we'll try to re-acquire the key normally (i.e. not silently).
>>>
>>> Would you please help review this proposal?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153438
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/
>>>
>>> With kind regards,
>>> Ivan
>>>
>>>

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

From ivan.gerasimov at oracle.com  Tue Aug 16 20:06:21 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 16 Aug 2016 23:06:21 +0300
Subject: PING - [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart
	card" popup windows
In-Reply-To: <24339fa6-9f25-0863-6fff-3eca3d97e65b@oracle.com>
References: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>
	<beb09678-d3c5-ffb1-bfb2-2ceace2027ed@oracle.com>
	<1A59DF96-4E31-4738-A70F-E499793879BF@oracle.com>
	<24339fa6-9f25-0863-6fff-3eca3d97e65b@oracle.com>
Message-ID: <f3c9a092-d151-2864-f40b-2c1b30bd33d0@oracle.com>

Thank you Valerie for looking into this!


On 16.08.2016 22:18, Valerie Peng wrote:
>
>
> I am not familiar with the general behavior of 
> CryptAcquireCertificatePrivateKey API.
>
> Would the first CryptAcquireCertificatePrivateKey(.., 
> CRYPT_ACQUIRE_SILENT_FLAG, ...) ever return TRUE?

Yes.  It returns TRUE if the key could be acquired silently, and I've 
seen this happening.

> If yes, then do we need to release the context and call 
> CryptAcquireCertificatePrivateKey(..) again?
>
> I'd expect the overall logic to be something like:
>
>     if (::CryptAcquireCertificatePrivateKey(pCertContext,
>     CRYPT_ACQUIRE_SILENT_FLAG, NULL,&hCryptProv, &dwKeySpec,
>     &bCallerFreeProv) == FALSE) { if (GetLastError() ==
>     NTE_SILENT_CONTEXT) { // Try acquiring the key normally (not
>     silently)if (::CryptAcquireCertificatePrivateKey(pCertContext, 0,
>     NULL, &hCryptProv, &dwKeySpec, &bCallerFreeProv) == FALSE)
>     {bHasNoPrivateKey = TRUE;   } } else { bHasNoPrivateKey = TRUE; }
>     } // Then proceed on different code paths based on
>     bHasNoPrivateKey value
>
This was the first thing I attempted to do.
However, some subsequent operations with the key started to fail, 
throwing SignatureException (with the message "Provider could not 
perform the action since the context was acquired as silent.")

That's why I switched to what is in this proposal: Silent probing and 
then re-acquiring the key normally (not silently).

With kind regards,
Ivan

> Anything that I missed?
> Valerie
>
> On 8/16/2016 6:27 AM, Vincent Ryan wrote:
>> That fix looks fine. Is there any significant performance impact due to calling CryptAcquireCertificatePrivateKey twice?
>> Thanks.
>>
>>> On 16 Aug 2016, at 13:56, Ivan Gerasimov<ivan.gerasimov at oracle.com>  wrote:
>>>
>>> A gentle reminder.
>>>
>>> Would you please help review at your convenience.
>>>
>>> With kind regards,
>>> Ivan
>>>
>>>
>>> On 09.08.2016 12:27, Ivan Gerasimov wrote:
>>>> Hello!
>>>>
>>>> In order to reduce the number of popup dialog windows during accessing the smartcard, it is proposed to first do a silent "probe" step.
>>>> Only if this probe succeeded, or if it failed due to that SILENT flag, we'll try to re-acquire the key normally (i.e. not silently).
>>>>
>>>> Would you please help review this proposal?
>>>>
>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8153438
>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/
>>>>
>>>> With kind regards,
>>>> Ivan
>>>>
>>>>
>

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

From ivan.gerasimov at oracle.com  Tue Aug 16 20:25:08 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 16 Aug 2016 23:25:08 +0300
Subject: PING - [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart
	card" popup windows
In-Reply-To: <1A59DF96-4E31-4738-A70F-E499793879BF@oracle.com>
References: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>
	<beb09678-d3c5-ffb1-bfb2-2ceace2027ed@oracle.com>
	<1A59DF96-4E31-4738-A70F-E499793879BF@oracle.com>
Message-ID: <19781d99-2424-c0cb-56d5-a8b4cf4f8292@oracle.com>

Thank you Vincent!


On 16.08.2016 16:27, Vincent Ryan wrote:
> That fix looks fine. Is there any significant performance impact due to calling CryptAcquireCertificatePrivateKey twice?
One of the intermittent attempts of implementing this enhancement was to 
also get the handle to the private key (CryptGetUserKey), using the 
silently acquired provider.
And only if *that* succeeded, we treated the probe successful and tried 
to re-acquire the key normally.

However, that approach really introduced a significant slowdown 
(approximately x2 times).

On the other hand, with the proposed variant, the slowdown isn't 
noticeable by eye, but it surely will be worthwhile to do some benchmarking.

With kind regards,
Ivan

> Thanks.
>
>> On 16 Aug 2016, at 13:56, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> A gentle reminder.
>>
>> Would you please help review at your convenience.
>>
>> With kind regards,
>> Ivan
>>
>>
>> On 09.08.2016 12:27, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> In order to reduce the number of popup dialog windows during accessing the smartcard, it is proposed to first do a silent "probe" step.
>>> Only if this probe succeeded, or if it failed due to that SILENT flag, we'll try to re-acquire the key normally (i.e. not silently).
>>>
>>> Would you please help review this proposal?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8153438
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/
>>>
>>> With kind regards,
>>> Ivan
>>>
>>>
>



From valerie.peng at oracle.com  Tue Aug 16 22:25:59 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 16 Aug 2016 15:25:59 -0700
Subject: PING - [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart
	card" popup windows
In-Reply-To: <f3c9a092-d151-2864-f40b-2c1b30bd33d0@oracle.com>
References: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>
	<beb09678-d3c5-ffb1-bfb2-2ceace2027ed@oracle.com>
	<1A59DF96-4E31-4738-A70F-E499793879BF@oracle.com>
	<24339fa6-9f25-0863-6fff-3eca3d97e65b@oracle.com>
	<f3c9a092-d151-2864-f40b-2c1b30bd33d0@oracle.com>
Message-ID: <edac6af3-05a9-6d03-bb34-9bb7ee82b31a@oracle.com>

Hmm, interesting...

So, if the first call succeeded and you release the context and re-try. 
Does the popup window show up for the second call?
Just curious.

Changes look fine.
Valerie
On 8/16/2016 1:06 PM, Ivan Gerasimov wrote:
>
> Thank you Valerie for looking into this!
>
>
> On 16.08.2016 22:18, Valerie Peng wrote:
>>
>>
>> I am not familiar with the general behavior of 
>> CryptAcquireCertificatePrivateKey API.
>>
>> Would the first CryptAcquireCertificatePrivateKey(.., 
>> CRYPT_ACQUIRE_SILENT_FLAG, ...) ever return TRUE?
>
> Yes.  It returns TRUE if the key could be acquired silently, and I've 
> seen this happening.
>
>> If yes, then do we need to release the context and call 
>> CryptAcquireCertificatePrivateKey(..) again?
>>
>> I'd expect the overall logic to be something like:
>>
>>     if (::CryptAcquireCertificatePrivateKey(pCertContext,
>>     CRYPT_ACQUIRE_SILENT_FLAG, NULL,&hCryptProv, &dwKeySpec,
>>     &bCallerFreeProv) == FALSE) { if (GetLastError() ==
>>     NTE_SILENT_CONTEXT) { // Try acquiring the key normally (not
>>     silently)if (::CryptAcquireCertificatePrivateKey(pCertContext, 0,
>>     NULL, &hCryptProv, &dwKeySpec, &bCallerFreeProv) == FALSE)
>>     {bHasNoPrivateKey = TRUE;   } } else { bHasNoPrivateKey = TRUE; }
>>     } // Then proceed on different code paths based on
>>     bHasNoPrivateKey value
>>
> This was the first thing I attempted to do.
> However, some subsequent operations with the key started to fail, 
> throwing SignatureException (with the message "Provider could not 
> perform the action since the context was acquired as silent.")
>
> That's why I switched to what is in this proposal: Silent probing and 
> then re-acquiring the key normally (not silently).
>
> With kind regards,
> Ivan
>
>> Anything that I missed?
>> Valerie
>>
>> On 8/16/2016 6:27 AM, Vincent Ryan wrote:
>>> That fix looks fine. Is there any significant performance impact due to calling CryptAcquireCertificatePrivateKey twice?
>>> Thanks.
>>>
>>>> On 16 Aug 2016, at 13:56, Ivan Gerasimov<ivan.gerasimov at oracle.com>  wrote:
>>>>
>>>> A gentle reminder.
>>>>
>>>> Would you please help review at your convenience.
>>>>
>>>> With kind regards,
>>>> Ivan
>>>>
>>>>
>>>> On 09.08.2016 12:27, Ivan Gerasimov wrote:
>>>>> Hello!
>>>>>
>>>>> In order to reduce the number of popup dialog windows during accessing the smartcard, it is proposed to first do a silent "probe" step.
>>>>> Only if this probe succeeded, or if it failed due to that SILENT flag, we'll try to re-acquire the key normally (i.e. not silently).
>>>>>
>>>>> Would you please help review this proposal?
>>>>>
>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8153438
>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/
>>>>>
>>>>> With kind regards,
>>>>> Ivan
>>>>>
>>>>>
>>
>

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

From weijun.wang at oracle.com  Wed Aug 17 00:30:53 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 17 Aug 2016 08:30:53 +0800
Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests
In-Reply-To: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>
References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>
Message-ID: <3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com>

Hi Shura

I am looking at test/jdk/security/jarsigner/Spec.java.

IMHO, even on a Solaris, without the SunPKCS11 provider at runtime, this 
test should be able to find Signature and MessageDigest implementations 
from the SunRsaSign and SUN provider.

Is the new @modules dependency necessary? In fact, I am curious how you 
note this test. Does it fail with some special settings?

Thanks
Max

On 8/17/2016 1:17, Alexandre (Shura) Iline wrote:
> Hi.
>
> Please review fixes related to module dependencies in a few jdk tests:
> http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/index.html
>
> The review contains a few cases where jdk.zipfs is added to the module list. This is happening because all TestNG tests which use compiler API require jdk.zipfs to be able to read the testng jar. This is unfortunate but there is no easy way around that.
>
> Shura
>
>
>


From valerie.peng at oracle.com  Wed Aug 17 01:24:26 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 16 Aug 2016 18:24:26 -0700
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
Message-ID: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>


Anyone has time to review a straightforward fix? The current PKCS11 code 
assume that if public exponent is available for RSA Private Key, then 
it's a RSA CRT key. However, not all vendor implementation works this 
way. Changing to a tighter check and did minor code-refactoring to avoid 
re-retrieving the attribute values.

Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/

Thanks,
Valerie


From alexandre.iline at oracle.com  Wed Aug 17 01:26:26 2016
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Tue, 16 Aug 2016 18:26:26 -0700
Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests
In-Reply-To: <3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com>
References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>
	<3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com>
Message-ID: <D8B0F5A2-1024-4B5D-88AC-8E58DCDF1A72@oracle.com>

Hi, Max.

Excerpt from JTReg documentation:
=========================================================================================================
@modules <module>[/<package>]+
Express a dependence on a modules in the system being tested, and optionally, on selected internal packages in some or all of those modules.

If no dependencies are specified explicitly, a default set of dependencies will be read from the modules entry in test suite configuration files.

A test will not be run if the system being tested does not contain all of the specified modules.

Note: Specifying an entry that includes a dependence on an internal package is essentially equivalent to using -XaddExports:<module>/<package>ALL-UNNAMED when the test is compiled and run.
=========================================================================================================


Before the suggested fix, the test in question would fail on a system with no jdk.crypto.pkcs11. That could be emulated by:
$ jtreg ... -javaoptions:"-limitmods jdk.jartool" jdk/security/jarsigner/Spec.java
...
FAILED: jdk/security/jarsigner/Spec.java
...
$ jtreg ... -javaoptions:"-limitmods jdk.jartool,jdk.crypto.pkcs11" jdk/security/jarsigner/Spec.java
...
Passed: jdk/security/jarsigner/Spec.java
...
$ 

With my fix, the test will not be selected for execution when there is no jdk.crypto.pkcs11:
$ jtreg ... -javaoptions:"-limitmods jdk.jartool" jdk/security/jarsigner/Spec.java
...
Test results: no tests selected
?
$

Shura



> On Aug 16, 2016, at 5:30 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Hi Shura
> 
> I am looking at test/jdk/security/jarsigner/Spec.java.
> 
> IMHO, even on a Solaris, without the SunPKCS11 provider at runtime, this test should be able to find Signature and MessageDigest implementations from the SunRsaSign and SUN provider.
> 
> Is the new @modules dependency necessary? In fact, I am curious how you note this test. Does it fail with some special settings?
> 
> Thanks
> Max
> 
> On 8/17/2016 1:17, Alexandre (Shura) Iline wrote:
>> Hi.
>> 
>> Please review fixes related to module dependencies in a few jdk tests:
>> http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/index.html
>> 
>> The review contains a few cases where jdk.zipfs is added to the module list. This is happening because all TestNG tests which use compiler API require jdk.zipfs to be able to read the testng jar. This is unfortunate but there is no easy way around that.
>> 
>> Shura
>> 
>> 
>> 



From Xuelei.Fan at Oracle.COM  Wed Aug 17 01:28:45 2016
From: Xuelei.Fan at Oracle.COM (Xuelei Fan)
Date: Wed, 17 Aug 2016 09:28:45 +0800
Subject: RFR 8087144/8153146: sun/security/krb5/auto/MaxRetries.java fails
In-Reply-To: <4a645b15-be96-841e-a4ae-409b8fec58ca@oracle.com>
References: <4a645b15-be96-841e-a4ae-409b8fec58ca@oracle.com>
Message-ID: <57B3BDCD.1060806@Oracle.COM>

Looks fine to me.

Xuelei

On 8/16/2016 11:52 PM, Weijun Wang wrote:
> Please take a review at
>
>    http://cr.openjdk.java.net/~weijun/8087144/webrev.00/
>
> for
>
>     8087144: sun/security/krb5/auto/MaxRetries.java fails with Retry
> count is -1 less
>     8153146: sun/security/krb5/auto/MaxRetries.java failed with timeout
>
> The test fails because a timeout happens on a real KDC. If a retry is
> permitted, this retry is treated as unexpected (8087144), otherwise, a
> timeout exception is thrown (8153146).
>
> The rewritten test does not always pursue for a single correct result.
> Instead, it encodes the test output into a string, and compares it to
> both an ideal exact result (real KDC never timeout) or a relaxed one
> (real KDC could timeout once for a while) and succeeds if either
> matches. The relaxed result is a regular expression.
>
> Before this change, the stability of the test is guaranteed (although
> not successfully) by using a big timeout value (say, 5 seconds). Now
> that we have the relaxed match, I am thinking it can be smaller. The
> current code change uses BadKdc.setRatio() to change the effective
> timeout value to 1 second. The test execution time is reduced from 180s
> to 30s on my machine.
>
> If the test still fails intermittently, maybe the relaxed match is not
> relaxed enough, or I should set a higher ratio. Let's wait and see.
>
> Thanks
> Max



From weijun.wang at oracle.com  Wed Aug 17 01:48:52 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 17 Aug 2016 09:48:52 +0800
Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests
In-Reply-To: <D8B0F5A2-1024-4B5D-88AC-8E58DCDF1A72@oracle.com>
References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>
	<3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com>
	<D8B0F5A2-1024-4B5D-88AC-8E58DCDF1A72@oracle.com>
Message-ID: <8D77C9ED-BA5E-4F94-BE2D-C73E418C666F@oracle.com>


> On Aug 17, 2016, at 9:26 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> Before the suggested fix, the test in question would fail on a system with no jdk.crypto.pkcs11. That could be emulated by:
> $ jtreg ... -javaoptions:"-limitmods jdk.jartool" jdk/security/jarsigner/Spec.java
> ...
> FAILED: jdk/security/jarsigner/Spec.java
> ...
> $ jtreg ... -javaoptions:"-limitmods jdk.jartool,jdk.crypto.pkcs11" jdk/security/jarsigner/Spec.java
> ...
> Passed: jdk/security/jarsigner/Spec.java
> ...
> $ 

Thanks very much for the detailed answer.

Just a small suggestion: Can you try using jdk.crypto.ec module instead? It also provides all EC-related algorithms and it is available and loaded out-of-box on all platforms?

--Max



From ivan.gerasimov at oracle.com  Wed Aug 17 10:48:47 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 17 Aug 2016 13:48:47 +0300
Subject: PING - [jdk9] RFR: 8153438: Avoid repeated "Please insert a smart
	card" popup windows
In-Reply-To: <edac6af3-05a9-6d03-bb34-9bb7ee82b31a@oracle.com>
References: <1b997be1-1d49-f477-b687-afe32b1563f5@oracle.com>
	<beb09678-d3c5-ffb1-bfb2-2ceace2027ed@oracle.com>
	<1A59DF96-4E31-4738-A70F-E499793879BF@oracle.com>
	<24339fa6-9f25-0863-6fff-3eca3d97e65b@oracle.com>
	<f3c9a092-d151-2864-f40b-2c1b30bd33d0@oracle.com>
	<edac6af3-05a9-6d03-bb34-9bb7ee82b31a@oracle.com>
Message-ID: <f5b4d5b5-807e-cb84-933d-63465f8e1800@oracle.com>

Hi Valerie!


On 17.08.2016 1:25, Valerie Peng wrote:
>
> Hmm, interesting...
>
> So, if the first call succeeded and you release the context and 
> re-try. Does the popup window show up for the second call?
> Just curious.
>
I assume that CryptAcquireCertificatePrivateKey() only displays the UI 
when necessary, so if the context could be acquired silently (i.e. the 
result is TRUE), it will be possible to acquire it with no UI and 
without explicit SILENT flag.

With kind regards,
Ivan

> Changes look fine.
> Valerie
> On 8/16/2016 1:06 PM, Ivan Gerasimov wrote:
>>
>> Thank you Valerie for looking into this!
>>
>>
>> On 16.08.2016 22:18, Valerie Peng wrote:
>>>
>>>
>>> I am not familiar with the general behavior of 
>>> CryptAcquireCertificatePrivateKey API.
>>>
>>> Would the first CryptAcquireCertificatePrivateKey(.., 
>>> CRYPT_ACQUIRE_SILENT_FLAG, ...) ever return TRUE?
>>
>> Yes.  It returns TRUE if the key could be acquired silently, and I've 
>> seen this happening.
>>
>>> If yes, then do we need to release the context and call 
>>> CryptAcquireCertificatePrivateKey(..) again?
>>>
>>> I'd expect the overall logic to be something like:
>>>
>>>     if (::CryptAcquireCertificatePrivateKey(pCertContext,
>>>     CRYPT_ACQUIRE_SILENT_FLAG, NULL,&hCryptProv, &dwKeySpec,
>>>     &bCallerFreeProv) == FALSE) { if (GetLastError() ==
>>>     NTE_SILENT_CONTEXT) { // Try acquiring the key normally (not
>>>     silently)if (::CryptAcquireCertificatePrivateKey(pCertContext,
>>>     0, NULL, &hCryptProv, &dwKeySpec, &bCallerFreeProv) == FALSE)
>>>     {bHasNoPrivateKey = TRUE;   } } else { bHasNoPrivateKey = TRUE;
>>>     } } // Then proceed on different code paths based on
>>>     bHasNoPrivateKey value
>>>
>> This was the first thing I attempted to do.
>> However, some subsequent operations with the key started to fail, 
>> throwing SignatureException (with the message "Provider could not 
>> perform the action since the context was acquired as silent.")
>>
>> That's why I switched to what is in this proposal: Silent probing and 
>> then re-acquiring the key normally (not silently).
>>
>> With kind regards,
>> Ivan
>>
>>> Anything that I missed?
>>> Valerie
>>>
>>> On 8/16/2016 6:27 AM, Vincent Ryan wrote:
>>>> That fix looks fine. Is there any significant performance impact due to calling CryptAcquireCertificatePrivateKey twice?
>>>> Thanks.
>>>>
>>>>> On 16 Aug 2016, at 13:56, Ivan Gerasimov<ivan.gerasimov at oracle.com>  wrote:
>>>>>
>>>>> A gentle reminder.
>>>>>
>>>>> Would you please help review at your convenience.
>>>>>
>>>>> With kind regards,
>>>>> Ivan
>>>>>
>>>>>
>>>>> On 09.08.2016 12:27, Ivan Gerasimov wrote:
>>>>>> Hello!
>>>>>>
>>>>>> In order to reduce the number of popup dialog windows during accessing the smartcard, it is proposed to first do a silent "probe" step.
>>>>>> Only if this probe succeeded, or if it failed due to that SILENT flag, we'll try to re-acquire the key normally (i.e. not silently).
>>>>>>
>>>>>> Would you please help review this proposal?
>>>>>>
>>>>>> BUGURL:https://bugs.openjdk.java.net/browse/JDK-8153438
>>>>>> WEBREV:http://cr.openjdk.java.net/~igerasim/8153438/00/webrev/
>>>>>>
>>>>>> With kind regards,
>>>>>> Ivan
>>>>>>
>>>>>>
>>>
>>
>

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

From vincent.x.ryan at oracle.com  Wed Aug 17 11:10:40 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Wed, 17 Aug 2016 12:10:40 +0100
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
Message-ID: <C52487A8-1E07-48FC-B48B-5EADE648CB48@oracle.com>

Your fix looks good to me.
Thanks.

> On 17 Aug 2016, at 02:24, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> 
> Anyone has time to review a straightforward fix? The current PKCS11 code assume that if public exponent is available for RSA Private Key, then it's a RSA CRT key. However, not all vendor implementation works this way. Changing to a tighter check and did minor code-refactoring to avoid re-retrieving the attribute values.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
> 
> Thanks,
> Valerie



From sean.mullan at oracle.com  Wed Aug 17 16:18:49 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 17 Aug 2016 12:18:49 -0400
Subject: RFR: 8164071: Default.policy file missing content for solaris
Message-ID: <c15f1ea2-5890-c98f-2d57-17b75395528d@oracle.com>

Please review this simple fix to append the solaris default.policy file 
to the overall default.policy file.

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

diff -r 551f7617b2c0 make/copy/Copy-java.base.gmk
--- a/make/copy/Copy-java.base.gmk	Wed Aug 17 10:08:18 2016 +0800
+++ b/make/copy/Copy-java.base.gmk	Wed Aug 17 12:17:19 2016 -0400
@@ -185,6 +185,8 @@

  ifeq ($(OPENJDK_TARGET_OS), windows)
    DEF_POLICY_SRC_LIST += 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy
+else ifeq ($(OPENJDK_TARGET_OS), solaris)
+  DEF_POLICY_SRC_LIST += 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy 

  endif

  # Allow imported modules to modify the java.policy


Thanks,
Sean


From erik.joelsson at oracle.com  Wed Aug 17 16:33:52 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 Aug 2016 18:33:52 +0200
Subject: RFR: 8164071: Default.policy file missing content for solaris
In-Reply-To: <c15f1ea2-5890-c98f-2d57-17b75395528d@oracle.com>
References: <c15f1ea2-5890-c98f-2d57-17b75395528d@oracle.com>
Message-ID: <7c8dae94-4f67-d176-c39e-22f1cc12aa6a@oracle.com>

Hello Sean,

The change looks ok, but it could also be expressed like this to avoid 
duplication:

ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), )
   DEF_POLICY_SRC_LIST += $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy
endif


/Erik

On 2016-08-17 18:18, Sean Mullan wrote:
> Please review this simple fix to append the solaris default.policy 
> file to the overall default.policy file.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164071
>
> diff -r 551f7617b2c0 make/copy/Copy-java.base.gmk
> --- a/make/copy/Copy-java.base.gmk    Wed Aug 17 10:08:18 2016 +0800
> +++ b/make/copy/Copy-java.base.gmk    Wed Aug 17 12:17:19 2016 -0400
> @@ -185,6 +185,8 @@
>
>  ifeq ($(OPENJDK_TARGET_OS), windows)
>    DEF_POLICY_SRC_LIST += 
> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy
> +else ifeq ($(OPENJDK_TARGET_OS), solaris)
> +  DEF_POLICY_SRC_LIST += 
> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy 
>
>  endif
>
>  # Allow imported modules to modify the java.policy
>
>
> Thanks,
> Sean



From alexandre.iline at oracle.com  Wed Aug 17 16:40:58 2016
From: alexandre.iline at oracle.com (Alexandre (Shura) Iline)
Date: Wed, 17 Aug 2016 09:40:58 -0700
Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests
In-Reply-To: <8D77C9ED-BA5E-4F94-BE2D-C73E418C666F@oracle.com>
References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>
	<3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com>
	<D8B0F5A2-1024-4B5D-88AC-8E58DCDF1A72@oracle.com>
	<8D77C9ED-BA5E-4F94-BE2D-C73E418C666F@oracle.com>
Message-ID: <4371BA82-A2A1-4AC5-8477-F46A589F52E3@oracle.com>

Thank you!

Fixed in place:
http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/test/jdk/security/jarsigner/Spec.java.sdiff.html

Shura

> On Aug 16, 2016, at 6:48 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> 
>> On Aug 17, 2016, at 9:26 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>> 
>> Before the suggested fix, the test in question would fail on a system with no jdk.crypto.pkcs11. That could be emulated by:
>> $ jtreg ... -javaoptions:"-limitmods jdk.jartool" jdk/security/jarsigner/Spec.java
>> ...
>> FAILED: jdk/security/jarsigner/Spec.java
>> ...
>> $ jtreg ... -javaoptions:"-limitmods jdk.jartool,jdk.crypto.pkcs11" jdk/security/jarsigner/Spec.java
>> ...
>> Passed: jdk/security/jarsigner/Spec.java
>> ...
>> $ 
> 
> Thanks very much for the detailed answer.
> 
> Just a small suggestion: Can you try using jdk.crypto.ec module instead? It also provides all EC-related algorithms and it is available and loaded out-of-box on all platforms?
> 
> --Max
> 



From sean.mullan at oracle.com  Wed Aug 17 16:43:46 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 17 Aug 2016 12:43:46 -0400
Subject: RFR: 8164071: Default.policy file missing content for solaris
In-Reply-To: <7c8dae94-4f67-d176-c39e-22f1cc12aa6a@oracle.com>
References: <c15f1ea2-5890-c98f-2d57-17b75395528d@oracle.com>
	<7c8dae94-4f67-d176-c39e-22f1cc12aa6a@oracle.com>
Message-ID: <57B49442.6090406@oracle.com>


On 8/17/2016 12:33 PM, Erik Joelsson wrote:
> Hello Sean,
>
> The change looks ok, but it could also be expressed like this to avoid 
> duplication:
>
> ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), )
>   DEF_POLICY_SRC_LIST += 
> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy
> endif
Thanks. However, shouldn't that be "ifeq" and not "ifneq"?

--Sean
>
>
> /Erik
>
> On 2016-08-17 18:18, Sean Mullan wrote:
>> Please review this simple fix to append the solaris default.policy 
>> file to the overall default.policy file.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164071
>>
>> diff -r 551f7617b2c0 make/copy/Copy-java.base.gmk
>> --- a/make/copy/Copy-java.base.gmk    Wed Aug 17 10:08:18 2016 +0800
>> +++ b/make/copy/Copy-java.base.gmk    Wed Aug 17 12:17:19 2016 -0400
>> @@ -185,6 +185,8 @@
>>
>>  ifeq ($(OPENJDK_TARGET_OS), windows)
>>    DEF_POLICY_SRC_LIST += 
>> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy
>> +else ifeq ($(OPENJDK_TARGET_OS), solaris)
>> +  DEF_POLICY_SRC_LIST += 
>> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy 
>>
>>  endif
>>
>>  # Allow imported modules to modify the java.policy
>>
>>
>> Thanks,
>> Sean
>



From erik.joelsson at oracle.com  Wed Aug 17 16:48:52 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 17 Aug 2016 18:48:52 +0200
Subject: RFR: 8164071: Default.policy file missing content for solaris
In-Reply-To: <57B49442.6090406@oracle.com>
References: <c15f1ea2-5890-c98f-2d57-17b75395528d@oracle.com>
	<7c8dae94-4f67-d176-c39e-22f1cc12aa6a@oracle.com>
	<57B49442.6090406@oracle.com>
Message-ID: <a348a263-9428-3606-f939-1f9b4a5a9909@oracle.com>

On 2016-08-17 18:43, Sean Mullan wrote:
>
> On 8/17/2016 12:33 PM, Erik Joelsson wrote:
>> Hello Sean,
>>
>> The change looks ok, but it could also be expressed like this to 
>> avoid duplication:
>>
>> ifneq ($(filter $(OPENJDK_TARGET_OS), windows solaris), )
>>   DEF_POLICY_SRC_LIST += 
>> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy
>> endif
> Thanks. However, shouldn't that be "ifeq" and not "ifneq"?
>
Actually no, if OPENJDK_TARGET_OS is either windows or solaris, the 
filter function will return exactly that, otherwise it will return 
empty. The if(n)eq compares the result of filter to the empty string. 
This construct is a bit convoluted but is our standard construct for 
this situation.

/Erik
> --Sean
>>
>>
>> /Erik
>>
>> On 2016-08-17 18:18, Sean Mullan wrote:
>>> Please review this simple fix to append the solaris default.policy 
>>> file to the overall default.policy file.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164071
>>>
>>> diff -r 551f7617b2c0 make/copy/Copy-java.base.gmk
>>> --- a/make/copy/Copy-java.base.gmk    Wed Aug 17 10:08:18 2016 +0800
>>> +++ b/make/copy/Copy-java.base.gmk    Wed Aug 17 12:17:19 2016 -0400
>>> @@ -185,6 +185,8 @@
>>>
>>>  ifeq ($(OPENJDK_TARGET_OS), windows)
>>>    DEF_POLICY_SRC_LIST += 
>>> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy
>>> +else ifeq ($(OPENJDK_TARGET_OS), solaris)
>>> +  DEF_POLICY_SRC_LIST += 
>>> $(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/lib/security/default.policy 
>>>
>>>  endif
>>>
>>>  # Allow imported modules to modify the java.policy
>>>
>>>
>>> Thanks,
>>> Sean
>>
>



From sean.coffey at oracle.com  Wed Aug 17 16:53:47 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 17 Aug 2016 17:53:47 +0100
Subject: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java fails
Message-ID: <57B4969B.4030904@oracle.com>

A recently added test case lacks sufficient permissions to read a conf 
file when running with security manager.

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

proposed patch :
  diff --git a/test/sun/security/krb5/auto/unbound.ssl.policy 
b/test/sun/security/krb5/auto/unbound.ssl.policy
--- a/test/sun/security/krb5/auto/unbound.ssl.policy
+++ b/test/sun/security/krb5/auto/unbound.ssl.policy
@@ -1,7 +1,13 @@
+// Standard extensions get all permissions by default
+
+grant codeBase "file:${{java.ext.dirs}}/*" {
+        permission java.security.AllPermission;
+};
+
  grant {
      permission java.util.PropertyPermission "*", "read,write";
      permission java.net.SocketPermission "*:*", 
"listen,resolve,accept,connect";
-    permission java.io.FilePermission "*", "read,write,delete";
+    permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete";
      permission java.lang.RuntimePermission "accessDeclaredMembers";
      permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
      permission java.lang.RuntimePermission "accessClassInPackage.*";

-- 
Regards,
Sean.



From mstjohns at comcast.net  Wed Aug 17 16:55:09 2016
From: mstjohns at comcast.net (Michael StJohns)
Date: Wed, 17 Aug 2016 12:55:09 -0400
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
Message-ID: <d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>

On 8/16/2016 9:24 PM, Valerie Peng wrote:
>
> Anyone has time to review a straightforward fix? The current PKCS11 
> code assume that if public exponent is available for RSA Private Key, 
> then it's a RSA CRT key. However, not all vendor implementation works 
> this way. Changing to a tighter check and did minor code-refactoring 
> to avoid re-retrieving the attribute values.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
>
> Thanks,
> Valerie

Given that there's a change to PKCS11 for 2.40 that says that all RSA 
private key objects  MUST also store CKA_PUBLIC_EXPONENT, some change 
needed to be made.

Sorry - I don't think this fix will work.  Or if its working on your 
version of PKCS11, your version of PKCS11 is doing it wrong. The problem 
is that if you specify attributes that don't exist on the object, the 
underlying PKCS11 library is supposed to return 
CKR_ATTRIBUTE_TYPE_INVALID.  And that should trigger a thrown exception 
before you ever get anything copied to your attributes.

1) Get modulus and private exponent first.  That gives you the stuff for 
a generic RSA private key - and if it fails, there's no reason to continue.

2) Then get the rest of the stuff.  If that fails, then you already have 
the stuff you need for a normal private key.


>                       boolean crtKey;
>                       try {
>                           session.token.p11.C_GetAttributeValue
>                               (session.id(), keyID, attrs2);
> - crtKey = (attrs2[0].pValue instanceof byte[]);
> + crtKey = ((attrs2[1].pValue instanceof byte[]) &&
> + (attrs2[3].pValue instanceof byte[]) &&
> + (attrs2[4].pValue instanceof byte[]) &&
> + (attrs2[5].pValue instanceof byte[]) &&
> + (attrs2[6].pValue instanceof byte[]) &&
> + (attrs2[7].pValue instanceof byte[])) ;
>                       } catch (PKCS11Exception e) {
>                           // ignore, assume not available
>                           crtKey = false;
>                       }

// Change attrs2 so it only has the additional CRT attributes (e.g. 
delete CKA_MODULUS, CKA_PRIVATE_EXPONENT from the list

Replace the above with

CK_ATTRIBUTE[] attrs3 = new CK_ATTRIBUTE[] {
        new CK_ATTRIBUTE(CKA_MODULUS),
        new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT)
};
// no try block needed here - we want to throw the error if it occurs
session.token.p11.C_GetAttributeValue (session.id(), keyID, attrs3);

// So far so good - we have the base attributes, let's see if we can get 
the additional attributes;

try {
     session.token.p11.C_GetAttributeValue(session.id(),keyID, attrs2);
} catch (PKCS11Exception e) {
    // we really should check the return value for one of the non-fatal 
values, but let's just assume its not a CRT key
    return new P11RSAPrivateNonCRTKey (session, keyID, algorithm, 
keyLength, attrs2, attrs3);
}

// if we fall through then its a CRT key
// -- we should check for byte[] ness of each of the components, and 
throw an error if they arent - but which error?

return new P11RSAPrivateKey (session, keyID, algorithm, keyLength, 
attrs2, attrs3);

// there are cleanups necessary in other places.  I'd suggest rather 
than depending on the ordering of attributes, you do assignment by CKA_ 
values just so someone coming later doesn't mess things up by mistake.  
Also, a hell of a lot more readable.

static CK_ATTRIBUTE getAttribute (CK_ATTRIBUTE[] attrs, long attrType) {
     for (CK_ATTRIBUTE a : attrs) {
          if (a.type == attrType)
               return a;
      }
     return null; // or throw something?
}


coeff = getAtttribute(attrs,CKA_COEFFICIENT).getBigInteger();


The other possibility is to change the C code for C_GetAttributeValues 
so it doesn't error out for the non-fatal error codes and instead 
returns a null value attribute when the attribute is missing.

Mike

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

From artem.smotrakov at oracle.com  Wed Aug 17 17:10:41 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 17 Aug 2016 10:10:41 -0700
Subject: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java
	fails
In-Reply-To: <57B4969B.4030904@oracle.com>
References: <57B4969B.4030904@oracle.com>
Message-ID: <0ee91f5b-bcd5-7c93-d99d-13c00797d8f3@oracle.com>

Hi Sean,

If I remember correctly, there is no ext directory in JDK 9 any more.

I don't see in jtr file that "java.ext.dirs" system property is passed 
to the test. If I understand correctly, "file:${{java.ext.dirs}}/*" 
becomes "file:/*" which seems to grand all permissions to all the code. 
It doesn't look correct for this test.

It looks like the test overrides the default policy, please see in jtr file

-Djava.security.policy==/export/home/gtee/scripts/Results/workDir/scratch_2/unbound.ssl.policy_new 
\\

If I recall correctly, there should be a way to specify a policy file in 
@run without overriding the default one. May be it is "@run 
main/othervm/java.security.policy=unbound.ssl.policy_new"

Artem


On 08/17/2016 09:53 AM, Se?n Coffey wrote:
> A recently added test case lacks sufficient permissions to read a conf 
> file when running with security manager.
>
> bug report : https://bugs.openjdk.java.net/browse/JDK-8162916
>
> proposed patch :
>  diff --git a/test/sun/security/krb5/auto/unbound.ssl.policy 
> b/test/sun/security/krb5/auto/unbound.ssl.policy
> --- a/test/sun/security/krb5/auto/unbound.ssl.policy
> +++ b/test/sun/security/krb5/auto/unbound.ssl.policy
> @@ -1,7 +1,13 @@
> +// Standard extensions get all permissions by default
> +
> +grant codeBase "file:${{java.ext.dirs}}/*" {
> +        permission java.security.AllPermission;
> +};
> +
>  grant {
>      permission java.util.PropertyPermission "*", "read,write";
>      permission java.net.SocketPermission "*:*", 
> "listen,resolve,accept,connect";
> -    permission java.io.FilePermission "*", "read,write,delete";
> +    permission java.io.FilePermission "<<ALL FILES>>", 
> "read,write,delete";
>      permission java.lang.RuntimePermission "accessDeclaredMembers";
>      permission java.lang.reflect.ReflectPermission 
> "suppressAccessChecks";
>      permission java.lang.RuntimePermission "accessClassInPackage.*";
>



From sean.coffey at oracle.com  Wed Aug 17 17:12:56 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 17 Aug 2016 18:12:56 +0100
Subject: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java
	fails
In-Reply-To: <0ee91f5b-bcd5-7c93-d99d-13c00797d8f3@oracle.com>
References: <57B4969B.4030904@oracle.com>
	<0ee91f5b-bcd5-7c93-d99d-13c00797d8f3@oracle.com>
Message-ID: <57B49B18.3030505@oracle.com>

Hi Artem,

Sorry - should have said that this is for jdk8u-dev. The bug is marked 
9-na. The provider loading changes made in this area for 9 mean that 
it's not affected.

Regards,
Sean.

On 17/08/16 18:10, Artem Smotrakov wrote:
> Hi Sean,
>
> If I remember correctly, there is no ext directory in JDK 9 any more.
>
> I don't see in jtr file that "java.ext.dirs" system property is passed 
> to the test. If I understand correctly, "file:${{java.ext.dirs}}/*" 
> becomes "file:/*" which seems to grand all permissions to all the 
> code. It doesn't look correct for this test.
>
> It looks like the test overrides the default policy, please see in jtr 
> file
>
> -Djava.security.policy==/export/home/gtee/scripts/Results/workDir/scratch_2/unbound.ssl.policy_new 
> \\
>
> If I recall correctly, there should be a way to specify a policy file 
> in @run without overriding the default one. May be it is "@run 
> main/othervm/java.security.policy=unbound.ssl.policy_new"
>
> Artem
>
>
> On 08/17/2016 09:53 AM, Se?n Coffey wrote:
>> A recently added test case lacks sufficient permissions to read a 
>> conf file when running with security manager.
>>
>> bug report : https://bugs.openjdk.java.net/browse/JDK-8162916
>>
>> proposed patch :
>>  diff --git a/test/sun/security/krb5/auto/unbound.ssl.policy 
>> b/test/sun/security/krb5/auto/unbound.ssl.policy
>> --- a/test/sun/security/krb5/auto/unbound.ssl.policy
>> +++ b/test/sun/security/krb5/auto/unbound.ssl.policy
>> @@ -1,7 +1,13 @@
>> +// Standard extensions get all permissions by default
>> +
>> +grant codeBase "file:${{java.ext.dirs}}/*" {
>> +        permission java.security.AllPermission;
>> +};
>> +
>>  grant {
>>      permission java.util.PropertyPermission "*", "read,write";
>>      permission java.net.SocketPermission "*:*", 
>> "listen,resolve,accept,connect";
>> -    permission java.io.FilePermission "*", "read,write,delete";
>> +    permission java.io.FilePermission "<<ALL FILES>>", 
>> "read,write,delete";
>>      permission java.lang.RuntimePermission "accessDeclaredMembers";
>>      permission java.lang.reflect.ReflectPermission 
>> "suppressAccessChecks";
>>      permission java.lang.RuntimePermission "accessClassInPackage.*";
>>
>



From artem.smotrakov at oracle.com  Wed Aug 17 17:18:48 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 17 Aug 2016 10:18:48 -0700
Subject: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java
	fails
In-Reply-To: <57B49B18.3030505@oracle.com>
References: <57B4969B.4030904@oracle.com>
	<0ee91f5b-bcd5-7c93-d99d-13c00797d8f3@oracle.com>
	<57B49B18.3030505@oracle.com>
Message-ID: <27699872-c744-7ae6-249b-c3562c5a882e@oracle.com>

Sorry, my bad, I didn't notice '9-na' label.

I suppose that code from ext directory should have all permissions:

artem at artem-laptop:$ cat ~/jdk/jdk1.8.0_92b14/jre/lib/security/java.policy

// Standard extensions get all permissions by default

grant codeBase "file:${{java.ext.dirs}}/*" {
         permission java.security.AllPermission;
};

// default permissions granted to all domains
...

I am wondering if it would be better it the test didn't override the 
default policy.

Artem

On 08/17/2016 10:12 AM, Se?n Coffey wrote:
> Hi Artem,
>
> Sorry - should have said that this is for jdk8u-dev. The bug is marked 
> 9-na. The provider loading changes made in this area for 9 mean that 
> it's not affected.
>
> Regards,
> Sean.
>
> On 17/08/16 18:10, Artem Smotrakov wrote:
>> Hi Sean,
>>
>> If I remember correctly, there is no ext directory in JDK 9 any more.
>>
>> I don't see in jtr file that "java.ext.dirs" system property is 
>> passed to the test. If I understand correctly, 
>> "file:${{java.ext.dirs}}/*" becomes "file:/*" which seems to grand 
>> all permissions to all the code. It doesn't look correct for this test.
>>
>> It looks like the test overrides the default policy, please see in 
>> jtr file
>>
>> -Djava.security.policy==/export/home/gtee/scripts/Results/workDir/scratch_2/unbound.ssl.policy_new 
>> \\
>>
>> If I recall correctly, there should be a way to specify a policy file 
>> in @run without overriding the default one. May be it is "@run 
>> main/othervm/java.security.policy=unbound.ssl.policy_new"
>>
>> Artem
>>
>>
>> On 08/17/2016 09:53 AM, Se?n Coffey wrote:
>>> A recently added test case lacks sufficient permissions to read a 
>>> conf file when running with security manager.
>>>
>>> bug report : https://bugs.openjdk.java.net/browse/JDK-8162916
>>>
>>> proposed patch :
>>>  diff --git a/test/sun/security/krb5/auto/unbound.ssl.policy 
>>> b/test/sun/security/krb5/auto/unbound.ssl.policy
>>> --- a/test/sun/security/krb5/auto/unbound.ssl.policy
>>> +++ b/test/sun/security/krb5/auto/unbound.ssl.policy
>>> @@ -1,7 +1,13 @@
>>> +// Standard extensions get all permissions by default
>>> +
>>> +grant codeBase "file:${{java.ext.dirs}}/*" {
>>> +        permission java.security.AllPermission;
>>> +};
>>> +
>>>  grant {
>>>      permission java.util.PropertyPermission "*", "read,write";
>>>      permission java.net.SocketPermission "*:*", 
>>> "listen,resolve,accept,connect";
>>> -    permission java.io.FilePermission "*", "read,write,delete";
>>> +    permission java.io.FilePermission "<<ALL FILES>>", 
>>> "read,write,delete";
>>>      permission java.lang.RuntimePermission "accessDeclaredMembers";
>>>      permission java.lang.reflect.ReflectPermission 
>>> "suppressAccessChecks";
>>>      permission java.lang.RuntimePermission "accessClassInPackage.*";
>>>
>>
>



From rajan.halade at oracle.com  Wed Aug 17 17:54:31 2016
From: rajan.halade at oracle.com (Rajan Halade)
Date: Wed, 17 Aug 2016 10:54:31 -0700
Subject: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in
	jdk_security3 group
Message-ID: <191bdeb1-a52d-ac36-e331-64eebd060b2d@oracle.com>

sun/net/www/protocol/https tests are redundant in jdk_security3 group, 
these are included in jdk_net group.

Webrev: http://cr.openjdk.java.net/~rhalade/8164229/webrev.00/

Thanks,
Rajan


From artem.smotrakov at oracle.com  Wed Aug 17 18:29:23 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 17 Aug 2016 11:29:23 -0700
Subject: [9] RFR: 8164100:
	com/sun/crypto/provider/KeyFactory/TestProviderLeak.java fails with
	java.util.concurrent.TimeoutException
Message-ID: <177be901-0377-a912-6ee4-2684e31e710a@oracle.com>

Hello,

Please review the following patch for 
com/sun/crypto/provider/KeyFactory/TestProviderLeak.java test.

This is a request to make the test take into account a test timeout 
factor. Timeout factor can be specified with "-timeout" jtreg's command 
line option. This option is used in some test runs to make test runs 
more stable (for example, VM SQE uses it while running regression tests 
with different JVM options).

Bug: https://bugs.openjdk.java.net/browse/JDK-8164100
Webrev: http://cr.openjdk.java.net/~asmotrak/8164100/webrev.00/

Artem


From chris.hegarty at oracle.com  Wed Aug 17 18:36:49 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 17 Aug 2016 19:36:49 +0100
Subject: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in
	jdk_security3 group
In-Reply-To: <191bdeb1-a52d-ac36-e331-64eebd060b2d@oracle.com>
References: <191bdeb1-a52d-ac36-e331-64eebd060b2d@oracle.com>
Message-ID: <BE42DCBC-D278-42D3-A1B0-076AFBC56D54@oracle.com>

On 17 Aug 2016, at 18:54, Rajan Halade <rajan.halade at oracle.com> wrote:
> 
> sun/net/www/protocol/https tests are redundant in jdk_security3 group, these are included in jdk_net group.

Yes they are, but it is very important that anyone touching TLS verify
that HTTPS still works. If the jdk_net tests will be run to verity
such changes, then this should be fine.

Out of curiosity, how many tests are in sun/net/www/protocol/https,
and approximately how long do they run for? 

-Chris.



From bradford.wetmore at oracle.com  Wed Aug 17 18:52:16 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 17 Aug 2016 11:52:16 -0700
Subject: [9] RFR 6877937: The SunJCE PBKDF2KeyImpl is requiring the MAC
	instance also be from SunJCE.
In-Reply-To: <75EC098D-BE36-410D-AE23-D7BC75021283@oracle.com>
References: <75EC098D-BE36-410D-AE23-D7BC75021283@oracle.com>
Message-ID: <c668bd80-e32c-d113-4d78-6d81377722f7@oracle.com>

Looks ok, probably better than the initial proposed fix from April 2014.

Brad




On 8/11/2016 4:55 AM, Vincent Ryan wrote:
> Please review this change to unpin the Mac implementation from the
> SunJCE provider.
> Since the Mac is a private field there are no issues
> regarding Clonable implementations for Mac or its MessageDigest.
> Thanks.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6977937
>
> *diff --git
> a/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
> b/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java*
> *---
> a/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java*
> *+++
> b/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java*
> @@ -107,7 +107,7 @@
>              throw new InvalidKeySpecException("Key length is negative");
>          }
>          try {
> -            this.prf = Mac.getInstance(prfAlgo, SunJCE.getInstance());
> +            this.prf = Mac.getInstance(prfAlgo);
>          } catch (NoSuchAlgorithmException nsae) {
>              // not gonna happen; re-throw just in case
>              InvalidKeySpecException ike = new InvalidKeySpecException();


From rajan.halade at oracle.com  Wed Aug 17 18:52:26 2016
From: rajan.halade at oracle.com (Rajan Halade)
Date: Wed, 17 Aug 2016 11:52:26 -0700
Subject: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in
	jdk_security3 group
In-Reply-To: <BE42DCBC-D278-42D3-A1B0-076AFBC56D54@oracle.com>
References: <191bdeb1-a52d-ac36-e331-64eebd060b2d@oracle.com>
	<BE42DCBC-D278-42D3-A1B0-076AFBC56D54@oracle.com>
Message-ID: <c71f748e-a557-bb64-5fec-72c6e78c1ff2@oracle.com>

On 8/17/16 11:36 AM, Chris Hegarty wrote:

> On 17 Aug 2016, at 18:54, Rajan Halade <rajan.halade at oracle.com> wrote:
>> sun/net/www/protocol/https tests are redundant in jdk_security3 group, these are included in jdk_net group.
> Yes they are, but it is very important that anyone touching TLS verify
> that HTTPS still works. If the jdk_net tests will be run to verity
> such changes, then this should be fine.
Yes, these are useful tests to run with https changes. I don't think 
they need to be duplicated in jdk_security group as jdk_security and 
jdk_net are part of core tests and with continuous integration system in 
place to run all tests with each changeset, this duplication is not 
required.
>
> Out of curiosity, how many tests are in sun/net/www/protocol/https,
> and approximately how long do they run for?
There are 27 tests and I see each of those finish within seconds (max I 
saw was 8 secs for ReadTimeout.java).

Thanks,
Rajan
>
> -Chris.
>



From anthony.scarpino at oracle.com  Wed Aug 17 20:11:46 2016
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 17 Aug 2016 13:11:46 -0700
Subject: RFR: 8156192: Provider#compute and #merge methods expect wrong
	permission & #compute ClassCastException even with wrong permission.
Message-ID: <57B4C502.7000106@oracle.com>

Hi,

I need a simple review on fixing some cut-n-paste errors that the JCK 
tests found.

I didn't include the tests because the functionality is covered by the 
JCK tests and I don't feel typos need a regression test.

http://cr.openjdk.java.net/~ascarpino/8156192/webrev/

Tony



From sean.mullan at oracle.com  Wed Aug 17 20:47:58 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 17 Aug 2016 16:47:58 -0400
Subject: RFR: 8156192: Provider#compute and #merge methods expect wrong
	permission & #compute ClassCastException even with wrong permission.
In-Reply-To: <57B4C502.7000106@oracle.com>
References: <57B4C502.7000106@oracle.com>
Message-ID: <673529b2-f7d7-2596-7d9f-e4113164c50b@oracle.com>

Looks fine to me.

--Sean

On 08/17/2016 04:11 PM, Anthony Scarpino wrote:
> Hi,
>
> I need a simple review on fixing some cut-n-paste errors that the JCK
> tests found.
>
> I didn't include the tests because the functionality is covered by the
> JCK tests and I don't feel typos need a regression test.
>
> http://cr.openjdk.java.net/~ascarpino/8156192/webrev/
>
> Tony
>


From anthony.scarpino at oracle.com  Wed Aug 17 20:48:41 2016
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 17 Aug 2016 13:48:41 -0700
Subject: RFR: 8156192: Provider#compute and #merge methods expect wrong
	permission & #compute ClassCastException even with wrong permission.
In-Reply-To: <673529b2-f7d7-2596-7d9f-e4113164c50b@oracle.com>
References: <57B4C502.7000106@oracle.com>
	<673529b2-f7d7-2596-7d9f-e4113164c50b@oracle.com>
Message-ID: <57B4CDA9.9080801@oracle.com>

Thanks

Tony

On 08/17/2016 01:47 PM, Sean Mullan wrote:
> Looks fine to me.
>
> --Sean
>
> On 08/17/2016 04:11 PM, Anthony Scarpino wrote:
>> Hi,
>>
>> I need a simple review on fixing some cut-n-paste errors that the JCK
>> tests found.
>>
>> I didn't include the tests because the functionality is covered by the
>> JCK tests and I don't feel typos need a regression test.
>>
>> http://cr.openjdk.java.net/~ascarpino/8156192/webrev/
>>
>> Tony
>>



From bradford.wetmore at oracle.com  Wed Aug 17 23:22:58 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 17 Aug 2016 16:22:58 -0700
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
Message-ID: <2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>

New webrev:

https://bugs.openjdk.java.net/browse/JDK-8061842
http://cr.openjdk.java.net/~wetmore/8061842/webrev.01/

On 8/10/2016 11:19 AM, Sean Mullan wrote:
> Hi Brad,
>
> Looks pretty good. You should also send this to build-dev to review the
> Makefile changes. Just a few comments:
>
> - src/java.base/share/conf/security/policy/README.txt
>
> 17 contain no restrictions on cryptographic strengths, but they must
>
> s/must/must be/

Ok.

> 18 specifically activated by updating the "crypto.policy" entry in the
>
> s/entry/Security property/

Ok.  I've updated to:

---begin---
specifically activated by updating the "crypto.policy" Security property
(e.g. <java-home>/conf/security/java.security) to point to the 
appropriate directory.
----end---

> 33 Please see The Java(TM) Cryptography Architecture (JCA) Reference
>
> Is "TM" really necessary here?

It was required in previous versions of the unlimited crypto policy 
bundle.  We could run it by PM if you feel we should.

> src/java.base/share/conf/security/policy/unlimited/default_US_export.policy
>
> 1 // Manufacturing policy file.
>
> The term "Manufacturing" is odd. Can we just say this is the "Default
> local policy file"?

Sure.

> - src/java.base/share/conf/security/java.security
>
> 854 crypto.policy=policydir-tbd
>
> The policydir-tbd value is a little confusing in that it isn't a real
> value. What about just setting this to the empty string?

It's a similar marker for the string replacement like was done for 
security.provider.tbd.  I could change it to be delineated with <>: 
"<policydir-tbd>" if you like?

> - src/java.base/share/classes/javax/crypto/JceSecurity.java
>
>  255         String cryptoPolicyDir =
> Security.getProperty("crypto.policy");
>  256         Path cryptoPolicyPath = Paths.get(cryptoPolicyDir);
>
> What happens if crypto.policy is not set or is set to ""?

Good catch.  Not set would NPE, "" would simply look at 
<java-home>/conf/security/policy and fail to iterate the directory if no 
files were actually there.  I've added code for both those conditions, 
and also switched to use Path.resolve().

> 302             // I/O error encounted during the iteration,
>
> s/encounted/encountered/

Thanks!

Brad


> --Sean
>
> On 08/04/2016 03:35 PM, Bradford Wetmore wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8061842
>> http://cr.openjdk.java.net/~wetmore/8061842/webrev.00/
>>
>> The proposal is to move the configuration files from the jar files in
>> <java-home>/lib/security to a series of subdirectories under a new
>> "policy" subdirectory in <java-home>/conf/security.  Each subdirectory
>> within that directory will represent a complete policy configuration.
>> The existing jar files will be split into flat text files such that the
>> current/existing policies remain.
>>
>> The default set of policy files (i.e. directory) is configured using a
>> new java.security.Security property called "crypto.policy" which will be
>> added to the <java-home>/conf/security/java.security file.  The default
>> initial options are "limited" or "unlimited", however additional
>> directories could potentially be created that specify other
>> as-yet-unknown policies.
>>
>> The default value of this property will be "limited" which corresponds
>> to our current policy for JRE/JDK export/import around the world.
>> However, the build respects the following "configure" option:
>>
>>     --enable-unlimited-crypto
>>                         Enable unlimited crypto policy [disabled]
>>
>> Within the directory, our implementation will look for files using the
>> standard filename prefix above ("default_" or "exempt_"), thus new
>> additional policy restrictions/abstractions can be added with a simple
>> file addition.
>>
>> Brad
>>


From valerie.peng at oracle.com  Thu Aug 18 02:31:10 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 17 Aug 2016 19:31:10 -0700
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
	<d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
Message-ID: <12ea9fa0-b166-ad89-17cc-80dcb40865f0@oracle.com>


Thanks for the input.
SunPKCS11 provider always generate RSA CRT keys if I recall correctly, 
so it's hard to test the non-CRT scenarios. Thus, I made the changes 
basing on the suggestions in the bug report.

I will update the webrev accordingly.
Valerie

On 8/17/2016 9:55 AM, Michael StJohns wrote:
> On 8/16/2016 9:24 PM, Valerie Peng wrote:
>>
>> Anyone has time to review a straightforward fix? The current PKCS11 
>> code assume that if public exponent is available for RSA Private Key, 
>> then it's a RSA CRT key. However, not all vendor implementation works 
>> this way. Changing to a tighter check and did minor code-refactoring 
>> to avoid re-retrieving the attribute values.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
>> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
>>
>> Thanks,
>> Valerie
>
> Given that there's a change to PKCS11 for 2.40 that says that all RSA 
> private key objects  MUST also store CKA_PUBLIC_EXPONENT, some change 
> needed to be made.
>
> Sorry - I don't think this fix will work.  Or if its working on your 
> version of PKCS11, your version of PKCS11 is doing it wrong.  The 
> problem is that if you specify attributes that don't exist on the 
> object, the underlying PKCS11 library is supposed to return 
> CKR_ATTRIBUTE_TYPE_INVALID.  And that should trigger a thrown 
> exception before you ever get anything copied to your attributes.
>
> 1) Get modulus and private exponent first.  That gives you the stuff 
> for a generic RSA private key - and if it fails, there's no reason to 
> continue.
>
> 2) Then get the rest of the stuff.  If that fails, then you already 
> have the stuff you need for a normal private key.
>
>
>>                       boolean crtKey;
>>                       try {
>>                           session.token.p11.C_GetAttributeValue
>>                               (session.id(), keyID, attrs2);
>> - crtKey = (attrs2[0].pValue instanceof byte[]);
>> + crtKey = ((attrs2[1].pValue instanceof byte[]) &&
>> + (attrs2[3].pValue instanceof byte[]) &&
>> + (attrs2[4].pValue instanceof byte[]) &&
>> + (attrs2[5].pValue instanceof byte[]) &&
>> + (attrs2[6].pValue instanceof byte[]) &&
>> + (attrs2[7].pValue instanceof byte[])) ;
>>                       } catch (PKCS11Exception e) {
>>                           // ignore, assume not available
>>                           crtKey = false;
>>                       }
>
> // Change attrs2 so it only has the additional CRT attributes (e.g. 
> delete CKA_MODULUS, CKA_PRIVATE_EXPONENT from the list
>
> Replace the above with
>
> CK_ATTRIBUTE[] attrs3 = new CK_ATTRIBUTE[] {
>        new CK_ATTRIBUTE(CKA_MODULUS),
>        new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT)
> };
> // no try block needed here - we want to throw the error if it occurs
> session.token.p11.C_GetAttributeValue (session.id(), keyID, attrs3);
>
> // So far so good - we have the base attributes, let's see if we can 
> get the additional attributes;
>
> try {
>     session.token.p11.C_GetAttributeValue(session.id(),keyID, attrs2);
> } catch (PKCS11Exception e) {
>    // we really should check the return value for one of the non-fatal 
> values, but let's just assume its not a CRT key
>    return new P11RSAPrivateNonCRTKey (session, keyID, algorithm, 
> keyLength, attrs2, attrs3);
> }
>
> // if we fall through then its a CRT key
> // -- we should check for byte[] ness of each of the components, and 
> throw an error if they arent - but which error?
>
> return new P11RSAPrivateKey (session, keyID, algorithm, keyLength, 
> attrs2, attrs3);
>
> // there are cleanups necessary in other places.  I'd suggest rather 
> than depending on the ordering of attributes, you do assignment by 
> CKA_ values just so someone coming later doesn't mess things up by 
> mistake.  Also, a hell of a lot more readable.
>
> static CK_ATTRIBUTE getAttribute (CK_ATTRIBUTE[] attrs, long attrType) {
>     for (CK_ATTRIBUTE a : attrs) {
>          if (a.type == attrType)
>               return a;
>      }
>     return null; // or throw something?
> }
>
>
> coeff = getAtttribute(attrs,CKA_COEFFICIENT).getBigInteger();
>
>
> The other possibility is to change the C code for C_GetAttributeValues 
> so it doesn't error out for the non-fatal error codes and instead 
> returns a null value attribute when the attribute is missing.
>
> Mike
>

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

From weijun.wang at oracle.com  Thu Aug 18 03:11:16 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 18 Aug 2016 11:11:16 +0800
Subject: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java
	fails
In-Reply-To: <27699872-c744-7ae6-249b-c3562c5a882e@oracle.com>
References: <57B4969B.4030904@oracle.com>
	<0ee91f5b-bcd5-7c93-d99d-13c00797d8f3@oracle.com>
	<57B49B18.3030505@oracle.com>
	<27699872-c744-7ae6-249b-c3562c5a882e@oracle.com>
Message-ID: <dff2b1b9-72aa-7c6e-fe27-bb8b1112967e@oracle.com>

>>> If I recall correctly, there should be a way to specify a policy file
>>> in @run without overriding the default one. May be it is "@run
>>> main/othervm/java.security.policy=unbound.ssl.policy_new"

Yes, I think this should work. I've also just learned about it and don't 
know from which jtreg it is supported. Hopefully the minimized-required 
version of jtreg for jdk8u already has it.

--Max



From valerie.peng at oracle.com  Thu Aug 18 03:36:55 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 17 Aug 2016 20:36:55 -0700
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
	<d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
Message-ID: <89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>

Regression tests are still running, but thought that I will send the 
updated webrev out and see if there are more comments.

Webrev is updated at: 
http://cr.openjdk.java.net/~valeriep/8078661/webrev.01/

Thanks,
Valerie

On 8/17/2016 9:55 AM, Michael StJohns wrote:
> On 8/16/2016 9:24 PM, Valerie Peng wrote:
>>
>> Anyone has time to review a straightforward fix? The current PKCS11 
>> code assume that if public exponent is available for RSA Private Key, 
>> then it's a RSA CRT key. However, not all vendor implementation works 
>> this way. Changing to a tighter check and did minor code-refactoring 
>> to avoid re-retrieving the attribute values.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
>> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
>>
>> Thanks,
>> Valerie
>
> Given that there's a change to PKCS11 for 2.40 that says that all RSA 
> private key objects  MUST also store CKA_PUBLIC_EXPONENT, some change 
> needed to be made.
>
> Sorry - I don't think this fix will work.  Or if its working on your 
> version of PKCS11, your version of PKCS11 is doing it wrong.  The 
> problem is that if you specify attributes that don't exist on the 
> object, the underlying PKCS11 library is supposed to return 
> CKR_ATTRIBUTE_TYPE_INVALID.  And that should trigger a thrown 
> exception before you ever get anything copied to your attributes.
>
> 1) Get modulus and private exponent first.  That gives you the stuff 
> for a generic RSA private key - and if it fails, there's no reason to 
> continue.
>
> 2) Then get the rest of the stuff.  If that fails, then you already 
> have the stuff you need for a normal private key.
>
>
>>                       boolean crtKey;
>>                       try {
>>                           session.token.p11.C_GetAttributeValue
>>                               (session.id(), keyID, attrs2);
>> - crtKey = (attrs2[0].pValue instanceof byte[]);
>> + crtKey = ((attrs2[1].pValue instanceof byte[]) &&
>> + (attrs2[3].pValue instanceof byte[]) &&
>> + (attrs2[4].pValue instanceof byte[]) &&
>> + (attrs2[5].pValue instanceof byte[]) &&
>> + (attrs2[6].pValue instanceof byte[]) &&
>> + (attrs2[7].pValue instanceof byte[])) ;
>>                       } catch (PKCS11Exception e) {
>>                           // ignore, assume not available
>>                           crtKey = false;
>>                       }
>
> // Change attrs2 so it only has the additional CRT attributes (e.g. 
> delete CKA_MODULUS, CKA_PRIVATE_EXPONENT from the list
>
> Replace the above with
>
> CK_ATTRIBUTE[] attrs3 = new CK_ATTRIBUTE[] {
>        new CK_ATTRIBUTE(CKA_MODULUS),
>        new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT)
> };
> // no try block needed here - we want to throw the error if it occurs
> session.token.p11.C_GetAttributeValue (session.id(), keyID, attrs3);
>
> // So far so good - we have the base attributes, let's see if we can 
> get the additional attributes;
>
> try {
>     session.token.p11.C_GetAttributeValue(session.id(),keyID, attrs2);
> } catch (PKCS11Exception e) {
>    // we really should check the return value for one of the non-fatal 
> values, but let's just assume its not a CRT key
>    return new P11RSAPrivateNonCRTKey (session, keyID, algorithm, 
> keyLength, attrs2, attrs3);
> }
>
> // if we fall through then its a CRT key
> // -- we should check for byte[] ness of each of the components, and 
> throw an error if they arent - but which error?
>
> return new P11RSAPrivateKey (session, keyID, algorithm, keyLength, 
> attrs2, attrs3);
>
> // there are cleanups necessary in other places.  I'd suggest rather 
> than depending on the ordering of attributes, you do assignment by 
> CKA_ values just so someone coming later doesn't mess things up by 
> mistake.  Also, a hell of a lot more readable.
>
> static CK_ATTRIBUTE getAttribute (CK_ATTRIBUTE[] attrs, long attrType) {
>     for (CK_ATTRIBUTE a : attrs) {
>          if (a.type == attrType)
>               return a;
>      }
>     return null; // or throw something?
> }
>
>
> coeff = getAtttribute(attrs,CKA_COEFFICIENT).getBigInteger();
>
>
> The other possibility is to change the C code for C_GetAttributeValues 
> so it doesn't error out for the non-fatal error codes and instead 
> returns a null value attribute when the attribute is missing.
>
> Mike
>

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

From weijun.wang at oracle.com  Thu Aug 18 04:26:07 2016
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 18 Aug 2016 12:26:07 +0800
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
Message-ID: <151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>

Before this change, you require default policy in neither export nor import to be empty but do not care about the getMinimum() result. In this change, you make sure the final result is not empty. I assume this is a fix?

283                     // Did we find a default perms?

What does this line mean?

296                         // This should never happen

But you can still print out the file name.


Can you rename policydir-tbd to something else? I am afraid it will be confused with policy.url.1 etc.

The original README.TXT in unlimited says "are exportable from the United States." and you have "is exportable." now. Is this intended? (IANAL)

TestUnlimited.java:
45 "// Use the AES are the test Cipher", you mean "Use AES as the test Cipher"?
51 "throw new Exception ("Unlimited policy is NOT active");". No space before "(".

No other comment.

--Max

> On Aug 18, 2016, at 7:22 AM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
> 
> New webrev:
> 
> https://bugs.openjdk.java.net/browse/JDK-8061842
> http://cr.openjdk.java.net/~wetmore/8061842/webrev.01/



From chris.hegarty at oracle.com  Thu Aug 18 07:51:24 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 18 Aug 2016 08:51:24 +0100
Subject: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in
	jdk_security3 group
In-Reply-To: <c71f748e-a557-bb64-5fec-72c6e78c1ff2@oracle.com>
References: <191bdeb1-a52d-ac36-e331-64eebd060b2d@oracle.com>
	<BE42DCBC-D278-42D3-A1B0-076AFBC56D54@oracle.com>
	<c71f748e-a557-bb64-5fec-72c6e78c1ff2@oracle.com>
Message-ID: <9B5D8A1C-B998-4286-A402-C0A7E61C758E@oracle.com>


> On 17 Aug 2016, at 19:52, Rajan Halade <rajan.halade at oracle.com> wrote:
> 
> On 8/17/16 11:36 AM, Chris Hegarty wrote:
> 
>> On 17 Aug 2016, at 18:54, Rajan Halade <rajan.halade at oracle.com> wrote:
>>> sun/net/www/protocol/https tests are redundant in jdk_security3 group, these are included in jdk_net group.
>> Yes they are, but it is very important that anyone touching TLS verify
>> that HTTPS still works. If the jdk_net tests will be run to verity
>> such changes, then this should be fine.
> Yes, these are useful tests to run with https changes. I don't think they need to be duplicated in jdk_security group as jdk_security and jdk_net are part of core tests and with continuous integration system in place to run all tests with each changeset, this duplication is not required.
>> 
>> Out of curiosity, how many tests are in sun/net/www/protocol/https,
>> and approximately how long do they run for?
> There are 27 tests and I see each of those finish within seconds (max I saw was 8 secs for ReadTimeout.java).

Ok, thanks. No objection from me.

-Chris.

From chris.hegarty at oracle.com  Thu Aug 18 07:51:24 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 18 Aug 2016 08:51:24 +0100
Subject: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in
	jdk_security3 group
In-Reply-To: <c71f748e-a557-bb64-5fec-72c6e78c1ff2@oracle.com>
References: <191bdeb1-a52d-ac36-e331-64eebd060b2d@oracle.com>
	<BE42DCBC-D278-42D3-A1B0-076AFBC56D54@oracle.com>
	<c71f748e-a557-bb64-5fec-72c6e78c1ff2@oracle.com>
Message-ID: <22826899-888A-48EA-AE94-C5C6B121A086@oracle.com>


> On 17 Aug 2016, at 19:52, Rajan Halade <rajan.halade at oracle.com> wrote:
> 
> On 8/17/16 11:36 AM, Chris Hegarty wrote:
> 
>> On 17 Aug 2016, at 18:54, Rajan Halade <rajan.halade at oracle.com> wrote:
>>> sun/net/www/protocol/https tests are redundant in jdk_security3 group, these are included in jdk_net group.
>> Yes they are, but it is very important that anyone touching TLS verify
>> that HTTPS still works. If the jdk_net tests will be run to verity
>> such changes, then this should be fine.
> Yes, these are useful tests to run with https changes. I don't think they need to be duplicated in jdk_security group as jdk_security and jdk_net are part of core tests and with continuous integration system in place to run all tests with each changeset, this duplication is not required.
>> 
>> Out of curiosity, how many tests are in sun/net/www/protocol/https,
>> and approximately how long do they run for?
> There are 27 tests and I see each of those finish within seconds (max I saw was 8 secs for ReadTimeout.java).

Ok, thanks. No objection from me.

-Chris.

From sean.coffey at oracle.com  Thu Aug 18 07:51:58 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 18 Aug 2016 08:51:58 +0100
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
In-Reply-To: <9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>
References: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
	<9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>
Message-ID: <e28d8b3a-0c0b-8b26-4031-7085424f6809@oracle.com>

Changes look good Ramanand. Reviewed.

Regards,
Sean.

On 18/08/2016 07:03, David Buck wrote:
> Hi Ramanand!
>
> As there are (minor) changes between the two change sets, you will need to get a code review of the backported changes. I have included the security-dev alias in the CC list.
>
> Cheers,
> -Buck
>
>> On Aug 18, 2016, at 14:34, Ramanand Patil <ramanand.patil at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review and approve the backport of 8144566 to 8u-dev.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144566
>>
>> JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3
>>
>> JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013171.html
>>
>> JDK8u-dev Webrev: http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/
>>
>> Changes apply semi-cleanly to jdk8u-dev after path reshuffling. Below are few reasons for manual edits in the jdk8u-dev patch:
>>
>> 1. JDK9 class name for "JavaNetAccess" is changed to " JavaNetInetAddressAccess".
>> 2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
>> 3. test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
>>
>>
>> Regards,
>> Ramanand.



From daniel.fuchs at oracle.com  Thu Aug 18 10:06:53 2016
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 18 Aug 2016 11:06:53 +0100
Subject: RFR [9] 8156841: sun.security.pkcs11.SunPKCS11 poller thread
	retains a strong reference to the context class loader
In-Reply-To: <455B517D-D665-4E4F-9B8F-4396BD33DE14@oracle.com>
References: <FEB9CC36-CA29-430F-B941-B03441CC4821@oracle.com>
	<455B517D-D665-4E4F-9B8F-4396BD33DE14@oracle.com>
Message-ID: <e1cef651-82e1-6455-aac1-fe9c7c18a5e3@oracle.com>

Hi Chris,

I agree that resetting the TCCL makes sense, and looks like the
minimal safer thing to do here.
InnocuousThread should probably be considered for the future,
but that's a first step in this direction :-)

best regards,

-- daniel

On 18/08/16 08:58, Chris Hegarty wrote:
>> The SunPKCS11 poller thread has no need of any user defined class loader,
>> so should set its context class loader to null before starting, so as to not
>> inadvertently retain a reference to the creating thread?s context class loader.
>>
>> In other areas that suffered from a similar issue we changed to use an
>> InnocuousThread, but I cannot fully satisfy myself that this is a safe
>> substation here, so I opted for the safest minimal fix. A future refactoring
>> exercise should consider using InnocuousThread.
>>
>> diff -r 92c31ec731eb src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java
>> --- a/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java	Wed Aug 10 11:54:12 2016 +0100
>> +++ b/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/SunPKCS11.java	Wed Aug 10 16:32:41 2016 +0100
>> @@ -809,20 +809,21 @@
>>         }
>>     }
>>
>>     // create the poller thread, if not already active
>>     private void createPoller() {
>>         if (poller != null) {
>>             return;
>>         }
>>         final TokenPoller poller = new TokenPoller(this);
>>         Thread t = new Thread(null, poller, "Poller " + getName(), 0, false);
>> +        t.setContextClassLoader(null);
>>         t.setDaemon(true);
>>         t.setPriority(Thread.MIN_PRIORITY);
>>         t.start();
>>         this.poller = poller;
>>     }
>>
>>     // destroy the poller thread, if active
>>     private void destroyPoller() {
>>         if (poller != null) {
>>             poller.disable();
>>
>> https://bugs.openjdk.java.net/browse/JDK-8156841
>>
>> -Chris.
>



From Alan.Bateman at oracle.com  Thu Aug 18 12:34:00 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Aug 2016 13:34:00 +0100
Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests
In-Reply-To: <4371BA82-A2A1-4AC5-8477-F46A589F52E3@oracle.com>
References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>
	<3b1f5d47-e64f-1f46-1486-889fa823841c@oracle.com>
	<D8B0F5A2-1024-4B5D-88AC-8E58DCDF1A72@oracle.com>
	<8D77C9ED-BA5E-4F94-BE2D-C73E418C666F@oracle.com>
	<4371BA82-A2A1-4AC5-8477-F46A589F52E3@oracle.com>
Message-ID: <477840f1-9358-d41f-9649-1da5ca7d1773@oracle.com>

On 17/08/2016 17:40, Alexandre (Shura) Iline wrote:

> Thank you!
>
> Fixed in place:
> http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/test/jdk/security/jarsigner/Spec.java.sdiff.html
>
> Shura
>
The updated patch looks good to me.

Slightly off-topic but how close do you think we are to dropping 
completely the test groups in the TEST.groups that are defined under the 
heading "Profile-based Test Group Definition"?

-Alan


From sean.coffey at oracle.com  Thu Aug 18 13:10:05 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 18 Aug 2016 14:10:05 +0100
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
Message-ID: <cef1addc-3ab5-645f-c820-e2eb780c966e@oracle.com>

Hi Brad,

nice to have this going in. Some comments.

1. Bug synopsis, can you edit it perhaps. "Introduce security property 
to control strong crypto" seems more descriptive.

2. Exception handling.

Alot of your new exceptions don't include context. That makes debugging 
more difficult than needs be.

> +            throw new SecurityException(
> +                "Invalid cryptographic jurisdiction policy directory value");
> +        if (!Files.isDirectory(path) || !Files.isReadable(path)) {
> +            throw new Exception("Can't read cryptographic policy directory");

> +                        throw new SecurityException(
> +                            "Unexpected jurisdiction policy filename found");

> +                } catch (Exception e) {
> +                    throw new SecurityException(
> +                        "Couldn't parse jurisdiction policy files");
Please include the exception 'e' in your last exception here.


> +        } catch (DirectoryIteratorException ex) {
> +            // I/O error encountered during the iteration,
> +            // the cause is an IOException
> +            throw new SecurityException(
> +                    "Couldn't iterate through the jurisdiction policy files");
> +        }
Can you add the DirectoryIteratorException to the final exception that 
you're throwing ?

3. Test case.

The TestUnlimited.java testcase seems to be lacking. Do you want to test 
other values for crypto.policy ? 'limited' would be one. Throwing in 
some dummy value would also be good so that the exception handling code 
gets exercised.

It needs to be run in ovm mode since you're setting a Security property.

Regards,
Sean.

On 18/08/2016 05:26, Wang Weijun wrote:
> Before this change, you require default policy in neither export nor import to be empty but do not care about the getMinimum() result. In this change, you make sure the final result is not empty. I assume this is a fix?
>
> 283                     // Did we find a default perms?
>
> What does this line mean?
>
> 296                         // This should never happen
>
> But you can still print out the file name.
>
>
> Can you rename policydir-tbd to something else? I am afraid it will be confused with policy.url.1 etc.
>
> The original README.TXT in unlimited says "are exportable from the United States." and you have "is exportable." now. Is this intended? (IANAL)
>
> TestUnlimited.java:
> 45 "// Use the AES are the test Cipher", you mean "Use AES as the test Cipher"?
> 51 "throw new Exception ("Unlimited policy is NOT active");". No space before "(".
>
> No other comment.
>
> --Max
>
>> On Aug 18, 2016, at 7:22 AM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
>>
>> New webrev:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8061842
>> http://cr.openjdk.java.net/~wetmore/8061842/webrev.01/

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

From sean.coffey at oracle.com  Thu Aug 18 15:28:15 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 18 Aug 2016 16:28:15 +0100
Subject: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java
	fails
In-Reply-To: <dff2b1b9-72aa-7c6e-fe27-bb8b1112967e@oracle.com>
References: <57B4969B.4030904@oracle.com>
	<0ee91f5b-bcd5-7c93-d99d-13c00797d8f3@oracle.com>
	<57B49B18.3030505@oracle.com>
	<27699872-c744-7ae6-249b-c3562c5a882e@oracle.com>
	<dff2b1b9-72aa-7c6e-fe27-bb8b1112967e@oracle.com>
Message-ID: <f5f69f07-c1d4-31c6-6fa3-2061a679ad6b@oracle.com>

Thanks for the tip Artem, Max. No need to modify the policy file then. 
Below is the new suggested patch for jdk8u-dev. JPRT results are good.

diff --git a/test/sun/security/krb5/auto/UnboundSSL.java 
b/test/sun/security/krb5/auto/UnboundSSL.java
--- a/test/sun/security/krb5/auto/UnboundSSL.java
+++ b/test/sun/security/krb5/auto/UnboundSSL.java
@@ -34,9 +34,9 @@
   * @bug 8025123
   * @summary Checks if an unbound server can handle connections
   *          only for allowed service principals
- * @run main/othervm/policy=unbound.ssl.policy UnboundSSL
+ * @run main/othervm/java.security.policy=unbound.ssl.policy UnboundSSL
   *                              unbound.ssl.jaas.conf server_star
- * @run main/othervm/policy=unbound.ssl.policy UnboundSSL
+ * @run main/othervm/java.security.policy=unbound.ssl.policy UnboundSSL
   *                              unbound.ssl.jaas.conf 
server_multiple_principals
   */
  public class UnboundSSL {

Regards,
Sean.

On 18/08/2016 04:11, Weijun Wang wrote:
>>>> If I recall correctly, there should be a way to specify a policy file
>>>> in @run without overriding the default one. May be it is "@run
>>>> main/othervm/java.security.policy=unbound.ssl.policy_new"
>
> Yes, I think this should work. I've also just learned about it and 
> don't know from which jtreg it is supported. Hopefully the 
> minimized-required version of jtreg for jdk8u already has it.
>
> --Max
>



From mstjohns at comcast.net  Thu Aug 18 15:40:36 2016
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 18 Aug 2016 11:40:36 -0400
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
	<d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
	<89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>
Message-ID: <851c0000-8341-294c-e62b-f15334d417a1@comcast.net>

On 8/17/2016 11:36 PM, Valerie Peng wrote:
> Regression tests are still running, but thought that I will send the 
> updated webrev out and see if there are more comments.
>
> Webrev is updated at: 
> http://cr.openjdk.java.net/~valeriep/8078661/webrev.01/
>
> Thanks,
> Valerie
Hi Valerie -

You know - re-reading this code I'm reminding of why PKCS11 annoys me so 
much.

At line 333 (of the "new" P11Key) you grab the Token, Sensitive and 
Extractable values and if the private data is sensitive or not 
extractable you create a generic P11PrivateKey and return that. However 
the contract for RSAKey requires that the public modulus be returned if 
available, and, since its not a sensitive attribute it probably should 
be available.  Also, even if the key is sensitive - if its a sensitive  
CRT key, then CKA_PUBLIC_EXPONENT should be available.

That's going to be a surprise if someone tries to cast this return to an 
(RSAKey) or (RSAPrivateKey). _This should be changed so a key of the 
appropriate type is always created._

Also, checking for CKA_EXTRACTABLE being true, doesn't actually get you 
access to the clear text information.  If a key is extractable, then it 
can be wrapped out under another key.  The components themselves aren't 
available.  It's possible to have a non-sensitive, non-extractable key 
where the components are retrievable, but the key can't be wrapped out.


(Hmm... the public exponent is in RSAPublicKey and RSAPrivateCRTKey, but 
should probably be in RSAKey instead).

So:

All RSA keys - even the sensitive private ones  - should return CKA_MODULUS.
All RSA Private CRT Keys - even the sensitive ones - should also return 
CKA_PUBLIC_EXPONENT.
All non-sensitive RSA Private keys - should also return CKA_PRIVATE_EXPONENT
All non-sensitive RSA Private CRT Keys - should also return CKA_PRIME_1, 
CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT_2 and CKA_COEFFICIENT.

This is harder to do than it needs to be due to how 
p11_objmgt.c::Java_sun_security_pkcs11_wrapper_PKCS11_C_1GetAttributeValue 
is built.  At lines 248 and 270, it does a check for an error return and 
throws an exception if any error occurs.  However, for 
C_GetAttributeValue, there are a number of "non-fatal" errors that 
indicate either buffer size errors or sensitivity of one or more 
components or unavailability of one or more components.
> Note that the error codes CKR_ATTRIBUTE_SENSITIVE, 
> CKR_ATTRIBUTE_TYPE_INVALID, and CKR_BUFFER_TOO_SMALL  do not denote 
> true errors for *C_GetAttributeValue*.  If a call to 
> *C_GetAttributeValue* returns any of these three values, then the call 
> must nonetheless have processed /every/ attribute in the template 
> supplied to *C_GetAttributeValue*. Each attribute in the template 
> whose value /can be/ returned by the call to *C_GetAttributeValue* 
> /will be/ returned by the call to *C_GetAttributeValue*.



If you updated this slightly - maybe by adding a new method to 
wrapper.PKCS11 (say GetAttributeValuesNoError) - to return the 
attributes it was able to get in the call with nulls elsewhere, then you 
could do all of the above in one pass.

Sorry to complicate this.  Mike

ps - I don't have a current build environment set up for the JDK, 
otherwise I'd code it and test it myself.  I'm happy to take a swing at 
it and provide you unverified code you can integrate.

>
> On 8/17/2016 9:55 AM, Michael StJohns wrote:
>> On 8/16/2016 9:24 PM, Valerie Peng wrote:
>>>
>>> Anyone has time to review a straightforward fix? The current PKCS11 
>>> code assume that if public exponent is available for RSA Private 
>>> Key, then it's a RSA CRT key. However, not all vendor implementation 
>>> works this way. Changing to a tighter check and did minor 
>>> code-refactoring to avoid re-retrieving the attribute values.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
>>>
>>> Thanks,
>>> Valerie
>>
>> Given that there's a change to PKCS11 for 2.40 that says that all RSA 
>> private key objects  MUST also store CKA_PUBLIC_EXPONENT, some change 
>> needed to be made.
>>
>> Sorry - I don't think this fix will work.  Or if its working on your 
>> version of PKCS11, your version of PKCS11 is doing it wrong.  The 
>> problem is that if you specify attributes that don't exist on the 
>> object, the underlying PKCS11 library is supposed to return 
>> CKR_ATTRIBUTE_TYPE_INVALID.  And that should trigger a thrown 
>> exception before you ever get anything copied to your attributes.
>>
>> 1) Get modulus and private exponent first.  That gives you the stuff 
>> for a generic RSA private key - and if it fails, there's no reason to 
>> continue.
>>
>> 2) Then get the rest of the stuff.  If that fails, then you already 
>> have the stuff you need for a normal private key.
>>
>>
>>>                       boolean crtKey;
>>>                       try {
>>>                           session.token.p11.C_GetAttributeValue
>>>                               (session.id(), keyID, attrs2);
>>> - crtKey = (attrs2[0].pValue instanceof byte[]);
>>> + crtKey = ((attrs2[1].pValue instanceof byte[]) &&
>>> + (attrs2[3].pValue instanceof byte[]) &&
>>> + (attrs2[4].pValue instanceof byte[]) &&
>>> + (attrs2[5].pValue instanceof byte[]) &&
>>> + (attrs2[6].pValue instanceof byte[]) &&
>>> + (attrs2[7].pValue instanceof byte[])) ;
>>>                       } catch (PKCS11Exception e) {
>>>                           // ignore, assume not available
>>>                           crtKey = false;
>>>                       }
>>
>> // Change attrs2 so it only has the additional CRT attributes (e.g. 
>> delete CKA_MODULUS, CKA_PRIVATE_EXPONENT from the list
>>
>> Replace the above with
>>
>> CK_ATTRIBUTE[] attrs3 = new CK_ATTRIBUTE[] {
>>        new CK_ATTRIBUTE(CKA_MODULUS),
>>        new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT)
>> };
>> // no try block needed here - we want to throw the error if it occurs
>> session.token.p11.C_GetAttributeValue (session.id(), keyID, attrs3);
>>
>> // So far so good - we have the base attributes, let's see if we can 
>> get the additional attributes;
>>
>> try {
>>     session.token.p11.C_GetAttributeValue(session.id(),keyID, attrs2);
>> } catch (PKCS11Exception e) {
>>    // we really should check the return value for one of the 
>> non-fatal values, but let's just assume its not a CRT key
>>    return new P11RSAPrivateNonCRTKey (session, keyID, algorithm, 
>> keyLength, attrs2, attrs3);
>> }
>>
>> // if we fall through then its a CRT key
>> // -- we should check for byte[] ness of each of the components, and 
>> throw an error if they arent - but which error?
>>
>> return new P11RSAPrivateKey (session, keyID, algorithm, keyLength, 
>> attrs2, attrs3);
>>
>> // there are cleanups necessary in other places.  I'd suggest rather 
>> than depending on the ordering of attributes, you do assignment by 
>> CKA_ values just so someone coming later doesn't mess things up by 
>> mistake.  Also, a hell of a lot more readable.
>>
>> static CK_ATTRIBUTE getAttribute (CK_ATTRIBUTE[] attrs, long attrType) {
>>     for (CK_ATTRIBUTE a : attrs) {
>>          if (a.type == attrType)
>>               return a;
>>      }
>>     return null; // or throw something?
>> }
>>
>>
>> coeff = getAtttribute(attrs,CKA_COEFFICIENT).getBigInteger();
>>
>>
>> The other possibility is to change the C code for 
>> C_GetAttributeValues so it doesn't error out for the non-fatal error 
>> codes and instead returns a null value attribute when the attribute 
>> is missing.
>>
>> Mike
>>
>

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

From mstjohns at comcast.net  Thu Aug 18 15:56:33 2016
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 18 Aug 2016 11:56:33 -0400
Subject: RSA Key Interfaces Was: Re: [9] RFR 8078661: [SunPKCS11] Fails to
	cast into RSAPrivateCrtKey after RSA KeyPair Generation
In-Reply-To: <89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
	<d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
	<89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>
Message-ID: <f52b6dbe-79d5-03f6-a776-85f2916d34ca@comcast.net>

Hi -

Looking at Valeries changes to the above made me take a closer look at 
the current definitions of the various RSA key interfaces. What would be 
the impact of the following changes?:

Make RSAMultiPrimePrivateCrtKeySpec extend RSAPrivateCrtKeyKeySpec 
instead of RSAPrivateKeySpec.  RSAMultiPrimePrivateCrtKeySpec would then 
only define the RSAOtherPrimeInfo[] getOtherPrimeInfo() method.

Ditto for RSAMultiPrimePrivateCrtKey and RSAPrivateCrtKey

Move getPublicExponent() from RSAPublicKey and RSAPrivateCrtKey to RSAKey.

Ditto for the Spec versions.


I think the first two changes can be done without adverse impact and are 
more correct than the current definitions.

The latter two are more problematic, but can probably be handled using 
the default method mechanism.

The API documents would indicate that these functions would return null 
if the values are unavailable.

Mike



From artem.smotrakov at oracle.com  Thu Aug 18 16:45:44 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 18 Aug 2016 09:45:44 -0700
Subject: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java
	fails
In-Reply-To: <f5f69f07-c1d4-31c6-6fa3-2061a679ad6b@oracle.com>
References: <57B4969B.4030904@oracle.com>
	<0ee91f5b-bcd5-7c93-d99d-13c00797d8f3@oracle.com>
	<57B49B18.3030505@oracle.com>
	<27699872-c744-7ae6-249b-c3562c5a882e@oracle.com>
	<dff2b1b9-72aa-7c6e-fe27-bb8b1112967e@oracle.com>
	<f5f69f07-c1d4-31c6-6fa3-2061a679ad6b@oracle.com>
Message-ID: <5bee7906-e5ea-0e8c-4d74-3fdf9a12b8cb@oracle.com>

Hi Sean,

The patch below looks fine to me, but I am not an official reviewer.

Artem


On 08/18/2016 08:28 AM, Se?n Coffey wrote:
> Thanks for the tip Artem, Max. No need to modify the policy file then. 
> Below is the new suggested patch for jdk8u-dev. JPRT results are good.
>
> diff --git a/test/sun/security/krb5/auto/UnboundSSL.java 
> b/test/sun/security/krb5/auto/UnboundSSL.java
> --- a/test/sun/security/krb5/auto/UnboundSSL.java
> +++ b/test/sun/security/krb5/auto/UnboundSSL.java
> @@ -34,9 +34,9 @@
>   * @bug 8025123
>   * @summary Checks if an unbound server can handle connections
>   *          only for allowed service principals
> - * @run main/othervm/policy=unbound.ssl.policy UnboundSSL
> + * @run main/othervm/java.security.policy=unbound.ssl.policy UnboundSSL
>   *                              unbound.ssl.jaas.conf server_star
> - * @run main/othervm/policy=unbound.ssl.policy UnboundSSL
> + * @run main/othervm/java.security.policy=unbound.ssl.policy UnboundSSL
>   *                              unbound.ssl.jaas.conf 
> server_multiple_principals
>   */
>  public class UnboundSSL {
>
> Regards,
> Sean.
>
> On 18/08/2016 04:11, Weijun Wang wrote:
>>>>> If I recall correctly, there should be a way to specify a policy file
>>>>> in @run without overriding the default one. May be it is "@run
>>>>> main/othervm/java.security.policy=unbound.ssl.policy_new"
>>
>> Yes, I think this should work. I've also just learned about it and 
>> don't know from which jtreg it is supported. Hopefully the 
>> minimized-required version of jtreg for jdk8u already has it.
>>
>> --Max
>>
>



From bradford.wetmore at oracle.com  Thu Aug 18 16:59:05 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 18 Aug 2016 09:59:05 -0700
Subject: RFR: 9: 8164229: Redundant "sun/net/www/protocol/https" tests in
	jdk_security3 group
In-Reply-To: <22826899-888A-48EA-AE94-C5C6B121A086@oracle.com>
References: <191bdeb1-a52d-ac36-e331-64eebd060b2d@oracle.com>
	<BE42DCBC-D278-42D3-A1B0-076AFBC56D54@oracle.com>
	<c71f748e-a557-bb64-5fec-72c6e78c1ff2@oracle.com>
	<22826899-888A-48EA-AE94-C5C6B121A086@oracle.com>
Message-ID: <1f8a6d0a-c6aa-64bc-fe62-3bcc419d78e6@oracle.com>

This was probably more important when the Security group had direct 
responsibility for the https code.

Brad

On 8/18/2016 12:51 AM, Chris Hegarty wrote:
>
>> On 17 Aug 2016, at 19:52, Rajan Halade <rajan.halade at oracle.com> wrote:
>>
>> On 8/17/16 11:36 AM, Chris Hegarty wrote:
>>
>>> On 17 Aug 2016, at 18:54, Rajan Halade <rajan.halade at oracle.com> wrote:
>>>> sun/net/www/protocol/https tests are redundant in jdk_security3 group, these are included in jdk_net group.
>>> Yes they are, but it is very important that anyone touching TLS verify
>>> that HTTPS still works. If the jdk_net tests will be run to verity
>>> such changes, then this should be fine.
>> Yes, these are useful tests to run with https changes. I don't think they need to be duplicated in jdk_security group as jdk_security and jdk_net are part of core tests and with continuous integration system in place to run all tests with each changeset, this duplication is not required.
>>>
>>> Out of curiosity, how many tests are in sun/net/www/protocol/https,
>>> and approximately how long do they run for?
>> There are 27 tests and I see each of those finish within seconds (max I saw was 8 secs for ReadTimeout.java).
>
> Ok, thanks. No objection from me.
>
> -Chris.
>


From david.buck at oracle.com  Thu Aug 18 06:03:36 2016
From: david.buck at oracle.com (David Buck)
Date: Thu, 18 Aug 2016 15:03:36 +0900
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
In-Reply-To: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
References: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
Message-ID: <9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>

Hi Ramanand!

As there are (minor) changes between the two change sets, you will need to get a code review of the backported changes. I have included the security-dev alias in the CC list.

Cheers,
-Buck

> On Aug 18, 2016, at 14:34, Ramanand Patil <ramanand.patil at oracle.com> wrote:
> 
> Hi,
> 
> Please review and approve the backport of 8144566 to 8u-dev.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144566
> 
> JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3
> 
> JDK9 Review Thread: http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013171.html
> 
> JDK8u-dev Webrev: http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/
> 
> Changes apply semi-cleanly to jdk8u-dev after path reshuffling. Below are few reasons for manual edits in the jdk8u-dev patch:
> 
> 1. JDK9 class name for "JavaNetAccess" is changed to " JavaNetInetAddressAccess".
> 2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
> 3. test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java pathToStores(keystore path) doesn't exist in JDK8u, hence changed the variable to point to available path.
> 
> 
> Regards,
> Ramanand.



From david.buck at oracle.com  Thu Aug 18 07:55:31 2016
From: david.buck at oracle.com (david buck)
Date: Thu, 18 Aug 2016 16:55:31 +0900
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
In-Reply-To: <e28d8b3a-0c0b-8b26-4031-7085424f6809@oracle.com>
References: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
	<9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>
	<e28d8b3a-0c0b-8b26-4031-7085424f6809@oracle.com>
Message-ID: <fb44f429-fc6a-e68c-7f13-e473d641a078@oracle.com>

approved for push to 8u-dev

Cheers,
-Buck

On 2016/08/18 16:51, Se?n Coffey wrote:
> Changes look good Ramanand. Reviewed.
>
> Regards,
> Sean.
>
> On 18/08/2016 07:03, David Buck wrote:
>> Hi Ramanand!
>>
>> As there are (minor) changes between the two change sets, you will
>> need to get a code review of the backported changes. I have included
>> the security-dev alias in the CC list.
>>
>> Cheers,
>> -Buck
>>
>>> On Aug 18, 2016, at 14:34, Ramanand Patil <ramanand.patil at oracle.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please review and approve the backport of 8144566 to 8u-dev.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144566
>>>
>>> JDK9 Changeset:
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3
>>>
>>> JDK9 Review Thread:
>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-December/013171.html
>>>
>>>
>>> JDK8u-dev Webrev: http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/
>>>
>>> Changes apply semi-cleanly to jdk8u-dev after path reshuffling. Below
>>> are few reasons for manual edits in the jdk8u-dev patch:
>>>
>>> 1. JDK9 class name for "JavaNetAccess" is changed to "
>>> JavaNetInetAddressAccess".
>>> 2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java
>>> pathToStores(keystore path) doesn't exist in JDK8u, hence changed the
>>> variable to point to available path.
>>> 3.
>>> test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java
>>> pathToStores(keystore path) doesn't exist in JDK8u, hence changed the
>>> variable to point to available path.
>>>
>>>
>>> Regards,
>>> Ramanand.
>


From ramanand.patil at oracle.com  Thu Aug 18 07:57:01 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Thu, 18 Aug 2016 00:57:01 -0700 (PDT)
Subject: [8u-dev] Request for Approval: Backport of 8144566: Custom
	HostnameVerifier disables SNI extension
In-Reply-To: <fb44f429-fc6a-e68c-7f13-e473d641a078@oracle.com>
References: <e197c9b4-c813-4780-a5ef-de867d24171d@default>
	<9F591029-13DD-478C-BA0C-CCEE87F1F440@oracle.com>
	<e28d8b3a-0c0b-8b26-4031-7085424f6809@oracle.com>
	<fb44f429-fc6a-e68c-7f13-e473d641a078@oracle.com>
Message-ID: <3191d787-dc45-4584-b99d-b717afdfa96c@default>

Thank you Sean and David.

Regards,
Ramanand.

-----Original Message-----
From: david buck 
Sent: Thursday, August 18, 2016 1:26 PM
To: Se?n Coffey; Ramanand Patil
Cc: jdk8u-dev; security-dev at openjdk.java.net
Subject: Re: [8u-dev] Request for Approval: Backport of 8144566: Custom HostnameVerifier disables SNI extension

approved for push to 8u-dev

Cheers,
-Buck

On 2016/08/18 16:51, Se?n Coffey wrote:
> Changes look good Ramanand. Reviewed.
>
> Regards,
> Sean.
>
> On 18/08/2016 07:03, David Buck wrote:
>> Hi Ramanand!
>>
>> As there are (minor) changes between the two change sets, you will 
>> need to get a code review of the backported changes. I have included 
>> the security-dev alias in the CC list.
>>
>> Cheers,
>> -Buck
>>
>>> On Aug 18, 2016, at 14:34, Ramanand Patil 
>>> <ramanand.patil at oracle.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please review and approve the backport of 8144566 to 8u-dev.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144566
>>>
>>> JDK9 Changeset:
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1781aba4f7e3
>>>
>>> JDK9 Review Thread:
>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-December/01
>>> 3171.html
>>>
>>>
>>> JDK8u-dev Webrev: 
>>> http://cr.openjdk.java.net/~rpatil/8144566/webrev.00/
>>>
>>> Changes apply semi-cleanly to jdk8u-dev after path reshuffling. 
>>> Below are few reasons for manual edits in the jdk8u-dev patch:
>>>
>>> 1. JDK9 class name for "JavaNetAccess" is changed to "
>>> JavaNetInetAddressAccess".
>>> 2. test/javax/net/ssl/ServerName/BestEffortOnLazyConnected.java
>>> pathToStores(keystore path) doesn't exist in JDK8u, hence changed 
>>> the variable to point to available path.
>>> 3.
>>> test/sun/net/www/protocol/https/HttpsURLConnection/ImpactOnSNI.java
>>> pathToStores(keystore path) doesn't exist in JDK8u, hence changed 
>>> the variable to point to available path.
>>>
>>>
>>> Regards,
>>> Ramanand.
>


From sean.mullan at oracle.com  Thu Aug 18 17:53:35 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 18 Aug 2016 13:53:35 -0400
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
Message-ID: <af7f4f6d-fabf-1d3d-8546-576edab64fa7@oracle.com>

On 08/17/2016 07:22 PM, Bradford Wetmore wrote:
>> - src/java.base/share/conf/security/java.security
>>
>> 854 crypto.policy=policydir-tbd
>>
>> The policydir-tbd value is a little confusing in that it isn't a real
>> value. What about just setting this to the empty string?
>
> It's a similar marker for the string replacement like was done for
> security.provider.tbd.

Ok, but those are property names.

What about setting the default value to "limited"? And then this would 
only be changed to "unlimited" if the build --enable-unlimited-crypto 
option is specified?

> I could change it to be delineated with <>:
> "<policydir-tbd>" if you like?

>> - src/java.base/share/classes/javax/crypto/JceSecurity.java
>>
>>  255         String cryptoPolicyDir =
>> Security.getProperty("crypto.policy");
>>  256         Path cryptoPolicyPath = Paths.get(cryptoPolicyDir);
>>
>> What happens if crypto.policy is not set or is set to ""?
>
> Good catch.  Not set would NPE, "" would simply look at
> <java-home>/conf/security/policy and fail to iterate the directory if no
> files were actually there.  I've added code for both those conditions,
> and also switched to use Path.resolve().

  253         // Sanity check the crypto.policy Security property.  Single
  254         // directory entry, no pseudo- or subdirectories.
  255         String cryptoPolicyDir = 
Security.getProperty("crypto.policy");
  256
  257         if (cryptoPolicyDir == null) {
  258             throw new SecurityException(
  259                 "No cryptographic jurisdiction policy directory 
value");
  260         }

Instead of throwing an exception here, I wonder if it would make more 
sense to assume a default value of "limited" if the property is not set 
or is empty.

--Sean



From valerie.peng at oracle.com  Thu Aug 18 20:49:22 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 18 Aug 2016 13:49:22 -0700
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <851c0000-8341-294c-e62b-f15334d417a1@comcast.net>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
	<d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
	<89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>
	<851c0000-8341-294c-e62b-f15334d417a1@comcast.net>
Message-ID: <4a33b5ec-816e-5ee5-ae77-f865c6b42fb3@oracle.com>

Hi Mike,

Thanks for the feedback and the detailed write up.

The scenario here is complicated by the sensitive/non-extractable keys 
of PKCS#11 and the fact that java key and key specification classes 
assume all relevant values being available. Only when all relevant 
values are available, then we will construct the corresponding key 
objects. This is necessary as there are other providers which may 
receive such keys and they can't handle keys like this.

I am sure that the current PKCS11 provider code needs many 
improvement/finer handlings. But I don't see a straightforward way of 
"making CKA_PUBLIC_EXPONENT available" across various RSA Key classes. 
This should be tracked in a different issue.

Given the current release schedule, the deadline for this fix (P4) is 
coming up in 10 days and I will be on vacation next week.

If you agree with the value of addressing this with the proposed changes 
for JDK 9, then we can proceed.
Otherwise, I will defer this bug to the update release and we can spend 
more time to polish this.
Valerie

On 8/18/2016 8:40 AM, Michael StJohns wrote:
> On 8/17/2016 11:36 PM, Valerie Peng wrote:
>> Regression tests are still running, but thought that I will send the 
>> updated webrev out and see if there are more comments.
>>
>> Webrev is updated at: 
>> http://cr.openjdk.java.net/~valeriep/8078661/webrev.01/
>>
>> Thanks,
>> Valerie
> Hi Valerie -
>
> You know - re-reading this code I'm reminding of why PKCS11 annoys me 
> so much.
>
> At line 333 (of the "new" P11Key) you grab the Token, Sensitive and 
> Extractable values and if the private data is sensitive or not 
> extractable you create a generic P11PrivateKey and return that. 
> However the contract for RSAKey requires that the public modulus be 
> returned if available, and, since its not a sensitive attribute it 
> probably should be available.  Also, even if the key is sensitive - if 
> its a sensitive  CRT key, then CKA_PUBLIC_EXPONENT should be available.
>
> That's going to be a surprise if someone tries to cast this return to 
> an (RSAKey) or (RSAPrivateKey). _This should be changed so a key of 
> the appropriate type is always created._
>
> Also, checking for CKA_EXTRACTABLE being true, doesn't actually get 
> you access to the clear text information.  If a key is extractable, 
> then it can be wrapped out under another key.  The components 
> themselves aren't available.  It's possible to have a non-sensitive, 
> non-extractable key where the components are retrievable, but the key 
> can't be wrapped out.
>
>
> (Hmm... the public exponent is in RSAPublicKey and RSAPrivateCRTKey, 
> but should probably be in RSAKey instead).
>
> So:
>
> All RSA keys - even the sensitive private ones  - should return 
> CKA_MODULUS.
> All RSA Private CRT Keys - even the sensitive ones - should also 
> return CKA_PUBLIC_EXPONENT.
> All non-sensitive RSA Private keys - should also return 
> CKA_PRIVATE_EXPONENT
> All non-sensitive RSA Private CRT Keys - should also return 
> CKA_PRIME_1, CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT_2 and 
> CKA_COEFFICIENT.
>
> This is harder to do than it needs to be due to how 
> p11_objmgt.c::Java_sun_security_pkcs11_wrapper_PKCS11_C_1GetAttributeValue 
> is built.  At lines 248 and 270, it does a check for an error return 
> and throws an exception if any error occurs.  However, for 
> C_GetAttributeValue, there are a number of "non-fatal" errors that 
> indicate either buffer size errors or sensitivity of one or more 
> components or unavailability of one or more components.
>> Note that the error codes CKR_ATTRIBUTE_SENSITIVE, 
>> CKR_ATTRIBUTE_TYPE_INVALID, and CKR_BUFFER_TOO_SMALL  do not denote 
>> true errors for *C_GetAttributeValue*. If a call to 
>> *C_GetAttributeValue* returns any of these three values, then the 
>> call must nonetheless have processed /every/ attribute in the 
>> template supplied to *C_GetAttributeValue*. Each attribute in the 
>> template whose value /can be/ returned by the call to 
>> *C_GetAttributeValue* /will be/ returned by the call to 
>> *C_GetAttributeValue*.
>
>
>
> If you updated this slightly - maybe by adding a new method to 
> wrapper.PKCS11 (say GetAttributeValuesNoError) - to return the 
> attributes it was able to get in the call with nulls elsewhere, then 
> you could do all of the above in one pass.
>
> Sorry to complicate this.  Mike
>
> ps - I don't have a current build environment set up for the JDK, 
> otherwise I'd code it and test it myself.  I'm happy to take a swing 
> at it and provide you unverified code you can integrate.
>
>>
>> On 8/17/2016 9:55 AM, Michael StJohns wrote:
>>> On 8/16/2016 9:24 PM, Valerie Peng wrote:
>>>>
>>>> Anyone has time to review a straightforward fix? The current PKCS11 
>>>> code assume that if public exponent is available for RSA Private 
>>>> Key, then it's a RSA CRT key. However, not all vendor 
>>>> implementation works this way. Changing to a tighter check and did 
>>>> minor code-refactoring to avoid re-retrieving the attribute values.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
>>>>
>>>> Thanks,
>>>> Valerie
>>>
>>> Given that there's a change to PKCS11 for 2.40 that says that all 
>>> RSA private key objects  MUST also store CKA_PUBLIC_EXPONENT, some 
>>> change needed to be made.
>>>
>>> Sorry - I don't think this fix will work.  Or if its working on your 
>>> version of PKCS11, your version of PKCS11 is doing it wrong.  The 
>>> problem is that if you specify attributes that don't exist on the 
>>> object, the underlying PKCS11 library is supposed to return 
>>> CKR_ATTRIBUTE_TYPE_INVALID.  And that should trigger a thrown 
>>> exception before you ever get anything copied to your attributes.
>>>
>>> 1) Get modulus and private exponent first.  That gives you the stuff 
>>> for a generic RSA private key - and if it fails, there's no reason 
>>> to continue.
>>>
>>> 2) Then get the rest of the stuff.  If that fails, then you already 
>>> have the stuff you need for a normal private key.
>>>
>>>
>>>>                       boolean crtKey;
>>>>                       try {
>>>>                           session.token.p11.C_GetAttributeValue
>>>>                               (session.id(), keyID, attrs2);
>>>> - crtKey = (attrs2[0].pValue instanceof byte[]);
>>>> + crtKey = ((attrs2[1].pValue instanceof byte[]) &&
>>>> + (attrs2[3].pValue instanceof byte[]) &&
>>>> + (attrs2[4].pValue instanceof byte[]) &&
>>>> + (attrs2[5].pValue instanceof byte[]) &&
>>>> + (attrs2[6].pValue instanceof byte[]) &&
>>>> + (attrs2[7].pValue instanceof byte[])) ;
>>>>                       } catch (PKCS11Exception e) {
>>>>                           // ignore, assume not available
>>>>                           crtKey = false;
>>>>                       }
>>>
>>> // Change attrs2 so it only has the additional CRT attributes (e.g. 
>>> delete CKA_MODULUS, CKA_PRIVATE_EXPONENT from the list
>>>
>>> Replace the above with
>>>
>>> CK_ATTRIBUTE[] attrs3 = new CK_ATTRIBUTE[] {
>>>        new CK_ATTRIBUTE(CKA_MODULUS),
>>>        new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT)
>>> };
>>> // no try block needed here - we want to throw the error if it occurs
>>> session.token.p11.C_GetAttributeValue (session.id(), keyID, attrs3);
>>>
>>> // So far so good - we have the base attributes, let's see if we can 
>>> get the additional attributes;
>>>
>>> try {
>>> session.token.p11.C_GetAttributeValue(session.id(),keyID, attrs2);
>>> } catch (PKCS11Exception e) {
>>>    // we really should check the return value for one of the 
>>> non-fatal values, but let's just assume its not a CRT key
>>>    return new P11RSAPrivateNonCRTKey (session, keyID, algorithm, 
>>> keyLength, attrs2, attrs3);
>>> }
>>>
>>> // if we fall through then its a CRT key
>>> // -- we should check for byte[] ness of each of the components, and 
>>> throw an error if they arent - but which error?
>>>
>>> return new P11RSAPrivateKey (session, keyID, algorithm, keyLength, 
>>> attrs2, attrs3);
>>>
>>> // there are cleanups necessary in other places.  I'd suggest rather 
>>> than depending on the ordering of attributes, you do assignment by 
>>> CKA_ values just so someone coming later doesn't mess things up by 
>>> mistake.  Also, a hell of a lot more readable.
>>>
>>> static CK_ATTRIBUTE getAttribute (CK_ATTRIBUTE[] attrs, long attrType) {
>>>     for (CK_ATTRIBUTE a : attrs) {
>>>          if (a.type == attrType)
>>>               return a;
>>>      }
>>>     return null; // or throw something?
>>> }
>>>
>>>
>>> coeff = getAtttribute(attrs,CKA_COEFFICIENT).getBigInteger();
>>>
>>>
>>> The other possibility is to change the C code for 
>>> C_GetAttributeValues so it doesn't error out for the non-fatal error 
>>> codes and instead returns a null value attribute when the attribute 
>>> is missing.
>>>
>>> Mike
>>>
>>
>

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

From vincent.x.ryan at oracle.com  Thu Aug 18 21:17:29 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 18 Aug 2016 22:17:29 +0100
Subject: [9] RFR 8164398: Add test sun/security/krb5/auto/EmptyPassword.java
	to ProblemList
Message-ID: <2D473677-B0D3-464C-B854-846EB5412C6A@oracle.com>

Please approve this change to add a failing test to jdk/test/ProblemList.txt so we can investigate further.
Thanks.


diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -289,6 +289,8 @@

 sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java         8161232 macosx-all

+sun/security/krb5/auto/EmptyPassword.java                       8164307 solaris-all
+
 ############################################################################

 # jdk_sound
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160818/001bd538/attachment.htm>

From mstjohns at comcast.net  Thu Aug 18 21:25:29 2016
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 18 Aug 2016 17:25:29 -0400
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <4a33b5ec-816e-5ee5-ae77-f865c6b42fb3@oracle.com>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
	<d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
	<89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>
	<851c0000-8341-294c-e62b-f15334d417a1@comcast.net>
	<4a33b5ec-816e-5ee5-ae77-f865c6b42fb3@oracle.com>
Message-ID: <3419f99e-d4d4-0802-8baa-b1fe89ddf545@comcast.net>

On 8/18/2016 4:49 PM, Valerie Peng wrote:
> Hi Mike,
>
> Thanks for the feedback and the detailed write up.
>
> The scenario here is complicated by the sensitive/non-extractable keys 
> of PKCS#11 and the fact that java key and key specification classes 
> assume all relevant values being available.
Um... I think that's true for any PublicKey, but not for Secret or 
Private keys.  At worst, the Key object is a handle for the real key 
that contains all those items, but they might not be available.  At 
best, most of those components will be available.  I say at best, 
because of the language in RSAMultiPrimePrivateCRTKey for 
getOtherPrimeInfo() which says it can return null.

> Only when all relevant values are available, then we will construct 
> the corresponding key objects. This is necessary as there are other 
> providers which may receive such keys and they can't handle keys like 
> this.

Keys can't generally move across providers AIRC?  You can try and use a 
key factory to convert them, but that's not guaranteed.  A PKCS11 
derived key isn't going to be portable to another provider without 
extraction to a keyspec in any case.

Hmm.. I went back and read the JDK8 p11 guide 
(https://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html) 
and section 3.2 gives the guidance that you only use the generic 
interfaces for unextractable keys.  I actually think that's wrong, given 
the general guidance in the JCA documentation with respect to Opaque 
Keys vs transparent KeySpecs.  (Hmm... I wonder if this guidance was in 
the originally submitted code package documentation).

Then there's the point that even a generic Public or Private key has a 
"getEncoded()" method.  *bleah*


>
> I am sure that the current PKCS11 provider code needs many 
> improvement/finer handlings. But I don't see a straightforward way of 
> "making CKA_PUBLIC_EXPONENT available" across various RSA Key classes. 
> This should be tracked in a different issue.

That's just one of the items.  As I mentioned in another email, I think 
the RSA key classes and interfaces need a bit more work and tweaking.  I 
wouldn't try and accomplish that quite yet.

>
> Given the current release schedule, the deadline for this fix (P4) is 
> coming up in 10 days and I will be on vacation next week.
>
> If you agree with the value of addressing this with the proposed 
> changes for JDK 9, then we can proceed.
> Otherwise, I will defer this bug to the update release and we can 
> spend more time to polish this.

I think you might as well go ahead with this change.  The fix you've got 
should work as long as someone who generates a RSA Key pair on a PKCS11 
which is both sensitive and unextractable doesn't try to cast the keys 
to RSAPublic or RSAPrivate.

Mike


> Valerie
>
> On 8/18/2016 8:40 AM, Michael StJohns wrote:
>> On 8/17/2016 11:36 PM, Valerie Peng wrote:
>>> Regression tests are still running, but thought that I will send the 
>>> updated webrev out and see if there are more comments.
>>>
>>> Webrev is updated at: 
>>> http://cr.openjdk.java.net/~valeriep/8078661/webrev.01/
>>>
>>> Thanks,
>>> Valerie
>> Hi Valerie -
>>
>> You know - re-reading this code I'm reminding of why PKCS11 annoys me 
>> so much.
>>
>> At line 333 (of the "new" P11Key) you grab the Token, Sensitive and 
>> Extractable values and if the private data is sensitive or not 
>> extractable you create a generic P11PrivateKey and return that.  
>> However the contract for RSAKey requires that the public modulus be 
>> returned if available, and, since its not a sensitive attribute it 
>> probably should be available.  Also, even if the key is sensitive - 
>> if its a sensitive  CRT key, then CKA_PUBLIC_EXPONENT should be 
>> available.
>>
>> That's going to be a surprise if someone tries to cast this return to 
>> an (RSAKey) or (RSAPrivateKey). _This should be changed so a key of 
>> the appropriate type is always created._
>>
>> Also, checking for CKA_EXTRACTABLE being true, doesn't actually get 
>> you access to the clear text information.  If a key is extractable, 
>> then it can be wrapped out under another key.  The components 
>> themselves aren't available.  It's possible to have a non-sensitive, 
>> non-extractable key where the components are retrievable, but the key 
>> can't be wrapped out.
>>
>>
>> (Hmm... the public exponent is in RSAPublicKey and RSAPrivateCRTKey, 
>> but should probably be in RSAKey instead).
>>
>> So:
>>
>> All RSA keys - even the sensitive private ones  - should return 
>> CKA_MODULUS.
>> All RSA Private CRT Keys - even the sensitive ones - should also 
>> return CKA_PUBLIC_EXPONENT.
>> All non-sensitive RSA Private keys - should also return 
>> CKA_PRIVATE_EXPONENT
>> All non-sensitive RSA Private CRT Keys - should also return 
>> CKA_PRIME_1, CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT_2 and 
>> CKA_COEFFICIENT.
>>
>> This is harder to do than it needs to be due to how 
>> p11_objmgt.c::Java_sun_security_pkcs11_wrapper_PKCS11_C_1GetAttributeValue 
>> is built.  At lines 248 and 270, it does a check for an error return 
>> and throws an exception if any error occurs.  However, for 
>> C_GetAttributeValue, there are a number of "non-fatal" errors that 
>> indicate either buffer size errors or sensitivity of one or more 
>> components or unavailability of one or more components.
>>> Note that the error codes CKR_ATTRIBUTE_SENSITIVE, 
>>> CKR_ATTRIBUTE_TYPE_INVALID, and CKR_BUFFER_TOO_SMALL  do not denote 
>>> true errors for *C_GetAttributeValue*. If a call to 
>>> *C_GetAttributeValue* returns any of these three values, then the 
>>> call must nonetheless have processed /every/ attribute in the 
>>> template supplied to *C_GetAttributeValue*. Each attribute in the 
>>> template whose value /can be/ returned by the call to 
>>> *C_GetAttributeValue* /will be/ returned by the call to 
>>> *C_GetAttributeValue*.
>>
>>
>>
>> If you updated this slightly - maybe by adding a new method to 
>> wrapper.PKCS11 (say GetAttributeValuesNoError) - to return the 
>> attributes it was able to get in the call with nulls elsewhere, then 
>> you could do all of the above in one pass.
>>
>> Sorry to complicate this.  Mike
>>
>> ps - I don't have a current build environment set up for the JDK, 
>> otherwise I'd code it and test it myself.  I'm happy to take a swing 
>> at it and provide you unverified code you can integrate.
>>
>>>
>>> On 8/17/2016 9:55 AM, Michael StJohns wrote:
>>>> On 8/16/2016 9:24 PM, Valerie Peng wrote:
>>>>>
>>>>> Anyone has time to review a straightforward fix? The current 
>>>>> PKCS11 code assume that if public exponent is available for RSA 
>>>>> Private Key, then it's a RSA CRT key. However, not all vendor 
>>>>> implementation works this way. Changing to a tighter check and did 
>>>>> minor code-refactoring to avoid re-retrieving the attribute values.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
>>>>>
>>>>> Thanks,
>>>>> Valerie
>>>>
>>>> Given that there's a change to PKCS11 for 2.40 that says that all 
>>>> RSA private key objects  MUST also store CKA_PUBLIC_EXPONENT, some 
>>>> change needed to be made.
>>>>
>>>> Sorry - I don't think this fix will work.  Or if its working on 
>>>> your version of PKCS11, your version of PKCS11 is doing it wrong.  
>>>> The problem is that if you specify attributes that don't exist on 
>>>> the object, the underlying PKCS11 library is supposed to return 
>>>> CKR_ATTRIBUTE_TYPE_INVALID.  And that should trigger a thrown 
>>>> exception before you ever get anything copied to your attributes.
>>>>
>>>> 1) Get modulus and private exponent first.  That gives you the 
>>>> stuff for a generic RSA private key - and if it fails, there's no 
>>>> reason to continue.
>>>>
>>>> 2) Then get the rest of the stuff.  If that fails, then you already 
>>>> have the stuff you need for a normal private key.
>>>>
>>>>
>>>>>                       boolean crtKey;
>>>>>                       try {
>>>>>                           session.token.p11.C_GetAttributeValue
>>>>>                               (session.id(), keyID, attrs2);
>>>>> - crtKey = (attrs2[0].pValue instanceof byte[]);
>>>>> + crtKey = ((attrs2[1].pValue instanceof byte[]) &&
>>>>> + (attrs2[3].pValue instanceof byte[]) &&
>>>>> + (attrs2[4].pValue instanceof byte[]) &&
>>>>> + (attrs2[5].pValue instanceof byte[]) &&
>>>>> + (attrs2[6].pValue instanceof byte[]) &&
>>>>> + (attrs2[7].pValue instanceof byte[])) ;
>>>>>                       } catch (PKCS11Exception e) {
>>>>>                           // ignore, assume not available
>>>>>                           crtKey = false;
>>>>>                       }
>>>>
>>>> // Change attrs2 so it only has the additional CRT attributes (e.g. 
>>>> delete CKA_MODULUS, CKA_PRIVATE_EXPONENT from the list
>>>>
>>>> Replace the above with
>>>>
>>>> CK_ATTRIBUTE[] attrs3 = new CK_ATTRIBUTE[] {
>>>>        new CK_ATTRIBUTE(CKA_MODULUS),
>>>>        new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT)
>>>> };
>>>> // no try block needed here - we want to throw the error if it occurs
>>>> session.token.p11.C_GetAttributeValue (session.id(), keyID, attrs3);
>>>>
>>>> // So far so good - we have the base attributes, let's see if we 
>>>> can get the additional attributes;
>>>>
>>>> try {
>>>> session.token.p11.C_GetAttributeValue(session.id(),keyID, attrs2);
>>>> } catch (PKCS11Exception e) {
>>>>    // we really should check the return value for one of the 
>>>> non-fatal values, but let's just assume its not a CRT key
>>>>    return new P11RSAPrivateNonCRTKey (session, keyID, algorithm, 
>>>> keyLength, attrs2, attrs3);
>>>> }
>>>>
>>>> // if we fall through then its a CRT key
>>>> // -- we should check for byte[] ness of each of the components, 
>>>> and throw an error if they arent - but which error?
>>>>
>>>> return new P11RSAPrivateKey (session, keyID, algorithm, keyLength, 
>>>> attrs2, attrs3);
>>>>
>>>> // there are cleanups necessary in other places.  I'd suggest 
>>>> rather than depending on the ordering of attributes, you do 
>>>> assignment by CKA_ values just so someone coming later doesn't mess 
>>>> things up by mistake. Also, a hell of a lot more readable.
>>>>
>>>> static CK_ATTRIBUTE getAttribute (CK_ATTRIBUTE[] attrs, long 
>>>> attrType) {
>>>>     for (CK_ATTRIBUTE a : attrs) {
>>>>          if (a.type == attrType)
>>>>               return a;
>>>>      }
>>>>     return null; // or throw something?
>>>> }
>>>>
>>>>
>>>> coeff = getAtttribute(attrs,CKA_COEFFICIENT).getBigInteger();
>>>>
>>>>
>>>> The other possibility is to change the C code for 
>>>> C_GetAttributeValues so it doesn't error out for the non-fatal 
>>>> error codes and instead returns a null value attribute when the 
>>>> attribute is missing.
>>>>
>>>> Mike
>>>>
>>>
>>
>

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

From valerie.peng at oracle.com  Thu Aug 18 23:55:29 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 18 Aug 2016 16:55:29 -0700
Subject: [9] RFR: 8164100:
	com/sun/crypto/provider/KeyFactory/TestProviderLeak.java fails with
	java.util.concurrent.TimeoutException
In-Reply-To: <177be901-0377-a912-6ee4-2684e31e710a@oracle.com>
References: <177be901-0377-a912-6ee4-2684e31e710a@oracle.com>
Message-ID: <6ca0ae71-0fc1-df50-1e59-a2c7806300d4@oracle.com>


Changes look fine.
Valerie

On 8/17/2016 11:29 AM, Artem Smotrakov wrote:
> Hello,
>
> Please review the following patch for 
> com/sun/crypto/provider/KeyFactory/TestProviderLeak.java test.
>
> This is a request to make the test take into account a test timeout 
> factor. Timeout factor can be specified with "-timeout" jtreg's 
> command line option. This option is used in some test runs to make 
> test runs more stable (for example, VM SQE uses it while running 
> regression tests with different JVM options).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164100
> Webrev: http://cr.openjdk.java.net/~asmotrak/8164100/webrev.00/
>
> Artem



From valerie.peng at oracle.com  Fri Aug 19 00:48:06 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 18 Aug 2016 17:48:06 -0700
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <3419f99e-d4d4-0802-8baa-b1fe89ddf545@comcast.net>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
	<d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
	<89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>
	<851c0000-8341-294c-e62b-f15334d417a1@comcast.net>
	<4a33b5ec-816e-5ee5-ae77-f865c6b42fb3@oracle.com>
	<3419f99e-d4d4-0802-8baa-b1fe89ddf545@comcast.net>
Message-ID: <e584e49a-6c50-37bc-4944-c59dd59e0f84@oracle.com>


I share your view on most things. It's just that the APIs are there 
before the PKCS11 provider is added.
So, there are some history reason as to why things are as they are today.
Re-structuring the public classes are almost impossible considering the 
compatibility impact.
However, we can explore other functional fixes if necessary.

Thanks for the review and feedback, it's very helpful,
Valerie

On 8/18/2016 2:25 PM, Michael StJohns wrote:
> On 8/18/2016 4:49 PM, Valerie Peng wrote:
>> Hi Mike,
>>
>> Thanks for the feedback and the detailed write up.
>>
>> The scenario here is complicated by the sensitive/non-extractable 
>> keys of PKCS#11 and the fact that java key and key specification 
>> classes assume all relevant values being available.
> Um... I think that's true for any PublicKey, but not for Secret or 
> Private keys.  At worst, the Key object is a handle for the real key 
> that contains all those items, but they might not be available.  At 
> best, most of those components will be available. I say at best, 
> because of the language in RSAMultiPrimePrivateCRTKey for 
> getOtherPrimeInfo() which says it can return null.
>
>> Only when all relevant values are available, then we will construct 
>> the corresponding key objects. This is necessary as there are other 
>> providers which may receive such keys and they can't handle keys like 
>> this.
>
> Keys can't generally move across providers AIRC?  You can try and use 
> a key factory to convert them, but that's not guaranteed.  A PKCS11 
> derived key isn't going to be portable to another provider without 
> extraction to a keyspec in any case.
>
> Hmm.. I went back and read the JDK8 p11 guide 
> (https://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html) 
> and section 3.2 gives the guidance that you only use the generic 
> interfaces for unextractable keys.  I actually think that's wrong, 
> given the general guidance in the JCA documentation with respect to 
> Opaque Keys vs transparent KeySpecs.  (Hmm... I wonder if this 
> guidance was in the originally submitted code package documentation).
>
> Then there's the point that even a generic Public or Private key has a 
> "getEncoded()" method.  *bleah*
>
>
>>
>> I am sure that the current PKCS11 provider code needs many 
>> improvement/finer handlings. But I don't see a straightforward way of 
>> "making CKA_PUBLIC_EXPONENT available" across various RSA Key 
>> classes. This should be tracked in a different issue.
>
> That's just one of the items.  As I mentioned in another email, I 
> think the RSA key classes and interfaces need a bit more work and 
> tweaking.  I wouldn't try and accomplish that quite yet.
>
>>
>> Given the current release schedule, the deadline for this fix (P4) is 
>> coming up in 10 days and I will be on vacation next week.
>>
>> If you agree with the value of addressing this with the proposed 
>> changes for JDK 9, then we can proceed.
>> Otherwise, I will defer this bug to the update release and we can 
>> spend more time to polish this.
>
> I think you might as well go ahead with this change.  The fix you've 
> got should work as long as someone who generates a RSA Key pair on a 
> PKCS11 which is both sensitive and unextractable doesn't try to cast 
> the keys to RSAPublic or RSAPrivate.
>
> Mike
>
>
>> Valerie
>>
>> On 8/18/2016 8:40 AM, Michael StJohns wrote:
>>> On 8/17/2016 11:36 PM, Valerie Peng wrote:
>>>> Regression tests are still running, but thought that I will send 
>>>> the updated webrev out and see if there are more comments.
>>>>
>>>> Webrev is updated at: 
>>>> http://cr.openjdk.java.net/~valeriep/8078661/webrev.01/
>>>>
>>>> Thanks,
>>>> Valerie
>>> Hi Valerie -
>>>
>>> You know - re-reading this code I'm reminding of why PKCS11 annoys 
>>> me so much.
>>>
>>> At line 333 (of the "new" P11Key) you grab the Token, Sensitive and 
>>> Extractable values and if the private data is sensitive or not 
>>> extractable you create a generic P11PrivateKey and return that.  
>>> However the contract for RSAKey requires that the public modulus be 
>>> returned if available, and, since its not a sensitive attribute it 
>>> probably should be available.  Also, even if the key is sensitive - 
>>> if its a sensitive  CRT key, then CKA_PUBLIC_EXPONENT should be 
>>> available.
>>>
>>> That's going to be a surprise if someone tries to cast this return 
>>> to an (RSAKey) or (RSAPrivateKey). _This should be changed so a key 
>>> of the appropriate type is always created._
>>>
>>> Also, checking for CKA_EXTRACTABLE being true, doesn't actually get 
>>> you access to the clear text information.  If a key is extractable, 
>>> then it can be wrapped out under another key.  The components 
>>> themselves aren't available.  It's possible to have a non-sensitive, 
>>> non-extractable key where the components are retrievable, but the 
>>> key can't be wrapped out.
>>>
>>>
>>> (Hmm... the public exponent is in RSAPublicKey and RSAPrivateCRTKey, 
>>> but should probably be in RSAKey instead).
>>>
>>> So:
>>>
>>> All RSA keys - even the sensitive private ones  - should return 
>>> CKA_MODULUS.
>>> All RSA Private CRT Keys - even the sensitive ones - should also 
>>> return CKA_PUBLIC_EXPONENT.
>>> All non-sensitive RSA Private keys - should also return 
>>> CKA_PRIVATE_EXPONENT
>>> All non-sensitive RSA Private CRT Keys - should also return 
>>> CKA_PRIME_1, CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT_2 and 
>>> CKA_COEFFICIENT.
>>>
>>> This is harder to do than it needs to be due to how 
>>> p11_objmgt.c::Java_sun_security_pkcs11_wrapper_PKCS11_C_1GetAttributeValue 
>>> is built.  At lines 248 and 270, it does a check for an error return 
>>> and throws an exception if any error occurs.  However, for 
>>> C_GetAttributeValue, there are a number of "non-fatal" errors that 
>>> indicate either buffer size errors or sensitivity of one or more 
>>> components or unavailability of one or more components.
>>>> Note that the error codes CKR_ATTRIBUTE_SENSITIVE, 
>>>> CKR_ATTRIBUTE_TYPE_INVALID, and CKR_BUFFER_TOO_SMALL  do not denote 
>>>> true errors for *C_GetAttributeValue*. If a call to 
>>>> *C_GetAttributeValue* returns any of these three values, then the 
>>>> call must nonetheless have processed /every/ attribute in the 
>>>> template supplied to *C_GetAttributeValue*.  Each attribute in the 
>>>> template whose value /can be/ returned by the call to 
>>>> *C_GetAttributeValue* /will be/ returned by the call to 
>>>> *C_GetAttributeValue*.
>>>
>>>
>>>
>>> If you updated this slightly - maybe by adding a new method to 
>>> wrapper.PKCS11 (say GetAttributeValuesNoError) - to return the 
>>> attributes it was able to get in the call with nulls elsewhere, then 
>>> you could do all of the above in one pass.
>>>
>>> Sorry to complicate this.  Mike
>>>
>>> ps - I don't have a current build environment set up for the JDK, 
>>> otherwise I'd code it and test it myself.  I'm happy to take a swing 
>>> at it and provide you unverified code you can integrate.
>>>
>>>>
>>>> On 8/17/2016 9:55 AM, Michael StJohns wrote:
>>>>> On 8/16/2016 9:24 PM, Valerie Peng wrote:
>>>>>>
>>>>>> Anyone has time to review a straightforward fix? The current 
>>>>>> PKCS11 code assume that if public exponent is available for RSA 
>>>>>> Private Key, then it's a RSA CRT key. However, not all vendor 
>>>>>> implementation works this way. Changing to a tighter check and 
>>>>>> did minor code-refactoring to avoid re-retrieving the attribute 
>>>>>> values.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
>>>>>>
>>>>>> Thanks,
>>>>>> Valerie
>>>>>
>>>>> Given that there's a change to PKCS11 for 2.40 that says that all 
>>>>> RSA private key objects  MUST also store CKA_PUBLIC_EXPONENT, some 
>>>>> change needed to be made.
>>>>>
>>>>> Sorry - I don't think this fix will work.  Or if its working on 
>>>>> your version of PKCS11, your version of PKCS11 is doing it wrong.  
>>>>> The problem is that if you specify attributes that don't exist on 
>>>>> the object, the underlying PKCS11 library is supposed to return 
>>>>> CKR_ATTRIBUTE_TYPE_INVALID.  And that should trigger a thrown 
>>>>> exception before you ever get anything copied to your attributes.
>>>>>
>>>>> 1) Get modulus and private exponent first.  That gives you the 
>>>>> stuff for a generic RSA private key - and if it fails, there's no 
>>>>> reason to continue.
>>>>>
>>>>> 2) Then get the rest of the stuff.  If that fails, then you 
>>>>> already have the stuff you need for a normal private key.
>>>>>
>>>>>
>>>>>>                       boolean crtKey;
>>>>>>                       try {
>>>>>>                           session.token.p11.C_GetAttributeValue
>>>>>>                               (session.id(), keyID, attrs2);
>>>>>> - crtKey = (attrs2[0].pValue instanceof byte[]);
>>>>>> + crtKey = ((attrs2[1].pValue instanceof byte[]) &&
>>>>>> + (attrs2[3].pValue instanceof byte[]) &&
>>>>>> + (attrs2[4].pValue instanceof byte[]) &&
>>>>>> + (attrs2[5].pValue instanceof byte[]) &&
>>>>>> + (attrs2[6].pValue instanceof byte[]) &&
>>>>>> + (attrs2[7].pValue instanceof byte[])) ;
>>>>>>                       } catch (PKCS11Exception e) {
>>>>>>                           // ignore, assume not available
>>>>>>                           crtKey = false;
>>>>>>                       }
>>>>>
>>>>> // Change attrs2 so it only has the additional CRT attributes 
>>>>> (e.g. delete CKA_MODULUS, CKA_PRIVATE_EXPONENT from the list
>>>>>
>>>>> Replace the above with
>>>>>
>>>>> CK_ATTRIBUTE[] attrs3 = new CK_ATTRIBUTE[] {
>>>>>        new CK_ATTRIBUTE(CKA_MODULUS),
>>>>>        new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT)
>>>>> };
>>>>> // no try block needed here - we want to throw the error if it occurs
>>>>> session.token.p11.C_GetAttributeValue (session.id(), keyID, attrs3);
>>>>>
>>>>> // So far so good - we have the base attributes, let's see if we 
>>>>> can get the additional attributes;
>>>>>
>>>>> try {
>>>>> session.token.p11.C_GetAttributeValue(session.id(),keyID, attrs2);
>>>>> } catch (PKCS11Exception e) {
>>>>>    // we really should check the return value for one of the 
>>>>> non-fatal values, but let's just assume its not a CRT key
>>>>>    return new P11RSAPrivateNonCRTKey (session, keyID, algorithm, 
>>>>> keyLength, attrs2, attrs3);
>>>>> }
>>>>>
>>>>> // if we fall through then its a CRT key
>>>>> // -- we should check for byte[] ness of each of the components, 
>>>>> and throw an error if they arent - but which error?
>>>>>
>>>>> return new P11RSAPrivateKey (session, keyID, algorithm, keyLength, 
>>>>> attrs2, attrs3);
>>>>>
>>>>> // there are cleanups necessary in other places.  I'd suggest 
>>>>> rather than depending on the ordering of attributes, you do 
>>>>> assignment by CKA_ values just so someone coming later doesn't 
>>>>> mess things up by mistake. Also, a hell of a lot more readable.
>>>>>
>>>>> static CK_ATTRIBUTE getAttribute (CK_ATTRIBUTE[] attrs, long 
>>>>> attrType) {
>>>>>     for (CK_ATTRIBUTE a : attrs) {
>>>>>          if (a.type == attrType)
>>>>>               return a;
>>>>>      }
>>>>>     return null; // or throw something?
>>>>> }
>>>>>
>>>>>
>>>>> coeff = getAtttribute(attrs,CKA_COEFFICIENT).getBigInteger();
>>>>>
>>>>>
>>>>> The other possibility is to change the C code for 
>>>>> C_GetAttributeValues so it doesn't error out for the non-fatal 
>>>>> error codes and instead returns a null value attribute when the 
>>>>> attribute is missing.
>>>>>
>>>>> Mike
>>>>>
>>>>
>>>
>>
>

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

From xuelei.fan at oracle.com  Fri Aug 19 00:48:10 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 19 Aug 2016 08:48:10 +0800
Subject: [9] RFR 8164398: Add test
	sun/security/krb5/auto/EmptyPassword.java to ProblemList
In-Reply-To: <2D473677-B0D3-464C-B854-846EB5412C6A@oracle.com>
References: <2D473677-B0D3-464C-B854-846EB5412C6A@oracle.com>
Message-ID: <fcb2387d-99a6-56b3-bc0b-23a3d65fb8b1@oracle.com>

Looks fine to me.

Xuelei

On 8/19/2016 5:17 AM, Vincent Ryan wrote:
> Please approve this change to add a failing test to
> jdk/test/ProblemList.txt so we can investigate further.
> Thanks.
>
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -289,6 +289,8 @@
>
>  sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java         8161232
> macosx-all
>
> +sun/security/krb5/auto/EmptyPassword.java                       8164307
> solaris-all
> +
>  ############################################################################
>
>  # jdk_sound


From weijun.wang at oracle.com  Fri Aug 19 02:17:27 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 19 Aug 2016 10:17:27 +0800
Subject: RFR: (XS) 8162916:Test sun/security/krb5/auto/UnboundSSL.java
	fails
In-Reply-To: <f5f69f07-c1d4-31c6-6fa3-2061a679ad6b@oracle.com>
References: <57B4969B.4030904@oracle.com>
	<0ee91f5b-bcd5-7c93-d99d-13c00797d8f3@oracle.com>
	<57B49B18.3030505@oracle.com>
	<27699872-c744-7ae6-249b-c3562c5a882e@oracle.com>
	<dff2b1b9-72aa-7c6e-fe27-bb8b1112967e@oracle.com>
	<f5f69f07-c1d4-31c6-6fa3-2061a679ad6b@oracle.com>
Message-ID: <692b286f-3f1d-b7d2-3828-14b645faf89f@oracle.com>

This is great. Change looks fine to me.

Thanks
Max

On 8/18/2016 23:28, Se?n Coffey wrote:
> Thanks for the tip Artem, Max. No need to modify the policy file then.
> Below is the new suggested patch for jdk8u-dev. JPRT results are good.
>
> diff --git a/test/sun/security/krb5/auto/UnboundSSL.java
> b/test/sun/security/krb5/auto/UnboundSSL.java
> --- a/test/sun/security/krb5/auto/UnboundSSL.java
> +++ b/test/sun/security/krb5/auto/UnboundSSL.java
> @@ -34,9 +34,9 @@
>   * @bug 8025123
>   * @summary Checks if an unbound server can handle connections
>   *          only for allowed service principals
> - * @run main/othervm/policy=unbound.ssl.policy UnboundSSL
> + * @run main/othervm/java.security.policy=unbound.ssl.policy UnboundSSL
>   *                              unbound.ssl.jaas.conf server_star
> - * @run main/othervm/policy=unbound.ssl.policy UnboundSSL
> + * @run main/othervm/java.security.policy=unbound.ssl.policy UnboundSSL
>   *                              unbound.ssl.jaas.conf
> server_multiple_principals
>   */
>  public class UnboundSSL {
>
> Regards,
> Sean.
>
> On 18/08/2016 04:11, Weijun Wang wrote:
>>>>> If I recall correctly, there should be a way to specify a policy file
>>>>> in @run without overriding the default one. May be it is "@run
>>>>> main/othervm/java.security.policy=unbound.ssl.policy_new"
>>
>> Yes, I think this should work. I've also just learned about it and
>> don't know from which jtreg it is supported. Hopefully the
>> minimized-required version of jtreg for jdk8u already has it.
>>
>> --Max
>>
>


From weijun.wang at oracle.com  Fri Aug 19 06:34:46 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 19 Aug 2016 14:34:46 +0800
Subject: RFR 8164437: Test for JDK-8042900
Message-ID: <4d0f4f0e-605a-5c6e-99a3-c3e190e9711d@oracle.com>

Please review the code change at

    http://cr.openjdk.java.net/~weijun/8164437/webrev.00

The updated test shows that with the jdk.security.jgss package, the 
result of GSSManager::createContext is of an enhanced type.

Thanks
Max


From xuelei.fan at oracle.com  Fri Aug 19 08:48:39 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 19 Aug 2016 16:48:39 +0800
Subject: RFR 8164437: Test for JDK-8042900
In-Reply-To: <4d0f4f0e-605a-5c6e-99a3-c3e190e9711d@oracle.com>
References: <4d0f4f0e-605a-5c6e-99a3-c3e190e9711d@oracle.com>
Message-ID: <dea56b0b-130c-d333-528d-299aa7a6309b@oracle.com>

Looks fine to me.

BTW, why not check the class name right after the object is created?

Xuelei

On 8/19/2016 2:34 PM, Weijun Wang wrote:
> Please review the code change at
>
>    http://cr.openjdk.java.net/~weijun/8164437/webrev.00
>
> The updated test shows that with the jdk.security.jgss package, the
> result of GSSManager::createContext is of an enhanced type.
>
> Thanks
> Max


From weijun.wang at oracle.com  Fri Aug 19 11:47:04 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 19 Aug 2016 19:47:04 +0800
Subject: RFR 8164437: Test for JDK-8042900
In-Reply-To: <dea56b0b-130c-d333-528d-299aa7a6309b@oracle.com>
References: <4d0f4f0e-605a-5c6e-99a3-c3e190e9711d@oracle.com>
	<dea56b0b-130c-d333-528d-299aa7a6309b@oracle.com>
Message-ID: <9d7df04c-64b8-c338-33d2-d074e05e1803@oracle.com>


On 8/19/2016 16:48, Xuelei Fan wrote:
> Looks fine to me.
>
> BTW, why not check the class name right after the object is created?

This is just a small enhancement to an existing test, and I don't want 
to break the existing block. I added a comment there.

And I've enhanced the test a little to compare with module names, this 
looks more natural.

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

Thanks
Max


>
> Xuelei
>
> On 8/19/2016 2:34 PM, Weijun Wang wrote:
>> Please review the code change at
>>
>>    http://cr.openjdk.java.net/~weijun/8164437/webrev.00
>>
>> The updated test shows that with the jdk.security.jgss package, the
>> result of GSSManager::createContext is of an enhanced type.
>>
>> Thanks
>> Max


From xuelei.fan at oracle.com  Fri Aug 19 13:11:56 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 19 Aug 2016 21:11:56 +0800
Subject: RFR 8164437: Test for JDK-8042900
In-Reply-To: <9d7df04c-64b8-c338-33d2-d074e05e1803@oracle.com>
References: <4d0f4f0e-605a-5c6e-99a3-c3e190e9711d@oracle.com>
	<dea56b0b-130c-d333-528d-299aa7a6309b@oracle.com>
	<9d7df04c-64b8-c338-33d2-d074e05e1803@oracle.com>
Message-ID: <1da01c0e-0b01-35c8-12cc-56ca7f80c4bc@oracle.com>

OK.

Xuelei

On 8/19/2016 7:47 PM, Weijun Wang wrote:
>
> On 8/19/2016 16:48, Xuelei Fan wrote:
>> Looks fine to me.
>>
>> BTW, why not check the class name right after the object is created?
>
> This is just a small enhancement to an existing test, and I don't want
> to break the existing block. I added a comment there.
>
> And I've enhanced the test a little to compare with module names, this
> looks more natural.
>
> http://cr.openjdk.java.net/~weijun/8164437/webrev.01
>
> Thanks
> Max
>
>
>>
>> Xuelei
>>
>> On 8/19/2016 2:34 PM, Weijun Wang wrote:
>>> Please review the code change at
>>>
>>>    http://cr.openjdk.java.net/~weijun/8164437/webrev.00
>>>
>>> The updated test shows that with the jdk.security.jgss package, the
>>> result of GSSManager::createContext is of an enhanced type.
>>>
>>> Thanks
>>> Max


From sean.mullan at oracle.com  Fri Aug 19 14:25:48 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 19 Aug 2016 10:25:48 -0400
Subject: RFR: 8164397: Provide javadoc descriptions for jdk.security.auth,
	jdk.security.jgss modules
Message-ID: <b22492c9-8a19-c061-5707-f8975b0a7cec@oracle.com>

Please review this docs-only fix to provide descriptions for the 
jdk.security.auth and jdk.security.jgss modules:

diff -r 657a5b92e26e src/jdk.security.auth/share/classes/module-info.java
--- a/src/jdk.security.auth/share/classes/module-info.java	Fri Aug 19 
13:50:03 2016 +0200
+++ b/src/jdk.security.auth/share/classes/module-info.java	Fri Aug 19 
10:24:47 2016 -0400
@@ -1,3 +1,3 @@
  /*
- * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
@@ -25,2 +25,6 @@

+/**
+ * Contains the implementation of the javax.security.auth.* interfaces and
+ * authentication modules.
+ */
  module jdk.security.auth {
diff -r 657a5b92e26e src/jdk.security.jgss/share/classes/module-info.java
--- a/src/jdk.security.jgss/share/classes/module-info.java	Fri Aug 19 
13:50:03 2016 +0200
+++ b/src/jdk.security.jgss/share/classes/module-info.java	Fri Aug 19 
10:24:47 2016 -0400
@@ -1,3 +1,3 @@
  /*
- * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
@@ -25,2 +25,6 @@

+/**
+ * Defines Java extensions to the GSS-API and an implementation of the SASL
+ * GSSAPI mechanism.
+ */
  module jdk.security.jgss {


--Sean


From xuelei.fan at oracle.com  Fri Aug 19 15:11:59 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 19 Aug 2016 23:11:59 +0800
Subject: RFR: 8164397: Provide javadoc descriptions for jdk.security.auth, 
	jdk.security.jgss modules
In-Reply-To: <b22492c9-8a19-c061-5707-f8975b0a7cec@oracle.com>
References: <b22492c9-8a19-c061-5707-f8975b0a7cec@oracle.com>
Message-ID: <dde526f5-5b05-99a2-81cf-795d4c6a9ce8@oracle.com>

Looks fine to me.

Xuelei

On 8/19/2016 10:25 PM, Sean Mullan wrote:
> Please review this docs-only fix to provide descriptions for the
> jdk.security.auth and jdk.security.jgss modules:
>
> diff -r 657a5b92e26e src/jdk.security.auth/share/classes/module-info.java
> --- a/src/jdk.security.auth/share/classes/module-info.java    Fri Aug 19
> 13:50:03 2016 +0200
> +++ b/src/jdk.security.auth/share/classes/module-info.java    Fri Aug 19
> 10:24:47 2016 -0400
> @@ -1,3 +1,3 @@
>  /*
> - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> @@ -25,2 +25,6 @@
>
> +/**
> + * Contains the implementation of the javax.security.auth.* interfaces and
> + * authentication modules.
> + */
>  module jdk.security.auth {
> diff -r 657a5b92e26e src/jdk.security.jgss/share/classes/module-info.java
> --- a/src/jdk.security.jgss/share/classes/module-info.java    Fri Aug 19
> 13:50:03 2016 +0200
> +++ b/src/jdk.security.jgss/share/classes/module-info.java    Fri Aug 19
> 10:24:47 2016 -0400
> @@ -1,3 +1,3 @@
>  /*
> - * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2014, 2016, Oracle and/or its affiliates. All rights
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> @@ -25,2 +25,6 @@
>
> +/**
> + * Defines Java extensions to the GSS-API and an implementation of the
> SASL
> + * GSSAPI mechanism.
> + */
>  module jdk.security.jgss {
>
>
> --Sean


From mstjohns at comcast.net  Fri Aug 19 16:50:46 2016
From: mstjohns at comcast.net (Michael StJohns)
Date: Fri, 19 Aug 2016 12:50:46 -0400
Subject: [9] RFR 8078661: [SunPKCS11] Fails to cast into RSAPrivateCrtKey
	after RSA KeyPair Generation
In-Reply-To: <e584e49a-6c50-37bc-4944-c59dd59e0f84@oracle.com>
References: <f2065a91-b1bd-f55b-7e1f-055752fcdfe9@oracle.com>
	<d605af02-3f3b-8fb5-4bbd-ebbd836457cc@comcast.net>
	<89d1e859-a988-627d-6b7c-c5ad6f062f18@oracle.com>
	<851c0000-8341-294c-e62b-f15334d417a1@comcast.net>
	<4a33b5ec-816e-5ee5-ae77-f865c6b42fb3@oracle.com>
	<3419f99e-d4d4-0802-8baa-b1fe89ddf545@comcast.net>
	<e584e49a-6c50-37bc-4944-c59dd59e0f84@oracle.com>
Message-ID: <5daa9d8a-d3bc-0507-a366-baec6a8e4f22@comcast.net>

On 8/18/2016 8:48 PM, Valerie Peng wrote:
>
>
> I share your view on most things. It's just that the APIs are there 
> before the PKCS11 provider is added.
> So, there are some history reason as to why things are as they are today.
> Re-structuring the public classes are almost impossible considering 
> the compatibility impact.
> However, we can explore other functional fixes if necessary.

I went and did some document archeology and based on various versions of 
RSA and PKCS11 and other APIs available around 1995-96, I would say that 
the Java API for RSA objects was originally based on the PKCS11 API 
rather than the original RSA documentation.  The original RSA docs all 
included the public exponent as part of the Private Key.  For some 
reason, PKCS11 did not.

For RSAMultiPrimePrivateCrtKey - which appears to have been added in 1.3 
- I have no idea why this wasn't subclassed from RSAPrivateCrtKey 
instead of RSAPrivateKey.

I think the compatibility issues can be managed.  Mostly, the fields and 
methods won't change except for RSAPrivateKey and RSAPrivateKeySpec.  
And for those you can use:

    default public BigInteger getPublicExponent() {
        return null;
    }

to keep from blowing up existing implementations.

In any event, that's a different problem than the current one.

>
> Thanks for the review and feedback, it's very helpful,

You're welcome - Mike

> Valerie
>
> On 8/18/2016 2:25 PM, Michael StJohns wrote:
>> On 8/18/2016 4:49 PM, Valerie Peng wrote:
>>> Hi Mike,
>>>
>>> Thanks for the feedback and the detailed write up.
>>>
>>> The scenario here is complicated by the sensitive/non-extractable 
>>> keys of PKCS#11 and the fact that java key and key specification 
>>> classes assume all relevant values being available.
>> Um... I think that's true for any PublicKey, but not for Secret or 
>> Private keys.  At worst, the Key object is a handle for the real key 
>> that contains all those items, but they might not be available.  At 
>> best, most of those components will be available.  I say at best, 
>> because of the language in RSAMultiPrimePrivateCRTKey for 
>> getOtherPrimeInfo() which says it can return null.
>>
>>> Only when all relevant values are available, then we will construct 
>>> the corresponding key objects. This is necessary as there are other 
>>> providers which may receive such keys and they can't handle keys 
>>> like this.
>>
>> Keys can't generally move across providers AIRC?  You can try and use 
>> a key factory to convert them, but that's not guaranteed.  A PKCS11 
>> derived key isn't going to be portable to another provider without 
>> extraction to a keyspec in any case.
>>
>> Hmm.. I went back and read the JDK8 p11 guide 
>> (https://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html) 
>> and section 3.2 gives the guidance that you only use the generic 
>> interfaces for unextractable keys.  I actually think that's wrong, 
>> given the general guidance in the JCA documentation with respect to 
>> Opaque Keys vs transparent KeySpecs.  (Hmm... I wonder if this 
>> guidance was in the originally submitted code package documentation).
>>
>> Then there's the point that even a generic Public or Private key has 
>> a "getEncoded()" method.  *bleah*
>>
>>
>>>
>>> I am sure that the current PKCS11 provider code needs many 
>>> improvement/finer handlings. But I don't see a straightforward way 
>>> of "making CKA_PUBLIC_EXPONENT available" across various RSA Key 
>>> classes. This should be tracked in a different issue.
>>
>> That's just one of the items.  As I mentioned in another email, I 
>> think the RSA key classes and interfaces need a bit more work and 
>> tweaking.  I wouldn't try and accomplish that quite yet.
>>
>>>
>>> Given the current release schedule, the deadline for this fix (P4) 
>>> is coming up in 10 days and I will be on vacation next week.
>>>
>>> If you agree with the value of addressing this with the proposed 
>>> changes for JDK 9, then we can proceed.
>>> Otherwise, I will defer this bug to the update release and we can 
>>> spend more time to polish this.
>>
>> I think you might as well go ahead with this change.  The fix you've 
>> got should work as long as someone who generates a RSA Key pair on a 
>> PKCS11 which is both sensitive and unextractable doesn't try to cast 
>> the keys to RSAPublic or RSAPrivate.
>>
>> Mike
>>
>>
>>> Valerie
>>>
>>> On 8/18/2016 8:40 AM, Michael StJohns wrote:
>>>> On 8/17/2016 11:36 PM, Valerie Peng wrote:
>>>>> Regression tests are still running, but thought that I will send 
>>>>> the updated webrev out and see if there are more comments.
>>>>>
>>>>> Webrev is updated at: 
>>>>> http://cr.openjdk.java.net/~valeriep/8078661/webrev.01/
>>>>>
>>>>> Thanks,
>>>>> Valerie
>>>> Hi Valerie -
>>>>
>>>> You know - re-reading this code I'm reminding of why PKCS11 annoys 
>>>> me so much.
>>>>
>>>> At line 333 (of the "new" P11Key) you grab the Token, Sensitive and 
>>>> Extractable values and if the private data is sensitive or not 
>>>> extractable you create a generic P11PrivateKey and return that.  
>>>> However the contract for RSAKey requires that the public modulus be 
>>>> returned if available, and, since its not a sensitive attribute it 
>>>> probably should be available.  Also, even if the key is sensitive - 
>>>> if its a sensitive  CRT key, then CKA_PUBLIC_EXPONENT should be 
>>>> available.
>>>>
>>>> That's going to be a surprise if someone tries to cast this return 
>>>> to an (RSAKey) or (RSAPrivateKey). _This should be changed so a key 
>>>> of the appropriate type is always created._
>>>>
>>>> Also, checking for CKA_EXTRACTABLE being true, doesn't actually get 
>>>> you access to the clear text information.  If a key is extractable, 
>>>> then it can be wrapped out under another key.  The components 
>>>> themselves aren't available.  It's possible to have a 
>>>> non-sensitive, non-extractable key where the components are 
>>>> retrievable, but the key can't be wrapped out.
>>>>
>>>>
>>>> (Hmm... the public exponent is in RSAPublicKey and 
>>>> RSAPrivateCRTKey, but should probably be in RSAKey instead).
>>>>
>>>> So:
>>>>
>>>> All RSA keys - even the sensitive private ones  - should return 
>>>> CKA_MODULUS.
>>>> All RSA Private CRT Keys - even the sensitive ones - should also 
>>>> return CKA_PUBLIC_EXPONENT.
>>>> All non-sensitive RSA Private keys - should also return 
>>>> CKA_PRIVATE_EXPONENT
>>>> All non-sensitive RSA Private CRT Keys - should also return 
>>>> CKA_PRIME_1, CKA_PRIME_2, CKA_EXPONENT_1, CKA_EXPONENT_2 and 
>>>> CKA_COEFFICIENT.
>>>>
>>>> This is harder to do than it needs to be due to how 
>>>> p11_objmgt.c::Java_sun_security_pkcs11_wrapper_PKCS11_C_1GetAttributeValue 
>>>> is built.  At lines 248 and 270, it does a check for an error 
>>>> return and throws an exception if any error occurs. However, for 
>>>> C_GetAttributeValue, there are a number of "non-fatal" errors that 
>>>> indicate either buffer size errors or sensitivity of one or more 
>>>> components or unavailability of one or more components.
>>>>> Note that the error codes CKR_ATTRIBUTE_SENSITIVE, 
>>>>> CKR_ATTRIBUTE_TYPE_INVALID, and CKR_BUFFER_TOO_SMALL  do not 
>>>>> denote true errors for *C_GetAttributeValue*. If a call to 
>>>>> *C_GetAttributeValue* returns any of these three values, then the 
>>>>> call must nonetheless have processed /every/ attribute in the 
>>>>> template supplied to *C_GetAttributeValue*.  Each attribute in the 
>>>>> template whose value /can be/ returned by the call to 
>>>>> *C_GetAttributeValue* /will be/ returned by the call to 
>>>>> *C_GetAttributeValue*.
>>>>
>>>>
>>>>
>>>> If you updated this slightly - maybe by adding a new method to 
>>>> wrapper.PKCS11 (say GetAttributeValuesNoError) - to return the 
>>>> attributes it was able to get in the call with nulls elsewhere, 
>>>> then you could do all of the above in one pass.
>>>>
>>>> Sorry to complicate this.  Mike
>>>>
>>>> ps - I don't have a current build environment set up for the JDK, 
>>>> otherwise I'd code it and test it myself.  I'm happy to take a 
>>>> swing at it and provide you unverified code you can integrate.
>>>>
>>>>>
>>>>> On 8/17/2016 9:55 AM, Michael StJohns wrote:
>>>>>> On 8/16/2016 9:24 PM, Valerie Peng wrote:
>>>>>>>
>>>>>>> Anyone has time to review a straightforward fix? The current 
>>>>>>> PKCS11 code assume that if public exponent is available for RSA 
>>>>>>> Private Key, then it's a RSA CRT key. However, not all vendor 
>>>>>>> implementation works this way. Changing to a tighter check and 
>>>>>>> did minor code-refactoring to avoid re-retrieving the attribute 
>>>>>>> values.
>>>>>>>
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8078661
>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8078661/webrev.00/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Valerie
>>>>>>
>>>>>> Given that there's a change to PKCS11 for 2.40 that says that all 
>>>>>> RSA private key objects  MUST also store CKA_PUBLIC_EXPONENT, 
>>>>>> some change needed to be made.
>>>>>>
>>>>>> Sorry - I don't think this fix will work.  Or if its working on 
>>>>>> your version of PKCS11, your version of PKCS11 is doing it 
>>>>>> wrong.  The problem is that if you specify attributes that don't 
>>>>>> exist on the object, the underlying PKCS11 library is supposed to 
>>>>>> return CKR_ATTRIBUTE_TYPE_INVALID.  And that should trigger a 
>>>>>> thrown exception before you ever get anything copied to your 
>>>>>> attributes.
>>>>>>
>>>>>> 1) Get modulus and private exponent first.  That gives you the 
>>>>>> stuff for a generic RSA private key - and if it fails, there's no 
>>>>>> reason to continue.
>>>>>>
>>>>>> 2) Then get the rest of the stuff.  If that fails, then you 
>>>>>> already have the stuff you need for a normal private key.
>>>>>>
>>>>>>
>>>>>>>                       boolean crtKey;
>>>>>>>                       try {
>>>>>>>                           session.token.p11.C_GetAttributeValue
>>>>>>>                               (session.id(), keyID, attrs2);
>>>>>>> - crtKey = (attrs2[0].pValue instanceof byte[]);
>>>>>>> + crtKey = ((attrs2[1].pValue instanceof byte[]) &&
>>>>>>> + (attrs2[3].pValue instanceof byte[]) &&
>>>>>>> + (attrs2[4].pValue instanceof byte[]) &&
>>>>>>> + (attrs2[5].pValue instanceof byte[]) &&
>>>>>>> + (attrs2[6].pValue instanceof byte[]) &&
>>>>>>> + (attrs2[7].pValue instanceof byte[])) ;
>>>>>>>                       } catch (PKCS11Exception e) {
>>>>>>>                           // ignore, assume not available
>>>>>>>                           crtKey = false;
>>>>>>>                       }
>>>>>>
>>>>>> // Change attrs2 so it only has the additional CRT attributes 
>>>>>> (e.g. delete CKA_MODULUS, CKA_PRIVATE_EXPONENT from the list
>>>>>>
>>>>>> Replace the above with
>>>>>>
>>>>>> CK_ATTRIBUTE[] attrs3 = new CK_ATTRIBUTE[] {
>>>>>>        new CK_ATTRIBUTE(CKA_MODULUS),
>>>>>>        new CK_ATTRIBUTE(CKA_PRIVATE_EXPONENT)
>>>>>> };
>>>>>> // no try block needed here - we want to throw the error if it occurs
>>>>>> session.token.p11.C_GetAttributeValue (session.id(), keyID, attrs3);
>>>>>>
>>>>>> // So far so good - we have the base attributes, let's see if we 
>>>>>> can get the additional attributes;
>>>>>>
>>>>>> try {
>>>>>> session.token.p11.C_GetAttributeValue(session.id(),keyID, attrs2);
>>>>>> } catch (PKCS11Exception e) {
>>>>>>    // we really should check the return value for one of the 
>>>>>> non-fatal values, but let's just assume its not a CRT key
>>>>>>    return new P11RSAPrivateNonCRTKey (session, keyID, algorithm, 
>>>>>> keyLength, attrs2, attrs3);
>>>>>> }
>>>>>>
>>>>>> // if we fall through then its a CRT key
>>>>>> // -- we should check for byte[] ness of each of the components, 
>>>>>> and throw an error if they arent - but which error?
>>>>>>
>>>>>> return new P11RSAPrivateKey (session, keyID, algorithm, 
>>>>>> keyLength, attrs2, attrs3);
>>>>>>
>>>>>> // there are cleanups necessary in other places.  I'd suggest 
>>>>>> rather than depending on the ordering of attributes, you do 
>>>>>> assignment by CKA_ values just so someone coming later doesn't 
>>>>>> mess things up by mistake.  Also, a hell of a lot more readable.
>>>>>>
>>>>>> static CK_ATTRIBUTE getAttribute (CK_ATTRIBUTE[] attrs, long 
>>>>>> attrType) {
>>>>>>     for (CK_ATTRIBUTE a : attrs) {
>>>>>>          if (a.type == attrType)
>>>>>>               return a;
>>>>>>      }
>>>>>>     return null; // or throw something?
>>>>>> }
>>>>>>
>>>>>>
>>>>>> coeff = getAtttribute(attrs,CKA_COEFFICIENT).getBigInteger();
>>>>>>
>>>>>>
>>>>>> The other possibility is to change the C code for 
>>>>>> C_GetAttributeValues so it doesn't error out for the non-fatal 
>>>>>> error codes and instead returns a null value attribute when the 
>>>>>> attribute is missing.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From vincent.x.ryan at oracle.com  Fri Aug 19 16:57:45 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 19 Aug 2016 17:57:45 +0100
Subject: [9] RFR 8164494: SunPKCS11-Solaris requires a non-empty PBE password
Message-ID: <3CBF08E6-317B-4554-991B-8AE522972749@oracle.com>

Please review this fix to PBE key derivation function which detects when a non-empty password
is supplied to the SunPKCS11-Solaris JCE provider and fails over to the SunJCE provider instead.
Thanks.

Bug: https://bugs.openjdk.java.net/browse/JDK-8164494
Webrev: http://cr.openjdk.java.net/~vinnie/8164494/webrev.00/ <http://cr.openjdk.java.net/~vinnie/8164494/webrev.00/>

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

From valerie.peng at oracle.com  Fri Aug 19 21:18:47 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 19 Aug 2016 14:18:47 -0700
Subject: [9] RFR 8164494: SunPKCS11-Solaris requires a non-empty PBE
	password
In-Reply-To: <3CBF08E6-317B-4554-991B-8AE522972749@oracle.com>
References: <3CBF08E6-317B-4554-991B-8AE522972749@oracle.com>
Message-ID: <5eb276dc-ace7-9929-f5dc-cd4199ec0ee9@oracle.com>

Looks fine to me.
Thanks,
Valerie

On 8/19/2016 9:57 AM, Vincent Ryan wrote:
> Please review this fix to PBE key derivation function which detects 
> when a non-empty password
> is supplied to the SunPKCS11-Solaris JCE provider and fails over to 
> the SunJCE provider instead.
> Thanks.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8164494
> Webrev: http://cr.openjdk.java.net/~vinnie/8164494/webrev.00/ 
> <http://cr.openjdk.java.net/%7Evinnie/8164494/webrev.00/>
>



From mandy.chung at oracle.com  Fri Aug 19 22:02:48 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 19 Aug 2016 15:02:48 -0700
Subject: RFR: 8163126 Wrong @modules in some of jdk/* tests
In-Reply-To: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>
References: <242C9427-C6B3-4E06-AA8A-708AA670CADE@oracle.com>
Message-ID: <9E7EBD37-4D3F-4B62-A34A-BC998D5F2A6D@oracle.com>


> On Aug 16, 2016, at 10:17 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> 
> Hi.
> 
> Please review fixes related to module dependencies in a few jdk tests:
> http://cr.openjdk.java.net/~shurailine/8163126/webrev.00/index.html

Looks okay.  I will sponsor this patch for you.

Mandy

From weijun.wang at oracle.com  Sat Aug 20 00:19:11 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 20 Aug 2016 08:19:11 +0800
Subject: RFR: 8164397: Provide javadoc descriptions for jdk.security.auth, 
	jdk.security.jgss modules
In-Reply-To: <dde526f5-5b05-99a2-81cf-795d4c6a9ce8@oracle.com>
References: <b22492c9-8a19-c061-5707-f8975b0a7cec@oracle.com>
	<dde526f5-5b05-99a2-81cf-795d4c6a9ce8@oracle.com>
Message-ID: <ee8fc225-581e-a15a-0f5e-ebf9c27c5c9d@oracle.com>

Me too.

--Max

On 8/19/2016 23:11, Xuelei Fan wrote:
> Looks fine to me.
>
> Xuelei
>
> On 8/19/2016 10:25 PM, Sean Mullan wrote:
>> Please review this docs-only fix to provide descriptions for the
>> jdk.security.auth and jdk.security.jgss modules:


From weijun.wang at oracle.com  Sat Aug 20 00:30:52 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 20 Aug 2016 08:30:52 +0800
Subject: [9] RFR 8164494: SunPKCS11-Solaris requires a non-empty PBE
	password
In-Reply-To: <5eb276dc-ace7-9929-f5dc-cd4199ec0ee9@oracle.com>
References: <3CBF08E6-317B-4554-991B-8AE522972749@oracle.com>
	<5eb276dc-ace7-9929-f5dc-cd4199ec0ee9@oracle.com>
Message-ID: <da6041c4-6efa-07cb-cf72-592d37143a32@oracle.com>

How about

   this.prf = (passwdBytes.length == 0) ?
       Mac.getInstance(prfAlgo, SunJCE.getInstance()) :
       Mac.getInstance(prfAlgo);

Mac is only implemented in SunPKCS11 and SunJCE out-of-box, so this 
saves an extra getInstance() call.

If a 3rd party provider is involved, I'm not sure it supports an empty 
password (I have a feeling that except for Java everyone else are using 
the same C codes. Maybe not Microsoft), and this call is safer.

--Max

On 8/20/2016 5:18, Valerie Peng wrote:
> Looks fine to me.
> Thanks,
> Valerie
>
> On 8/19/2016 9:57 AM, Vincent Ryan wrote:
>> Please review this fix to PBE key derivation function which detects
>> when a non-empty password
>> is supplied to the SunPKCS11-Solaris JCE provider and fails over to
>> the SunJCE provider instead.
>> Thanks.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164494
>> Webrev: http://cr.openjdk.java.net/~vinnie/8164494/webrev.00/
>> <http://cr.openjdk.java.net/%7Evinnie/8164494/webrev.00/>
>>
>


From vincent.x.ryan at oracle.com  Sat Aug 20 11:47:37 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Sat, 20 Aug 2016 12:47:37 +0100
Subject: [9] RFR 8164494: SunPKCS11-Solaris requires a non-empty PBE
	password
In-Reply-To: <da6041c4-6efa-07cb-cf72-592d37143a32@oracle.com>
References: <3CBF08E6-317B-4554-991B-8AE522972749@oracle.com>
	<5eb276dc-ace7-9929-f5dc-cd4199ec0ee9@oracle.com>
	<da6041c4-6efa-07cb-cf72-592d37143a32@oracle.com>
Message-ID: <329AF8E9-9C9B-421B-A451-4970159BD6E8@oracle.com>

I did consider the approach below, especially since it saves an extra call to Mac.getInstance.
However one motivation for fixing the original issue was to better facilitate third-party JCE providers
and I know of one provider that does support empty passwords which will never get selected if that approach is used.


> On 20 Aug 2016, at 01:30, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> How about
> 
>  this.prf = (passwdBytes.length == 0) ?
>      Mac.getInstance(prfAlgo, SunJCE.getInstance()) :
>      Mac.getInstance(prfAlgo);
> 
> Mac is only implemented in SunPKCS11 and SunJCE out-of-box, so this saves an extra getInstance() call.
> 
> If a 3rd party provider is involved, I'm not sure it supports an empty password (I have a feeling that except for Java everyone else are using the same C codes. Maybe not Microsoft), and this call is safer.
> 
> --Max
> 
> On 8/20/2016 5:18, Valerie Peng wrote:
>> Looks fine to me.
>> Thanks,
>> Valerie
>> 
>> On 8/19/2016 9:57 AM, Vincent Ryan wrote:
>>> Please review this fix to PBE key derivation function which detects
>>> when a non-empty password
>>> is supplied to the SunPKCS11-Solaris JCE provider and fails over to
>>> the SunJCE provider instead.
>>> Thanks.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164494
>>> Webrev: http://cr.openjdk.java.net/~vinnie/8164494/webrev.00/
>>> <http://cr.openjdk.java.net/%7Evinnie/8164494/webrev.00/>
>>> 
>> 



From weijun.wang at oracle.com  Sat Aug 20 13:52:00 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 20 Aug 2016 21:52:00 +0800
Subject: [9] RFR 8164494: SunPKCS11-Solaris requires a non-empty PBE
	password
In-Reply-To: <329AF8E9-9C9B-421B-A451-4970159BD6E8@oracle.com>
References: <3CBF08E6-317B-4554-991B-8AE522972749@oracle.com>
	<5eb276dc-ace7-9929-f5dc-cd4199ec0ee9@oracle.com>
	<da6041c4-6efa-07cb-cf72-592d37143a32@oracle.com>
	<329AF8E9-9C9B-421B-A451-4970159BD6E8@oracle.com>
Message-ID: <9223c39a-b91b-d988-d0ae-b5aa057a683e@oracle.com>

I see. Good.

--Max

On 8/20/2016 19:47, Vincent Ryan wrote:
> I did consider the approach below, especially since it saves an extra call to Mac.getInstance.
> However one motivation for fixing the original issue was to better facilitate third-party JCE providers
> and I know of one provider that does support empty passwords which will never get selected if that approach is used.
>
>
>> On 20 Aug 2016, at 01:30, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> How about
>>
>>  this.prf = (passwdBytes.length == 0) ?
>>      Mac.getInstance(prfAlgo, SunJCE.getInstance()) :
>>      Mac.getInstance(prfAlgo);
>>
>> Mac is only implemented in SunPKCS11 and SunJCE out-of-box, so this saves an extra getInstance() call.
>>
>> If a 3rd party provider is involved, I'm not sure it supports an empty password (I have a feeling that except for Java everyone else are using the same C codes. Maybe not Microsoft), and this call is safer.
>>
>> --Max
>>


From ecki at zusammenkunft.net  Sun Aug 21 12:51:05 2016
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sun, 21 Aug 2016 14:51:05 +0200
Subject: DHKeyGenerator comment nit and discussion on minimum random key size
Message-ID: <20160821145105.0000349f.ecki@zusammenkunft.net>

Hallo,

I have noticed in DHKeyGenerator, that there is a comment which is not
totally correct:

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/496a116876a3/src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java#l192

192            // generate random x up to 2^lSize bits long
193            x = new BigInteger(lSize, random);

I think the comment should read 

  // generate random x up to lsize bits long

however, the comment adds more value if it refers to the BigInteger
spec:

   // generate random 0 <= x <= (2^lsize)-1


While finding this, I also noticed that the code has changed in JDK8.
The old form used the simple rule of applied crypto handbook:


170        // Handbook of Applied Cryptography:  Menezes, et.al.
171        // Repeat if the following does not hold:
172        //     1 <= x <= p-2
173        //
174        do {
175            // generate random x up to 2^lSize bits long
176            x = new BigInteger(lSize, random);
177        } while ((x.compareTo(BigInteger.ONE) < 0) ||
178            ((x.compareTo(pMinus2) > 0)));

(Which I always wondered if it is not to simple). This code uses p-2 as
the upper bound.


The current code specifies it uses PKCS rules where 

186        // PKCS#3 section 7.1 "Private-value generation"
187        // Repeat if either of the followings does not hold:
188        //     0 < x < p-1
189        //     2^(lSize-1) <= x < 2^(lSize)
190        //
191        do {
192            // generate random x up to 2^lSize bits long
193            x = new BigInteger(lSize, random);
194        } while ((x.compareTo(BigInteger.ONE) < 0) ||
195            ((x.compareTo(pMinus2) > 0)) || (x.bitLength() !=
lSize));

IMHO It should either mention that the check is equivalent to x <= p-2
or use the x.compareTo(pMinus1) >= 0 instead.

The lower bound 2^(lSize-1) <= x (represented as x.bitLength) is always
stricter than 0<x, therefore I guess this check can be removed in the
while condition.

this results in:

    while ((x.bitLength() != lSize) || (x.compareTo(pMinus1) >= 0))


BTW1: would it be a good addition to BigInteger or an helper to generate
a random number with a minimum number of bitlength as well? This way
situations where a minimum bit length is mandated it can be used
instead of an additional loop.

new BigInteger(minLen, maxLen, random)

which ensures the higest bit is always set, consequently returning
random numbers between (2^minLen-1) and (2^maxLen)-1.

BTW2: I was not aware that the key genration in JDK8 changed
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6e2a5637b286 - that change
only talks about interop. MAybe a documentation that key generation was
changed can be backfilled? (instinctively one can say the key
generation is stricter, on the other hand it reduces the keyspace by
one bit).

Gruss
Bernd


From sean.coffey at oracle.com  Sun Aug 21 12:59:50 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Sun, 21 Aug 2016 13:59:50 +0100
Subject: RFR : 8162362: Introduce system property to control enabled
	ciphersuites
Message-ID: <09244aa2-e124-d210-2075-ff8172a1cece@oracle.com>

I'd like to backport this to jdk8u-dev. The new 
jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system 
properties will allows users to control what ciphersuites are enabled on 
SSL Sockets/Engines. One extra edit for jdk8u in 
SSLEngineImpl/SSLSocketImpl where ciphersuites was not configured if 
setUseClientMode was called during connectionState of cs_START. JDK 9 
introduced these changes when DTLS was being introduced.

https://bugs.openjdk.java.net/browse/JDK-8162362
http://cr.openjdk.java.net/~coffeys/webrev.8162362.8u-dev/webrev/

-- 
Regards,
Sean.



From ecki at zusammenkunft.net  Sun Aug 21 14:40:56 2016
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sun, 21 Aug 2016 16:40:56 +0200
Subject: DHKeyGenerator comment nit and discussion on minimum random key
	size
In-Reply-To: <20160821145105.0000349f.ecki@zusammenkunft.net>
References: <20160821145105.0000349f.ecki@zusammenkunft.net>
Message-ID: <20160821164056.000009e7.ecki@zusammenkunft.net>

Hello,

to answer myself, it can be done with setBit. I have discussed it here:

http://crypto.stackexchange.com/questions/39498/generating-dh-key-with-minimum-size

an optimized loop would then look like:

        do {
            // generate random x between 2^(lSize-1) and (2^lSize)-1
            x = new BigInteger(lSize - 1, random);
            x = x.setBit(lSize);
        } while (x.compareTo(pMinus1) >= 0);

BTW: the sentence "Repeat if either of the followings does not hold"
is wrong, this is not mandated in PKCS3. It is different if l is
specified or not and it does not require a loop of the condition can be
satisifed in another way.


Gruss
Bernd


Am Sun, 21 Aug 2016 14:51:05 +0200
schrieb Bernd Eckenfels <ecki at zusammenkunft.net>:

> Hallo,
> 
> I have noticed in DHKeyGenerator, that there is a comment which is not
> totally correct:
> 
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/496a116876a3/src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java#l192
> 
> 192            // generate random x up to 2^lSize bits long
> 193            x = new BigInteger(lSize, random);
> 
> I think the comment should read 
> 
>   // generate random x up to lsize bits long
> 
> however, the comment adds more value if it refers to the BigInteger
> spec:
> 
>    // generate random 0 <= x <= (2^lsize)-1
> 
> 
> While finding this, I also noticed that the code has changed in JDK8.
> The old form used the simple rule of applied crypto handbook:
> 
> 
> 170        // Handbook of Applied Cryptography:  Menezes, et.al.
> 171        // Repeat if the following does not hold:
> 172        //     1 <= x <= p-2
> 173        //
> 174        do {
> 175            // generate random x up to 2^lSize bits long
> 176            x = new BigInteger(lSize, random);
> 177        } while ((x.compareTo(BigInteger.ONE) < 0) ||
> 178            ((x.compareTo(pMinus2) > 0)));
> 
> (Which I always wondered if it is not to simple). This code uses p-2
> as the upper bound.
> 
> 
> The current code specifies it uses PKCS rules where 
> 
> 186        // PKCS#3 section 7.1 "Private-value generation"
> 187        // Repeat if either of the followings does not hold:
> 188        //     0 < x < p-1
> 189        //     2^(lSize-1) <= x < 2^(lSize)
> 190        //
> 191        do {
> 192            // generate random x up to 2^lSize bits long
> 193            x = new BigInteger(lSize, random);
> 194        } while ((x.compareTo(BigInteger.ONE) < 0) ||
> 195            ((x.compareTo(pMinus2) > 0)) || (x.bitLength() !=
> lSize));
> 
> IMHO It should either mention that the check is equivalent to x <= p-2
> or use the x.compareTo(pMinus1) >= 0 instead.
> 
> The lower bound 2^(lSize-1) <= x (represented as x.bitLength) is
> always stricter than 0<x, therefore I guess this check can be removed
> in the while condition.
> 
> this results in:
> 
>     while ((x.bitLength() != lSize) || (x.compareTo(pMinus1) >= 0))
> 
> 
> BTW1: would it be a good addition to BigInteger or an helper to
> generate a random number with a minimum number of bitlength as well?
> This way situations where a minimum bit length is mandated it can be
> used instead of an additional loop.
> 
> new BigInteger(minLen, maxLen, random)
> 
> which ensures the higest bit is always set, consequently returning
> random numbers between (2^minLen-1) and (2^maxLen)-1.
> 
> BTW2: I was not aware that the key genration in JDK8 changed
> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/6e2a5637b286 - that
> change only talks about interop. MAybe a documentation that key
> generation was changed can be backfilled? (instinctively one can say
> the key generation is stricter, on the other hand it reduces the
> keyspace by one bit).
> 
> Gruss
> Bernd


From sean.coffey at oracle.com  Mon Aug 22 07:56:43 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 22 Aug 2016 08:56:43 +0100
Subject: RFR: 8150530:Improve javax.crypto.BadPaddingException messages
Message-ID: <7dc95b29-9def-0a5f-6b4f-355810b1e430@oracle.com>

Looking to improve some of the messages used in generation of 
BadPaddingException messages. The 'Given final block not properly 
padded' one in particular has caused confusion for some users in the past.

JBS report : https://bugs.openjdk.java.net/browse/JDK-8150530
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8150530/webrev/

-- 
Regards,
Sean.



From xuelei.fan at oracle.com  Mon Aug 22 09:14:15 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 22 Aug 2016 17:14:15 +0800
Subject: RFR : 8162362: Introduce system property to control enabled
	ciphersuites
In-Reply-To: <09244aa2-e124-d210-2075-ff8172a1cece@oracle.com>
References: <09244aa2-e124-d210-2075-ff8172a1cece@oracle.com>
Message-ID: <c3f2517e-e132-a4b4-ef7e-52afa73d5139@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 8/21/2016 8:59 PM, Se?n Coffey wrote:
> I'd like to backport this to jdk8u-dev. The new
> jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system
> properties will allows users to control what ciphersuites are enabled on
> SSL Sockets/Engines. One extra edit for jdk8u in
> SSLEngineImpl/SSLSocketImpl where ciphersuites was not configured if
> setUseClientMode was called during connectionState of cs_START. JDK 9
> introduced these changes when DTLS was being introduced.
>
> https://bugs.openjdk.java.net/browse/JDK-8162362
> http://cr.openjdk.java.net/~coffeys/webrev.8162362.8u-dev/webrev/
>


From xuelei.fan at oracle.com  Mon Aug 22 10:06:24 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 22 Aug 2016 18:06:24 +0800
Subject: RFR: 8150530:Improve javax.crypto.BadPaddingException messages
In-Reply-To: <7dc95b29-9def-0a5f-6b4f-355810b1e430@oracle.com>
References: <7dc95b29-9def-0a5f-6b4f-355810b1e430@oracle.com>
Message-ID: <eefb3da9-185b-6d71-81d7-fec4d05e4349@oracle.com>

Minor comments:

CipherCore.java
---------------
"... could arise if a bad key or password is used during decryption."
"password" may be confusing for some user cases.  This could also happen 
if bad key used for encryption.  I may just say "could arise if a bad 
key used."

RSAPadding.java
---------------
I may prefer to use a sentence for the exception message.  For example:
    "Data must be shorter than ... bytes, but received ... bytes"
    "The pad array length (padded.length) is not the specified pad size 
(paddedSize)  "

CipherBox.java
--------------
I may not use the internal variable name in the exception message.  It 
might be easier to read:

496/580: "The padding removed text (newLen bytes) should be bigger than 
<blockSize> as explicit IV used."

763/810: "The padding length (padLen) of SSLv3 message should not bigger 
than the block size (blockSize)."

934: "Insufficient buffer for AEAD cipher fragment, needs more than 
(recordIvSize + tagSize) bytes, but only (bb.remaining()) remains in the 
buffer"

P11RSACipher.java
-----------------
360: "The output buffer (outLen bytes) is too small to hold the produced 
data (tmpBuffer.length bytes)"

Thanks,
Xuelei

On 8/22/2016 3:56 PM, Se?n Coffey wrote:
> Looking to improve some of the messages used in generation of
> BadPaddingException messages. The 'Given final block not properly
> padded' one in particular has caused confusion for some users in the past.
>
> JBS report : https://bugs.openjdk.java.net/browse/JDK-8150530
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8150530/webrev/
>


From sibabrata.sahoo at oracle.com  Tue Aug 23 08:19:26 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 23 Aug 2016 01:19:26 -0700 (PDT)
Subject: [9] RFR: 8006690: sun/security/krb5/auto/BadKdc* tests fails
	intermittently
Message-ID: <704aa535-190e-47c7-b78c-297e3edc559a@default>

Hi,

 

Please review the patch for intermittent failures in "sun/security/krb5/auto/BadKdc*"

 

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

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

 

Description:

Some times when the test machine is slow the number of retry for an active KDC can be more than expected. As the expected count is set to 2 the failure occurs when it find a 3rd retry attempt. I have increased the supported retry count for an active KDC response to overcome the failure. Please provide your suggestion.

 

Thanks,

Siba

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

From weijun.wang at oracle.com  Tue Aug 23 10:27:05 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 23 Aug 2016 18:27:05 +0800
Subject: [9] RFR: 8006690: sun/security/krb5/auto/BadKdc* tests fails
	intermittently
In-Reply-To: <704aa535-190e-47c7-b78c-297e3edc559a@default>
References: <704aa535-190e-47c7-b78c-297e3edc559a@default>
Message-ID: <e32113e0-3787-891d-4578-cf0d5e834a9d@oracle.com>

The change looks fine. Hopefully this can let intermittent failures go away.

Thanks
Max

On 8/23/2016 16:19, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for intermittent failures in
> ?sun/security/krb5/auto/BadKdc*?
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8006690
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8006690/webrev.00/
>
>
>
> Description:
>
> Some times when the test machine is slow the number of retry for an
> active KDC can be more than expected. As the expected count is set to 2
> the failure occurs when it find a 3^rd retry attempt. I have increased
> the supported retry count for an active KDC response to overcome the
> failure. Please provide your suggestion.
>
>
>
> Thanks,
>
> Siba
>
>
>


From weijun.wang at oracle.com  Tue Aug 23 16:14:49 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 24 Aug 2016 00:14:49 +0800
Subject: RFR 8164656: krb5 does not retry if TCP connection timeouts
Message-ID: <8d23e550-a8b6-269b-770c-54c873571565@oracle.com>

Please review the change at

    http://cr.openjdk.java.net/~weijun/8164656/webrev.00/

The old try-catch is only on send/receive, but NetClient.getInstance() 
could also timeout for TCP when it calls Socket::connect(dest,timeout). 
Therefore move the catch to a higher level.

The test is brand new and it's meant to replace existing BadKdc?.java, 
TcpTimeout.java and MaxRetries.java. In fact, I discover this bug when I 
am writing it. The new test is much faster because in most cases there 
is no real KDC and timeout can be very short. It contains 2 @run and 
each spends a little more than half a minute to run on my laptop.

Thanks
Max


From ivan.gerasimov at oracle.com  Tue Aug 23 17:20:07 2016
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 23 Aug 2016 20:20:07 +0300
Subject: [jdk9] (XS) RFR: 6474807: (smartcardio) CardTerminal.connect() throws
	CardException instead of CardNotPresentException
Message-ID: <d4cf87df-a560-7806-d373-71deb150e540@oracle.com>

Hello!

When underlying PCSC driver returns the error SCARD_E_NO_SMARTCARD, we 
should throw a more specialized exception of type CardNotPresentException.

Currently, the plain CardException is thrown, which makes some TCK tests 
unhappy.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-6474807
WEBREV: http://cr.openjdk.java.net/~igerasim/6474807/00/webrev/

Would you please help review a simple fix?

With kind regards,
Ivan



From xuelei.fan at oracle.com  Wed Aug 24 00:06:00 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 24 Aug 2016 08:06:00 +0800
Subject: RFR 8164656: krb5 does not retry if TCP connection timeouts
In-Reply-To: <8d23e550-a8b6-269b-770c-54c873571565@oracle.com>
References: <8d23e550-a8b6-269b-770c-54c873571565@oracle.com>
Message-ID: <85b5cc07-0eab-4b9b-25b7-e2017e1c018a@oracle.com>

Looks fine to me.

Xuelei

On 8/24/2016 12:14 AM, Weijun Wang wrote:
> Please review the change at
>
>    http://cr.openjdk.java.net/~weijun/8164656/webrev.00/
>
> The old try-catch is only on send/receive, but NetClient.getInstance()
> could also timeout for TCP when it calls Socket::connect(dest,timeout).
> Therefore move the catch to a higher level.
>
> The test is brand new and it's meant to replace existing BadKdc?.java,
> TcpTimeout.java and MaxRetries.java. In fact, I discover this bug when I
> am writing it. The new test is much faster because in most cases there
> is no real KDC and timeout can be very short. It contains 2 @run and
> each spends a little more than half a minute to run on my laptop.
>
> Thanks
> Max


From weijun.wang at oracle.com  Wed Aug 24 02:00:50 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 24 Aug 2016 10:00:50 +0800
Subject: RFR 8164656: krb5 does not retry if TCP connection timeouts
In-Reply-To: <85b5cc07-0eab-4b9b-25b7-e2017e1c018a@oracle.com>
References: <8d23e550-a8b6-269b-770c-54c873571565@oracle.com>
	<85b5cc07-0eab-4b9b-25b7-e2017e1c018a@oracle.com>
Message-ID: <f8856839-2e0e-35a6-6ad2-f3a1d8116efb@oracle.com>

I've updated the test at

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

No more ratio things.

When the ratio was invented for BadKdc, it was because it uses real KDCs 
and we have to find a balance between unexpected timeout and test speed. 
Changing a single ratio is much easier to modify hundreds of timeout and 
pattern across 6 test files.

In KdcPolicy.java, most requests go to fake KDCs and the timeout is 
already super short. For the few cases where a real KDC is needed, even 
if we need to tweak the timeout later (if intermittent failures still 
happen), it will be much easier to just tweak on the actual timeout 
value directly.

Thanks
Max

On 8/24/2016 8:06, Xuelei Fan wrote:
> Looks fine to me.
>
> Xuelei
>
> On 8/24/2016 12:14 AM, Weijun Wang wrote:
>> Please review the change at
>>
>>    http://cr.openjdk.java.net/~weijun/8164656/webrev.00/
>>
>> The old try-catch is only on send/receive, but NetClient.getInstance()
>> could also timeout for TCP when it calls Socket::connect(dest,timeout).
>> Therefore move the catch to a higher level.
>>
>> The test is brand new and it's meant to replace existing BadKdc?.java,
>> TcpTimeout.java and MaxRetries.java. In fact, I discover this bug when I
>> am writing it. The new test is much faster because in most cases there
>> is no real KDC and timeout can be very short. It contains 2 @run and
>> each spends a little more than half a minute to run on my laptop.
>>
>> Thanks
>> Max


From xuelei.fan at oracle.com  Wed Aug 24 04:39:10 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 24 Aug 2016 12:39:10 +0800
Subject: RFR 8164656: krb5 does not retry if TCP connection timeouts
In-Reply-To: <f8856839-2e0e-35a6-6ad2-f3a1d8116efb@oracle.com>
References: <8d23e550-a8b6-269b-770c-54c873571565@oracle.com>
	<85b5cc07-0eab-4b9b-25b7-e2017e1c018a@oracle.com>
	<f8856839-2e0e-35a6-6ad2-f3a1d8116efb@oracle.com>
Message-ID: <e29a37d6-a487-aa05-74b5-c536f8b634ce@oracle.com>

OK.

On 8/24/2016 10:00 AM, Weijun Wang wrote:
> I've updated the test at
>
>   http://cr.openjdk.java.net/~weijun/8164656/webrev.01/
>
> No more ratio things.
>
> When the ratio was invented for BadKdc, it was because it uses real KDCs
> and we have to find a balance between unexpected timeout and test speed.
> Changing a single ratio is much easier to modify hundreds of timeout and
> pattern across 6 test files.
>
> In KdcPolicy.java, most requests go to fake KDCs and the timeout is
> already super short. For the few cases where a real KDC is needed, even
> if we need to tweak the timeout later (if intermittent failures still
> happen), it will be much easier to just tweak on the actual timeout
> value directly.
>
> Thanks
> Max
>
> On 8/24/2016 8:06, Xuelei Fan wrote:
>> Looks fine to me.
>>
>> Xuelei
>>
>> On 8/24/2016 12:14 AM, Weijun Wang wrote:
>>> Please review the change at
>>>
>>>    http://cr.openjdk.java.net/~weijun/8164656/webrev.00/
>>>
>>> The old try-catch is only on send/receive, but NetClient.getInstance()
>>> could also timeout for TCP when it calls Socket::connect(dest,timeout).
>>> Therefore move the catch to a higher level.
>>>
>>> The test is brand new and it's meant to replace existing BadKdc?.java,
>>> TcpTimeout.java and MaxRetries.java. In fact, I discover this bug when I
>>> am writing it. The new test is much faster because in most cases there
>>> is no real KDC and timeout can be very short. It contains 2 @run and
>>> each spends a little more than half a minute to run on my laptop.
>>>
>>> Thanks
>>> Max


From sean.coffey at oracle.com  Wed Aug 24 11:02:18 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 24 Aug 2016 12:02:18 +0100
Subject: RFR: 8150530:Improve javax.crypto.BadPaddingException messages
In-Reply-To: <eefb3da9-185b-6d71-81d7-fec4d05e4349@oracle.com>
References: <7dc95b29-9def-0a5f-6b4f-355810b1e430@oracle.com>
	<eefb3da9-185b-6d71-81d7-fec4d05e4349@oracle.com>
Message-ID: <57BD7EBA.4030407@oracle.com>


On 22/08/16 11:06, Xuelei Fan wrote:
> Minor comments:
>
> CipherCore.java
> ---------------
> "... could arise if a bad key or password is used during decryption."
> "password" may be confusing for some user cases.  This could also 
> happen if bad key used for encryption.  I may just say "could arise if 
> a bad key used."
The exception message modified only gets thrown in a decryption call. 
Isn't it true that a password fed to an application may be used to 
generate a key ? For that reason, I was trying to suggest that other 
variables (from user) could be at fault for the BadPaddingException. 
Would it be ok to keep the password reference (as a hint?)

I've implemented the rest of your suggested edits. Makes sense - thanks.
new webrev : 
http://cr.openjdk.java.net/~coffeys/webrev.8150530.v2/webrev/index.html

regards,
Sean.

>
> RSAPadding.java
> ---------------
> I may prefer to use a sentence for the exception message.  For example:
>    "Data must be shorter than ... bytes, but received ... bytes"
>    "The pad array length (padded.length) is not the specified pad size 
> (paddedSize)  "
>
> CipherBox.java
> --------------
> I may not use the internal variable name in the exception message.  It 
> might be easier to read:
>
> 496/580: "The padding removed text (newLen bytes) should be bigger 
> than <blockSize> as explicit IV used."
>
> 763/810: "The padding length (padLen) of SSLv3 message should not 
> bigger than the block size (blockSize)."
>
> 934: "Insufficient buffer for AEAD cipher fragment, needs more than 
> (recordIvSize + tagSize) bytes, but only (bb.remaining()) remains in 
> the buffer"
>
> P11RSACipher.java
> -----------------
> 360: "The output buffer (outLen bytes) is too small to hold the 
> produced data (tmpBuffer.length bytes)"
>
> Thanks,
> Xuelei
>
> On 8/22/2016 3:56 PM, Se?n Coffey wrote:
>> Looking to improve some of the messages used in generation of
>> BadPaddingException messages. The 'Given final block not properly
>> padded' one in particular has caused confusion for some users in the 
>> past.
>>
>> JBS report : https://bugs.openjdk.java.net/browse/JDK-8150530
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8150530/webrev/
>>



From xuelei.fan at oracle.com  Wed Aug 24 14:55:35 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 24 Aug 2016 22:55:35 +0800
Subject: RFR: 8150530:Improve javax.crypto.BadPaddingException messages
In-Reply-To: <57BD7EBA.4030407@oracle.com>
References: <7dc95b29-9def-0a5f-6b4f-355810b1e430@oracle.com>
	<eefb3da9-185b-6d71-81d7-fec4d05e4349@oracle.com>
	<57BD7EBA.4030407@oracle.com>
Message-ID: <570e7c33-fad6-409a-b8d5-566b1573d68d@oracle.com>

On 8/24/2016 7:02 PM, Se?n Coffey wrote:
>
> On 22/08/16 11:06, Xuelei Fan wrote:
>> Minor comments:
>>
>> CipherCore.java
>> ---------------
>> "... could arise if a bad key or password is used during decryption."
>> "password" may be confusing for some user cases.  This could also
>> happen if bad key used for encryption.  I may just say "could arise if
>> a bad key used."
> The exception message modified only gets thrown in a decryption call.
> Isn't it true that a password fed to an application may be used to
> generate a key ? For that reason, I was trying to suggest that other
> variables (from user) could be at fault for the BadPaddingException.
> Would it be ok to keep the password reference (as a hint?)
>
Password is just one way of many to generate a key.  There is no 
password in the context of this class.  Password based implementation 
should take care of to show the right message.  Adding password word to 
this message may be confusing to both users and developers, I think.

For example, I want to login with password but the key used to encrypt 
and decrypt the communication is not actually generated by the password 
(it's a very common case for HTTPS based login in practice).  This 
exception message may be very confusing.

Not a big issue, I'm OK if you want to keep the password reference.

> I've implemented the rest of your suggested edits. Makes sense - thanks.
> new webrev :
> http://cr.openjdk.java.net/~coffeys/webrev.8150530.v2/webrev/index.html
>
Looks fine to me.

Thanks,
Xuelei

> regards,
> Sean.
>
>>
>> RSAPadding.java
>> ---------------
>> I may prefer to use a sentence for the exception message.  For example:
>>    "Data must be shorter than ... bytes, but received ... bytes"
>>    "The pad array length (padded.length) is not the specified pad size
>> (paddedSize)  "
>>
>> CipherBox.java
>> --------------
>> I may not use the internal variable name in the exception message.  It
>> might be easier to read:
>>
>> 496/580: "The padding removed text (newLen bytes) should be bigger
>> than <blockSize> as explicit IV used."
>>
>> 763/810: "The padding length (padLen) of SSLv3 message should not
>> bigger than the block size (blockSize)."
>>
>> 934: "Insufficient buffer for AEAD cipher fragment, needs more than
>> (recordIvSize + tagSize) bytes, but only (bb.remaining()) remains in
>> the buffer"
>>
>> P11RSACipher.java
>> -----------------
>> 360: "The output buffer (outLen bytes) is too small to hold the
>> produced data (tmpBuffer.length bytes)"
>>
>> Thanks,
>> Xuelei
>>
>> On 8/22/2016 3:56 PM, Se?n Coffey wrote:
>>> Looking to improve some of the messages used in generation of
>>> BadPaddingException messages. The 'Given final block not properly
>>> padded' one in particular has caused confusion for some users in the
>>> past.
>>>
>>> JBS report : https://bugs.openjdk.java.net/browse/JDK-8150530
>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8150530/webrev/
>>>
>


From sibabrata.sahoo at oracle.com  Wed Aug 24 16:16:01 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Wed, 24 Aug 2016 09:16:01 -0700 (PDT)
Subject: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java fails
	with Timeout error
Message-ID: <c0578e90-ca11-4234-ba72-a2b1818a34e6@default>

Hi,

 

Please review the patch for "sun/security/krb5/auto/Unreachable.java fails with Timeout error"

 

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

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

 

Description:

When a KDC port is unreachable, Kerberos login module depends on PortUnreachableException to exit immediately. But as per JavaDoc for receive() in "java.net.DatagramSocket", the PortUnreachableException is not guaranteed. In such case the Login module waits for 90 second by default. But the JTREG Test timeout has been set for 10 second and because of that the Test gets timeout.

 

Since the "intermittent" failure is unavoidable due to  "PortUnreachableException is not guaranteed", I have provided a fix to print a warning message for such cases instead of making the Test timeout.

 

Thanks,

Siba

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

From sean.coffey at oracle.com  Wed Aug 24 16:49:14 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 24 Aug 2016 17:49:14 +0100
Subject: RFR: 8150530:Improve javax.crypto.BadPaddingException messages
In-Reply-To: <570e7c33-fad6-409a-b8d5-566b1573d68d@oracle.com>
References: <7dc95b29-9def-0a5f-6b4f-355810b1e430@oracle.com>
	<eefb3da9-185b-6d71-81d7-fec4d05e4349@oracle.com>
	<57BD7EBA.4030407@oracle.com>
	<570e7c33-fad6-409a-b8d5-566b1573d68d@oracle.com>
Message-ID: <57BDD00A.2060309@oracle.com>

Thanks for the review Xuelei. OK - I'll drop the 'password' reference 
then and push the changes.

!                     throw new BadPaddingException("Given final block 
not " +
!                     "properly padded. Such issues could arise if a bad 
key " +
!                     "is used during decryption.");

Regards,
Sean.

On 24/08/16 15:55, Xuelei Fan wrote:
> On 8/24/2016 7:02 PM, Se?n Coffey wrote:
>>
>> On 22/08/16 11:06, Xuelei Fan wrote:
>>> Minor comments:
>>>
>>> CipherCore.java
>>> ---------------
>>> "... could arise if a bad key or password is used during decryption."
>>> "password" may be confusing for some user cases.  This could also
>>> happen if bad key used for encryption.  I may just say "could arise if
>>> a bad key used."
>> The exception message modified only gets thrown in a decryption call.
>> Isn't it true that a password fed to an application may be used to
>> generate a key ? For that reason, I was trying to suggest that other
>> variables (from user) could be at fault for the BadPaddingException.
>> Would it be ok to keep the password reference (as a hint?)
>>
> Password is just one way of many to generate a key.  There is no 
> password in the context of this class.  Password based implementation 
> should take care of to show the right message. Adding password word to 
> this message may be confusing to both users and developers, I think.
>
> For example, I want to login with password but the key used to encrypt 
> and decrypt the communication is not actually generated by the 
> password (it's a very common case for HTTPS based login in practice).  
> This exception message may be very confusing.
>
> Not a big issue, I'm OK if you want to keep the password reference.
>
>> I've implemented the rest of your suggested edits. Makes sense - thanks.
>> new webrev :
>> http://cr.openjdk.java.net/~coffeys/webrev.8150530.v2/webrev/index.html
>>
> Looks fine to me.
>
> Thanks,
> Xuelei
>
>> regards,
>> Sean.
>>
>>>
>>> RSAPadding.java
>>> ---------------
>>> I may prefer to use a sentence for the exception message.  For example:
>>>    "Data must be shorter than ... bytes, but received ... bytes"
>>>    "The pad array length (padded.length) is not the specified pad size
>>> (paddedSize)  "
>>>
>>> CipherBox.java
>>> --------------
>>> I may not use the internal variable name in the exception message.  It
>>> might be easier to read:
>>>
>>> 496/580: "The padding removed text (newLen bytes) should be bigger
>>> than <blockSize> as explicit IV used."
>>>
>>> 763/810: "The padding length (padLen) of SSLv3 message should not
>>> bigger than the block size (blockSize)."
>>>
>>> 934: "Insufficient buffer for AEAD cipher fragment, needs more than
>>> (recordIvSize + tagSize) bytes, but only (bb.remaining()) remains in
>>> the buffer"
>>>
>>> P11RSACipher.java
>>> -----------------
>>> 360: "The output buffer (outLen bytes) is too small to hold the
>>> produced data (tmpBuffer.length bytes)"
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 8/22/2016 3:56 PM, Se?n Coffey wrote:
>>>> Looking to improve some of the messages used in generation of
>>>> BadPaddingException messages. The 'Given final block not properly
>>>> padded' one in particular has caused confusion for some users in the
>>>> past.
>>>>
>>>> JBS report : https://bugs.openjdk.java.net/browse/JDK-8150530
>>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8150530/webrev/
>>>>
>>



From svetlana.nikandrova at oracle.com  Wed Aug 24 18:21:37 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Wed, 24 Aug 2016 21:21:37 +0300
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java
	failed with "Error while cleaning up threads after test"
Message-ID: <57BDE5B1.3010601@oracle.com>

Hello,

please review this test bug fix. Test failed because of staled threads 
left after execution.
Added try-with-resources statements to make sure test closes it's 
resources. Also as test is overall quite old-fashioned I've done some 
refactoring (hope now it looks better).

JBS:
https://bugs.openjdk.java.net/browse/JDK-8164533
Webrev:
http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/ 
<http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/>

Thank you,
Svetlana


From sean.mullan at oracle.com  Wed Aug 24 19:17:31 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 24 Aug 2016 15:17:31 -0400
Subject: RFR: 8151893: Add security property to configure XML Signature secure
	validation mode
Message-ID: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>

Please review this fix to add a new security property that allows you to 
configure the individual restrictions that are enabled by the XML 
Signature secure validation mode.

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

Thanks,
Sean


From artem.smotrakov at oracle.com  Wed Aug 24 19:55:48 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 24 Aug 2016 12:55:48 -0700
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <57BDE5B1.3010601@oracle.com>
References: <57BDE5B1.3010601@oracle.com>
Message-ID: <b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>

Hi Svetlana,

Thank you for cleaning up this test. I have a couple of comments (mostly 
about the original test).

1. I see that the test tries to connect to a server three times, but the 
server accept only first connection, and then it stops. So test cases 
#2-3 fail just because the connection was refused. The original test 
behaves like this. This looks like a bug to me. What do you think? 
Should the server have a loop of three iterations?

2. Here is server's code:

   95         @Override
   96         public void run() {
   97             try (Socket s = serverSocket.accept()) {
   98                 System.out.println("Server accepted connection");
   99                 // wait a bit before closing the socket to give
  100                 // the client time to send its hello message
  101                 Thread.currentThread().sleep(100);
  102                 s.close();
  103                 System.out.println("Server closed socket, done.");
  104             } catch (Exception e) {
  105                 throw new RuntimeException("Problem in test 
execution", e);
  106             }
  107         }

Not sure if it is a good assumption to expect that ClientHello is 
received in 100 milliseconds. It might read first data, and then close 
the socket. It also doesn't seem to be necessary to call close() there.

Otherwise, the webrev looks good to me, but please note that I am not an 
official reviewer. You may want to fix the issues above, or we can just 
file a new bug.

Artem

On 08/24/2016 11:21 AM, Svetlana Nikandrova wrote:
> Hello,
>
> please review this test bug fix. Test failed because of staled threads 
> left after execution.
> Added try-with-resources statements to make sure test closes it's 
> resources. Also as test is overall quite old-fashioned I've done some 
> refactoring (hope now it looks better).
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8164533
> Webrev:
> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/ 
> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/>
>
> Thank you,
> Svetlana



From sean.mullan at oracle.com  Wed Aug 24 23:57:04 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 24 Aug 2016 19:57:04 -0400
Subject: RFR: 8151893: Add security property to configure XML Signature
	secure validation mode
In-Reply-To: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>
References: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>
Message-ID: <b633d67f-1a92-5773-8352-8d68de0e2fb0@oracle.com>

I posted an updated webrev: 
http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.0

I found an existing bug in the dsig implementation and wanted to fix it 
with this change. There are 2 ways to register an element's ID attributes:

1. Using javax.xml.crypto.dom.DOMCryptoContext.setIdAttributeNS()
2. Using one of the org.w3c.dom.Element.setIdAttribute*() methods

The DOMURIDereferencer needs to check both mechanisms when searching for 
Id attributes (it was only checking the first). Fix has been applied to 
lines 91-96 of DOMURIDereferencer in the updated webrev.

--Sean

On 08/24/2016 03:17 PM, Sean Mullan wrote:
> Please review this fix to add a new security property that allows you to
> configure the individual restrictions that are enabled by the XML
> Signature secure validation mode.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8151893
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.00/
>
> Thanks,
> Sean


From bradford.wetmore at oracle.com  Thu Aug 25 00:21:55 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 24 Aug 2016 17:21:55 -0700
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
Message-ID: <d3832c25-5458-6b70-616c-1babf7289697@oracle.com>

Max/SeanC/SeanM,

The latest update:

     http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/

On 8/17/2016 9:26 PM, Wang Weijun wrote:
> Before this change, you require default policy in neither export nor import to be empty but do not care about the getMinimum() result. In this change, you make sure the final result is not empty. I assume this is a fix?

I made the change to allow for our traditional (default) export/import 
mechanism, but other additional styles could be added/used.  Since we no 
longer sign, distros are free to edit, add and/or remove files.  But 
before doing any JCE operation, the environment needs to grant 
something, otherwise there are no perms and no JCE available.

> 283                     // Did we find a default perms?
>
> What does this line mean?

I've moved to the right position in the file.  I meant did we find a 
default perms file, vs an exempt.

> 296                         // This should never happen
>
> But you can still print out the file name.

I'm concerned that the exception might print out the entire path instead 
of just the filename, which would include java.home and probably should 
not be made available.

> Can you rename policydir-tbd to something else? I am afraid it will be confused with policy.url.1 etc.

Changed to:  crypto.policydir-tbd?

> The original README.TXT in unlimited says "are exportable from the United States." and you have "is exportable." now. Is this intended? (IANAL)

Changed.

> TestUnlimited.java:
> 45 "// Use the AES are the test Cipher", you mean "Use AES as the test Cipher"?
> 51 "throw new Exception ("Unlimited policy is NOT active");". No space before "(".

Fixed.

Sean Mullan wrote:

  > What about setting the default value to "limited"? And then this
  > would only be changed to "unlimited" if the build --enable-unlimited-
  > crypto option is specified?

I could, but I'm concerned that a build with --enabled-unlimited-crypto 
would expect that the compiled-in version default would also be 
unlimited and would be surprised with limited.

Upon Max's suggestion above, I've changed the name of the marker to 
"crypto.policy=crypto.policydir-tbd."  Does that work for you?

  > Instead of throwing an exception here, I wonder if it would make more
  > sense to assume a default value of "limited" if the property is not
  > set or is empty.

We could, but see above.

Sean Coffey wrote:

 > Please include the exception 'e' in your last exception here.

Again, I'm concerned about outputting java.home, so I'm just going to 
output the final directory name.

 > 3. Test case.
 >
 > The TestUnlimited.java testcase seems to be lacking. Do you want to
 > test other values for crypto.policy ? 'limited' would be one.
 > Throwing in some dummy value would also be good so that the exception
 > handling code gets exercised.

Done.

  * @run main/othervm TestUnlimited limited fail
  * @run main/othervm TestUnlimited unlimited pass
  * @run main/othervm TestUnlimited NosuchDir exception
  * @run main/othervm TestUnlimited . exception
  * @run main/othervm TestUnlimited /tmp/unlimited exception
  * @run main/othervm TestUnlimited ../policy/unlimited exception
  * @run main/othervm TestUnlimited ./unlimited exception

 > It needs to be run in ovm mode since you're setting a Security
 > property.

Yes, good catch.

Brad



From xuelei.fan at oracle.com  Thu Aug 25 01:10:41 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 25 Aug 2016 09:10:41 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
References: <57BDE5B1.3010601@oracle.com>
	<b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
Message-ID: <101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>



On 8/25/2016 3:55 AM, Artem Smotrakov wrote:
> Hi Svetlana,
>
> Thank you for cleaning up this test. I have a couple of comments (mostly
> about the original test).
>
> 1. I see that the test tries to connect to a server three times, but the
> server accept only first connection, and then it stops. So test cases
> #2-3 fail just because the connection was refused. The original test
> behaves like this. This looks like a bug to me. What do you think?
> Should the server have a loop of three iterations?
>
I think it's the purpose to test behavior of the close server socket.

> 2. Here is server's code:
>
>   95         @Override
>   96         public void run() {
>   97             try (Socket s = serverSocket.accept()) {
>   98                 System.out.println("Server accepted connection");
>   99                 // wait a bit before closing the socket to give
>  100                 // the client time to send its hello message
>  101                 Thread.currentThread().sleep(100);
>  102                 s.close();
>  103                 System.out.println("Server closed socket, done.");
>  104             } catch (Exception e) {
>  105                 throw new RuntimeException("Problem in test
> execution", e);
>  106             }
>  107         }
>
> Not sure if it is a good assumption to expect that ClientHello is
> received in 100 milliseconds. It might read first data, and then close
> the socket. It also doesn't seem to be necessary to call close() there.
>
It is not expected to perform handshaking for this test.  Get 
connection, and immediately close the socket before handshaking, and 
then see what happens in client side (connect/read/write).

I have the same concern that 100 MS may be an issue.  Please consider to 
make an improvement.

BTW, please run the test in othervm mode.

Xuelei

> Otherwise, the webrev looks good to me, but please note that I am not an
> official reviewer. You may want to fix the issues above, or we can just
> file a new bug.
>
> Artem
>
> On 08/24/2016 11:21 AM, Svetlana Nikandrova wrote:
>> Hello,
>>
>> please review this test bug fix. Test failed because of staled threads
>> left after execution.
>> Added try-with-resources statements to make sure test closes it's
>> resources. Also as test is overall quite old-fashioned I've done some
>> refactoring (hope now it looks better).
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8164533
>> Webrev:
>> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/
>> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/>
>>
>> Thank you,
>> Svetlana
>


From weijun.wang at oracle.com  Thu Aug 25 01:22:58 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 25 Aug 2016 09:22:58 +0800
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
Message-ID: <8bcfa44a-ecb4-ad02-0611-069cb98d1dcc@oracle.com>

+        Path javaHomePath = Paths.get(javaHomeProperty, "conf", "security",
+                "policy").normalize();

This is not javaHomePath, but policyPath.

You added "cryptoPolicyProperty" to some exceptions, but the exception 
titles are "Unexpected jurisdiction policy filename found: " and 
"Couldn't parse jurisdiction policy files: ". cryptoPolicyProperty is 
not file(s). Maybe "... file(s) in " + cryptoPolicyProperty?

No other comment.

Thanks
Max

On 8/25/2016 8:21, Bradford Wetmore wrote:
> Max/SeanC/SeanM,
>
> The latest update:
>
>     http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/
>
> On 8/17/2016 9:26 PM, Wang Weijun wrote:
>> Before this change, you require default policy in neither export nor
>> import to be empty but do not care about the getMinimum() result. In
>> this change, you make sure the final result is not empty. I assume
>> this is a fix?
>
> I made the change to allow for our traditional (default) export/import
> mechanism, but other additional styles could be added/used.  Since we no
> longer sign, distros are free to edit, add and/or remove files.  But
> before doing any JCE operation, the environment needs to grant
> something, otherwise there are no perms and no JCE available.
>
>> 283                     // Did we find a default perms?
>>
>> What does this line mean?
>
> I've moved to the right position in the file.  I meant did we find a
> default perms file, vs an exempt.
>
>> 296                         // This should never happen
>>
>> But you can still print out the file name.
>
> I'm concerned that the exception might print out the entire path instead
> of just the filename, which would include java.home and probably should
> not be made available.
>
>> Can you rename policydir-tbd to something else? I am afraid it will be
>> confused with policy.url.1 etc.
>
> Changed to:  crypto.policydir-tbd?
>
>> The original README.TXT in unlimited says "are exportable from the
>> United States." and you have "is exportable." now. Is this intended?
>> (IANAL)
>
> Changed.
>
>> TestUnlimited.java:
>> 45 "// Use the AES are the test Cipher", you mean "Use AES as the test
>> Cipher"?
>> 51 "throw new Exception ("Unlimited policy is NOT active");". No space
>> before "(".
>
> Fixed.
>
> Sean Mullan wrote:
>
>  > What about setting the default value to "limited"? And then this
>  > would only be changed to "unlimited" if the build --enable-unlimited-
>  > crypto option is specified?
>
> I could, but I'm concerned that a build with --enabled-unlimited-crypto
> would expect that the compiled-in version default would also be
> unlimited and would be surprised with limited.
>
> Upon Max's suggestion above, I've changed the name of the marker to
> "crypto.policy=crypto.policydir-tbd."  Does that work for you?
>
>  > Instead of throwing an exception here, I wonder if it would make more
>  > sense to assume a default value of "limited" if the property is not
>  > set or is empty.
>
> We could, but see above.
>
> Sean Coffey wrote:
>
>> Please include the exception 'e' in your last exception here.
>
> Again, I'm concerned about outputting java.home, so I'm just going to
> output the final directory name.
>
>> 3. Test case.
>>
>> The TestUnlimited.java testcase seems to be lacking. Do you want to
>> test other values for crypto.policy ? 'limited' would be one.
>> Throwing in some dummy value would also be good so that the exception
>> handling code gets exercised.
>
> Done.
>
>  * @run main/othervm TestUnlimited limited fail
>  * @run main/othervm TestUnlimited unlimited pass
>  * @run main/othervm TestUnlimited NosuchDir exception
>  * @run main/othervm TestUnlimited . exception
>  * @run main/othervm TestUnlimited /tmp/unlimited exception
>  * @run main/othervm TestUnlimited ../policy/unlimited exception
>  * @run main/othervm TestUnlimited ./unlimited exception
>
>> It needs to be run in ovm mode since you're setting a Security
>> property.
>
> Yes, good catch.
>
> Brad
>


From artem.smotrakov at oracle.com  Thu Aug 25 01:27:58 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 24 Aug 2016 18:27:58 -0700
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
References: <57BDE5B1.3010601@oracle.com>
	<b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
	<101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
Message-ID: <d59c4567-5a91-a5a9-bf01-21143a248ddf@oracle.com>

Hi Xuelei,

Please see inline.

On 08/24/2016 06:10 PM, Xuelei Fan wrote:
>
>
> On 8/25/2016 3:55 AM, Artem Smotrakov wrote:
>> Hi Svetlana,
>>
>> Thank you for cleaning up this test. I have a couple of comments (mostly
>> about the original test).
>>
>> 1. I see that the test tries to connect to a server three times, but the
>> server accept only first connection, and then it stops. So test cases
>> #2-3 fail just because the connection was refused. The original test
>> behaves like this. This looks like a bug to me. What do you think?
>> Should the server have a loop of three iterations?
>>
> I think it's the purpose to test behavior of the close server socket.
Okay, makes sense to me. I am not sure what the author meant, but I 
thought the purpose is to check if an exception is thrown when server 
accepts all connections, but then close them right away.
>
>> 2. Here is server's code:
>>
>>   95         @Override
>>   96         public void run() {
>>   97             try (Socket s = serverSocket.accept()) {
>>   98                 System.out.println("Server accepted connection");
>>   99                 // wait a bit before closing the socket to give
>>  100                 // the client time to send its hello message
>>  101                 Thread.currentThread().sleep(100);
>>  102                 s.close();
>>  103                 System.out.println("Server closed socket, done.");
>>  104             } catch (Exception e) {
>>  105                 throw new RuntimeException("Problem in test
>> execution", e);
>>  106             }
>>  107         }
>>
>> Not sure if it is a good assumption to expect that ClientHello is
>> received in 100 milliseconds. It might read first data, and then close
>> the socket. It also doesn't seem to be necessary to call close() there.
>>
> It is not expected to perform handshaking for this test.  Get 
> connection, and immediately close the socket before handshaking, and 
> then see what happens in client side (connect/read/write).
>
> I have the same concern that 100 MS may be an issue.  Please consider 
> to make an improvement.
>
> BTW, please run the test in othervm mode.
Why do you think it's necessary here? I don't see the test modifies 
anything that may affect other tests running in the same JVM (for 
example, system properties). Am I missing something?

Artem
>
> Xuelei
>
>> Otherwise, the webrev looks good to me, but please note that I am not an
>> official reviewer. You may want to fix the issues above, or we can just
>> file a new bug.
>>
>> Artem
>>
>> On 08/24/2016 11:21 AM, Svetlana Nikandrova wrote:
>>> Hello,
>>>
>>> please review this test bug fix. Test failed because of staled threads
>>> left after execution.
>>> Added try-with-resources statements to make sure test closes it's
>>> resources. Also as test is overall quite old-fashioned I've done some
>>> refactoring (hope now it looks better).
>>>
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8164533
>>> Webrev:
>>> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/
>>> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/>
>>>
>>> Thank you,
>>> Svetlana
>>



From anthony.scarpino at oracle.com  Thu Aug 25 01:58:26 2016
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 24 Aug 2016 18:58:26 -0700
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
Message-ID: <57BE50C2.2000900@oracle.com>

On 08/24/2016 05:21 PM, Bradford Wetmore wrote:
[...]
>
> Sean Mullan wrote:
>
>   > What about setting the default value to "limited"? And then this
>   > would only be changed to "unlimited" if the build --enable-unlimited-
>   > crypto option is specified?
>
> I could, but I'm concerned that a build with --enabled-unlimited-crypto
> would expect that the compiled-in version default would also be
> unlimited and would be surprised with limited.
>
> Upon Max's suggestion above, I've changed the name of the marker to
> "crypto.policy=crypto.policydir-tbd."  Does that work for you?

So by having no crypto.policy defined we have no JCA?  Does that mean no 
operations at all (No MessageDigest, etc) or no restrictable crypto ops?

Since we know a limited number of countries have import issues, can we 
make no crypto.policy property defined as unlimited policy?  Defining 
the property would be for only limiting the access.  We could get rid of 
the unlimited policy file and just ship a limited policy file.

Tony



From weijun.wang at oracle.com  Thu Aug 25 02:00:05 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 25 Aug 2016 10:00:05 +0800
Subject: RFR 7004967: SecureRandom should be more explicit about threading
Message-ID: <e98ae428-605c-844d-47c1-0869112fc5f5@oracle.com>

Please review the enhancement at

   http://cr.openjdk.java.net/~weijun/7004967/webrev.00/

Basically, we want SecureRandom to be more efficient by removing all 
synchronized keywords from its public methods and let an implementation 
to take care of thread-safety (We already did some in JDK-8098581). On 
the other hand, we need to make sure that existing implementations that 
have not synchronized correctly to behave just as good as before.

Therefore a new Service Attribute "ThreadSafe" is introduced. If you 
think your implementation is already thread-safe, set it to "true" and 
SecureRandom will be happy. Otherwise, don't set it and SecureRandom 
will continuously call your SecureRandomSpi engine methods in 
synchronized blocks.

Thanks
Max


From weijun.wang at oracle.com  Thu Aug 25 02:08:58 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 25 Aug 2016 10:08:58 +0800
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <57BE50C2.2000900@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
	<57BE50C2.2000900@oracle.com>
Message-ID: <5a7c7fe3-bb28-09f4-e403-9736e51fd799@oracle.com>

I guess we need a lawyer to answer this question. :-)

On 8/25/2016 9:58, Anthony Scarpino wrote:
> So by having no crypto.policy defined we have no JCA?  Does that mean no
> operations at all (No MessageDigest, etc) or no restrictable crypto ops?
>
> Since we know a limited number of countries have import issues, can we
> make no crypto.policy property defined as unlimited policy?  Defining
> the property would be for only limiting the access.  We could get rid of
> the unlimited policy file and just ship a limited policy file.
>
> Tony
>


From xuelei.fan at oracle.com  Thu Aug 25 02:21:53 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 25 Aug 2016 10:21:53 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <d59c4567-5a91-a5a9-bf01-21143a248ddf@oracle.com>
References: <57BDE5B1.3010601@oracle.com>
	<b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
	<101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
	<d59c4567-5a91-a5a9-bf01-21143a248ddf@oracle.com>
Message-ID: <32ffbc40-05b0-0c29-b910-79b5e2376838@oracle.com>

On 8/25/2016 9:27 AM, Artem Smotrakov wrote:
>> BTW, please run the test in othervm mode.
> Why do you think it's necessary here? I don't see the test modifies
> anything that may affect other tests running in the same JVM (for
> example, system properties). Am I missing something?
It's not about the test code, but about the JSSE impl.  The JSSE impl 
uses a lot of singleton static fields for performance.  Once these 
fields are initialized, they may impact other test cases.

In JSSE test cases, we always run in othervm mode, and put a comment 
like (See test/javax/net/ssl/templates/SSLSocketTemplate.java):

// SunJSSE does not support dynamic system properties, no way to re-use
// system properties in samevm/agentvm mode.


Xuelei


From xuelei.fan at oracle.com  Thu Aug 25 02:25:00 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 25 Aug 2016 10:25:00 +0800
Subject: RFR: 8151893: Add security property to configure XML Signature
	secure validation mode
In-Reply-To: <b633d67f-1a92-5773-8352-8d68de0e2fb0@oracle.com>
References: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>
	<b633d67f-1a92-5773-8352-8d68de0e2fb0@oracle.com>
Message-ID: <1d90b7f3-1d75-d423-e177-39fd8e279bcd@oracle.com>

On 8/25/2016 7:57 AM, Sean Mullan wrote:
> I posted an updated webrev:
> http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.0
>
I guess the link should be:

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

Xuelei

> I found an existing bug in the dsig implementation and wanted to fix it
> with this change. There are 2 ways to register an element's ID attributes:
>
> 1. Using javax.xml.crypto.dom.DOMCryptoContext.setIdAttributeNS()
> 2. Using one of the org.w3c.dom.Element.setIdAttribute*() methods
>
> The DOMURIDereferencer needs to check both mechanisms when searching for
> Id attributes (it was only checking the first). Fix has been applied to
> lines 91-96 of DOMURIDereferencer in the updated webrev.
>
> --Sean
>
> On 08/24/2016 03:17 PM, Sean Mullan wrote:
>> Please review this fix to add a new security property that allows you to
>> configure the individual restrictions that are enabled by the XML
>> Signature secure validation mode.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8151893
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.00/
>>
>> Thanks,
>> Sean


From artem.smotrakov at oracle.com  Thu Aug 25 03:17:15 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 24 Aug 2016 20:17:15 -0700 (PDT)
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
Message-ID: <2aba9d4a-d496-4c66-b8b0-a793118133f8@default>

Hi Xuelei,

Yes, I know that JSSE provider initializes only once. But I suppose that tests which use default JSSE configuration (like this test) can be safely run in agent VM. Am I missing something?

Artem

----- Original Message -----
From: xuelei.fan at oracle.com
To: artem.smotrakov at oracle.com, security-dev at openjdk.java.net
Cc: svetlana.nikandrova at oracle.com
Sent: Wednesday, August 24, 2016 7:21:55 PM GMT -08:00 US/Canada Pacific
Subject: Re: RFR 8164533: [TEST_BUG] sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error while cleaning up threads after test"

On 8/25/2016 9:27 AM, Artem Smotrakov wrote:
>> BTW, please run the test in othervm mode.
> Why do you think it's necessary here? I don't see the test modifies
> anything that may affect other tests running in the same JVM (for
> example, system properties). Am I missing something?
It's not about the test code, but about the JSSE impl.  The JSSE impl 
uses a lot of singleton static fields for performance.  Once these 
fields are initialized, they may impact other test cases.

In JSSE test cases, we always run in othervm mode, and put a comment 
like (See test/javax/net/ssl/templates/SSLSocketTemplate.java):

// SunJSSE does not support dynamic system properties, no way to re-use
// system properties in samevm/agentvm mode.


Xuelei


From xuelei.fan at oracle.com  Thu Aug 25 03:20:43 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 25 Aug 2016 11:20:43 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <2aba9d4a-d496-4c66-b8b0-a793118133f8@default>
References: <2aba9d4a-d496-4c66-b8b0-a793118133f8@default>
Message-ID: <d5ee0197-f38c-30b6-4b4e-a4c6a2bd925c@oracle.com>



On 8/25/2016 11:17 AM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> Yes, I know that JSSE provider initializes only once. But I suppose that tests which use default JSSE configuration (like this test) can be safely run in agent VM. Am I missing something?
>
The default one can be customized.  For example, the protocols, cipher 
suites, etc.  So it is not safe to run in agentvm/samevm mode.

Xuelei

> Artem
>
> ----- Original Message -----
> From: xuelei.fan at oracle.com
> To: artem.smotrakov at oracle.com, security-dev at openjdk.java.net
> Cc: svetlana.nikandrova at oracle.com
> Sent: Wednesday, August 24, 2016 7:21:55 PM GMT -08:00 US/Canada Pacific
> Subject: Re: RFR 8164533: [TEST_BUG] sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error while cleaning up threads after test"
>
> On 8/25/2016 9:27 AM, Artem Smotrakov wrote:
>>> BTW, please run the test in othervm mode.
>> Why do you think it's necessary here? I don't see the test modifies
>> anything that may affect other tests running in the same JVM (for
>> example, system properties). Am I missing something?
> It's not about the test code, but about the JSSE impl.  The JSSE impl
> uses a lot of singleton static fields for performance.  Once these
> fields are initialized, they may impact other test cases.
>
> In JSSE test cases, we always run in othervm mode, and put a comment
> like (See test/javax/net/ssl/templates/SSLSocketTemplate.java):
>
> // SunJSSE does not support dynamic system properties, no way to re-use
> // system properties in samevm/agentvm mode.
>
>
> Xuelei
>


From anthony.scarpino at oracle.com  Thu Aug 25 03:43:27 2016
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 24 Aug 2016 20:43:27 -0700
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <5a7c7fe3-bb28-09f4-e403-9736e51fd799@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
	<57BE50C2.2000900@oracle.com>
	<5a7c7fe3-bb28-09f4-e403-9736e51fd799@oracle.com>
Message-ID: <57BE695F.1090408@oracle.com>

Yuck lawyers :-)

I think the lawyers have already answered.  The huge explanation in the 
java.security file covers our responsibilities and where the user's 
responsibilities starts.  I believe what I'm talking about is just 
implementation details.

Tony

On 08/24/2016 07:08 PM, Weijun Wang wrote:
> I guess we need a lawyer to answer this question. :-)
>
> On 8/25/2016 9:58, Anthony Scarpino wrote:
>> So by having no crypto.policy defined we have no JCA?  Does that mean no
>> operations at all (No MessageDigest, etc) or no restrictable crypto ops?
>>
>> Since we know a limited number of countries have import issues, can we
>> make no crypto.policy property defined as unlimited policy?  Defining
>> the property would be for only limiting the access.  We could get rid of
>> the unlimited policy file and just ship a limited policy file.
>>
>> Tony
>>



From weijun.wang at oracle.com  Thu Aug 25 03:55:10 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 25 Aug 2016 11:55:10 +0800
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
Message-ID: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>

Hi All

Please take a look at

    http://cr.openjdk.java.net/~weijun/8164705/webrev.00

 From the beginning of JDK, FilePermission canonicalizes the input path 
and use the result in implies() and equals(). This has been a big 
performance hurt and leads to confusing results when symlinks are involved.

The code change above removes the canonicalization.

This means FilePermission on "/the/current/working/directory/x" no 
longer implies that on "x". Since this might bring quite some 
compatibility risk, the code change includes some tweaks in permission 
checking to make sure an app is still able to read "x" when the 
FilePermission granted is on "/the/current/working/directory/x". 
However, we still hope the policy to be updated to be consistent of how 
a file is actually accessed.

No tweak is devoted to make granting "/this/is/a/symlink" to imply 
reading of "/the/actual/target/file", because we think it should not.

This is quite a big behavior change. If it breaks your app/lib, or does 
not work with your customized security manager or policy implementation, 
please let us know.

Feel free to provide any feedback.

Finally, a new system property "jdk.filepermission.canonicalize" is 
introduced and it can be "true", "false", or "compat". The out-of-box 
default is "compat", which means no canonicalization with check tweaks.

Thanks
Max



From artem.smotrakov at oracle.com  Thu Aug 25 04:31:26 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Wed, 24 Aug 2016 21:31:26 -0700 (PDT)
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
Message-ID: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>

Those tests which modify default JSSE parameters should be run in othervm mode. But other tests which don't do that can be safely run in agent VM. This test doesn't seem to modify any default JSSE parameter.

Artem


----- Original Message -----
From: xuelei.fan at oracle.com
To: artem.smotrakov at oracle.com
Cc: security-dev at openjdk.java.net, svetlana.nikandrova at oracle.com
Sent: Wednesday, August 24, 2016 8:20:45 PM GMT -08:00 US/Canada Pacific
Subject: Re: RFR 8164533: [TEST_BUG] sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error while cleaning up threads after test"



On 8/25/2016 11:17 AM, Artem Smotrakov wrote:
> Hi Xuelei,
>
> Yes, I know that JSSE provider initializes only once. But I suppose that tests which use default JSSE configuration (like this test) can be safely run in agent VM. Am I missing something?
>
The default one can be customized.  For example, the protocols, cipher 
suites, etc.  So it is not safe to run in agentvm/samevm mode.

Xuelei

> Artem
>
> ----- Original Message -----
> From: xuelei.fan at oracle.com
> To: artem.smotrakov at oracle.com, security-dev at openjdk.java.net
> Cc: svetlana.nikandrova at oracle.com
> Sent: Wednesday, August 24, 2016 7:21:55 PM GMT -08:00 US/Canada Pacific
> Subject: Re: RFR 8164533: [TEST_BUG] sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error while cleaning up threads after test"
>
> On 8/25/2016 9:27 AM, Artem Smotrakov wrote:
>>> BTW, please run the test in othervm mode.
>> Why do you think it's necessary here? I don't see the test modifies
>> anything that may affect other tests running in the same JVM (for
>> example, system properties). Am I missing something?
> It's not about the test code, but about the JSSE impl.  The JSSE impl
> uses a lot of singleton static fields for performance.  Once these
> fields are initialized, they may impact other test cases.
>
> In JSSE test cases, we always run in othervm mode, and put a comment
> like (See test/javax/net/ssl/templates/SSLSocketTemplate.java):
>
> // SunJSSE does not support dynamic system properties, no way to re-use
> // system properties in samevm/agentvm mode.
>
>
> Xuelei
>


From xuelei.fan at oracle.com  Thu Aug 25 05:31:17 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 25 Aug 2016 13:31:17 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
Message-ID: <d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>

On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
> Those tests which modify default JSSE parameters should be run in othervm mode. But other tests which don't do that can be safely run in agent VM. This test doesn't seem to modify any default JSSE parameter.
>
If this test get booted, other test that need to do more customization 
may not work any more.

For example, boolean variable A is a singleton static field, default is 
true.  If A get initialized in default mode, it is "true".  It is not 
possible to customize it to "false" any more in other test in 
agentvm/samevm mode.

This test has no impact in agentvm/samevm mode unless no test run in 
agentvm/samevm mode or all tests run in agentvm/samevm mode has the same 
configuration as this one.   This assumption is too strong to follow.

Xuelei

> Artem
>
>
> ----- Original Message -----
> From: xuelei.fan at oracle.com
> To: artem.smotrakov at oracle.com
> Cc: security-dev at openjdk.java.net, svetlana.nikandrova at oracle.com
> Sent: Wednesday, August 24, 2016 8:20:45 PM GMT -08:00 US/Canada Pacific
> Subject: Re: RFR 8164533: [TEST_BUG] sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error while cleaning up threads after test"
>
>
>
> On 8/25/2016 11:17 AM, Artem Smotrakov wrote:
>> Hi Xuelei,
>>
>> Yes, I know that JSSE provider initializes only once. But I suppose that tests which use default JSSE configuration (like this test) can be safely run in agent VM. Am I missing something?
>>
> The default one can be customized.  For example, the protocols, cipher
> suites, etc.  So it is not safe to run in agentvm/samevm mode.
>
> Xuelei
>
>> Artem
>>
>> ----- Original Message -----
>> From: xuelei.fan at oracle.com
>> To: artem.smotrakov at oracle.com, security-dev at openjdk.java.net
>> Cc: svetlana.nikandrova at oracle.com
>> Sent: Wednesday, August 24, 2016 7:21:55 PM GMT -08:00 US/Canada Pacific
>> Subject: Re: RFR 8164533: [TEST_BUG] sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error while cleaning up threads after test"
>>
>> On 8/25/2016 9:27 AM, Artem Smotrakov wrote:
>>>> BTW, please run the test in othervm mode.
>>> Why do you think it's necessary here? I don't see the test modifies
>>> anything that may affect other tests running in the same JVM (for
>>> example, system properties). Am I missing something?
>> It's not about the test code, but about the JSSE impl.  The JSSE impl
>> uses a lot of singleton static fields for performance.  Once these
>> fields are initialized, they may impact other test cases.
>>
>> In JSSE test cases, we always run in othervm mode, and put a comment
>> like (See test/javax/net/ssl/templates/SSLSocketTemplate.java):
>>
>> // SunJSSE does not support dynamic system properties, no way to re-use
>> // system properties in samevm/agentvm mode.
>>
>>
>> Xuelei
>>


From weijun.wang at oracle.com  Thu Aug 25 06:06:40 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 25 Aug 2016 14:06:40 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
	<d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
Message-ID: <ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>

I think Artem is correct here.

All those tests that modify static fields should run in othervm mode, so 
that *each* runs in its *own* VM. All other tests, which make no such 
modifications, can share the *same* VM using agentvm.

On 8/25/2016 13:31, Xuelei Fan wrote:
> On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
>> Those tests which modify default JSSE parameters should be run in
>> othervm mode. But other tests which don't do that can be safely run in
>> agent VM. This test doesn't seem to modify any default JSSE parameter.
>>
> If this test get booted, other test that need to do more customization
> may not work any more.
>
> For example, boolean variable A is a singleton static field, default is
> true.  If A get initialized in default mode, it is "true".  It is not
> possible to customize it to "false" any more in other test in
> agentvm/samevm mode.

Shouldn't these "other" tests run in othervm mode?

Or, do you mean that even if a JSSE test does not modify a static field 
inside the test, it will modify some through innocent JSSE calls, so no 
JSSE test should ever run in agentvm?

I find this unnatural.

Thanks
Max

>
> This test has no impact in agentvm/samevm mode unless no test run in
> agentvm/samevm mode or all tests run in agentvm/samevm mode has the same
> configuration as this one.   This assumption is too strong to follow.
>
> Xuelei
>
>> Artem


From xuelei.fan at oracle.com  Thu Aug 25 07:43:01 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 25 Aug 2016 15:43:01 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
	<d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
	<ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>
Message-ID: <2f2756cb-00f0-eb20-4df3-64d9b8d46062@oracle.com>

On 8/25/2016 2:06 PM, Weijun Wang wrote:
> I think Artem is correct here.
>
> All those tests that modify static fields should run in othervm mode, so
> that *each* runs in its *own* VM.  All other tests, which make no such
> modifications, can share the *same* VM using agentvm.
>
It's too strong to follow.  And it is not easy to know there is no 
static fields update in a test case.

Xuelei

> On 8/25/2016 13:31, Xuelei Fan wrote:
>> On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
>>> Those tests which modify default JSSE parameters should be run in
>>> othervm mode. But other tests which don't do that can be safely run in
>>> agent VM. This test doesn't seem to modify any default JSSE parameter.
>>>
>> If this test get booted, other test that need to do more customization
>> may not work any more.
>>
>> For example, boolean variable A is a singleton static field, default is
>> true.  If A get initialized in default mode, it is "true".  It is not
>> possible to customize it to "false" any more in other test in
>> agentvm/samevm mode.
>
> Shouldn't these "other" tests run in othervm mode?
>
> Or, do you mean that even if a JSSE test does not modify a static field
> inside the test, it will modify some through innocent JSSE calls, so no
> JSSE test should ever run in agentvm?
>
> I find this unnatural.
>
> Thanks
> Max
>
>>
>> This test has no impact in agentvm/samevm mode unless no test run in
>> agentvm/samevm mode or all tests run in agentvm/samevm mode has the same
>> configuration as this one.   This assumption is too strong to follow.
>>
>> Xuelei
>>
>>> Artem


From sean.mullan at oracle.com  Thu Aug 25 12:26:15 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 25 Aug 2016 08:26:15 -0400
Subject: RFR: 8151893: Add security property to configure XML Signature
	secure validation mode
In-Reply-To: <1d90b7f3-1d75-d423-e177-39fd8e279bcd@oracle.com>
References: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>
	<b633d67f-1a92-5773-8352-8d68de0e2fb0@oracle.com>
	<1d90b7f3-1d75-d423-e177-39fd8e279bcd@oracle.com>
Message-ID: <a3fb11e2-aa5e-1768-0569-23a65186cd87@oracle.com>

On 08/24/2016 10:25 PM, Xuelei Fan wrote:
> On 8/25/2016 7:57 AM, Sean Mullan wrote:
>> I posted an updated webrev:
>> http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.0
>>
> I guess the link should be:
>
> http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.01/

Yes, thanks.

--Sean

>
> Xuelei
>
>> I found an existing bug in the dsig implementation and wanted to fix it
>> with this change. There are 2 ways to register an element's ID
>> attributes:
>>
>> 1. Using javax.xml.crypto.dom.DOMCryptoContext.setIdAttributeNS()
>> 2. Using one of the org.w3c.dom.Element.setIdAttribute*() methods
>>
>> The DOMURIDereferencer needs to check both mechanisms when searching for
>> Id attributes (it was only checking the first). Fix has been applied to
>> lines 91-96 of DOMURIDereferencer in the updated webrev.
>>
>> --Sean
>>
>> On 08/24/2016 03:17 PM, Sean Mullan wrote:
>>> Please review this fix to add a new security property that allows you to
>>> configure the individual restrictions that are enabled by the XML
>>> Signature secure validation mode.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151893
>>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.00/
>>>
>>> Thanks,
>>> Sean


From xuelei.fan at oracle.com  Thu Aug 25 13:47:58 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 25 Aug 2016 21:47:58 +0800
Subject: RFR: 8151893: Add security property to configure XML Signature
	secure validation mode
In-Reply-To: <a3fb11e2-aa5e-1768-0569-23a65186cd87@oracle.com>
References: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>
	<b633d67f-1a92-5773-8352-8d68de0e2fb0@oracle.com>
	<1d90b7f3-1d75-d423-e177-39fd8e279bcd@oracle.com>
	<a3fb11e2-aa5e-1768-0569-23a65186cd87@oracle.com>
Message-ID: <70555720-da56-4e4a-1a1a-52f7f1bcdfbb@oracle.com>

 >> http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.01/

Looks fine to me except the following minor comment.

java.security
-------------
  818 #   AlgConstraint
  819 #       "disallowAlg" Uri
  ...
  829 # For AlgConstraint, Uri is the algorithm URI String that is not 
allowed.

The "disallowAlg" has said the same thing as line 829.  As you did not 
explain other options, may be this one can also be removed.  Minor comment.


Policy.java
-----------
   73   StringTokenizer st = new StringTokenizer(entry);

StringTokenizer is a legacy class per its specification, may be better 
to use String.split:

   String[] st = entry.split("\\s");


  103   disallowedRefUriSchemes.add(scheme.toLowerCase());
Better to use toLowerCase(Locale.ENGLISH).  There are issues to use 
toUpperCase/toLowerCase when comparing two case-insensitive strings. See 
JDK-6972387.

The same comment for other use of toLowerCase().


Xuelei


From sean.coffey at oracle.com  Thu Aug 25 13:56:18 2016
From: sean.coffey at oracle.com (Sean Coffey)
Date: Thu, 25 Aug 2016 14:56:18 +0100
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
Message-ID: <cf2dff99-e92e-29ae-a66f-668a6ae75575@oracle.com>

Looks good Brad. One comment :

You might hit an NPE here but I guess the Exception handling in the 
parent call would handle it :

JceSecurity.java :
  254         if (Paths.get(cryptoPolicyProperty).getNameCount() != 1) {

Maybe add a null check to be cleaner ?

I missed the "crypto.policy=crypto.policydir-tbd" approach in 1st 
revision. Isn't it going to confuse people studying the code ? This 
value gets replaced at build time - right ? What about changing it to 
something like :
"crypto.policy=$crypto.policydir-tbd //replaced at build time"

and having the make files search for that string instead ? I think it 
makes the intent more obvious.

Regards,
Sean.

On 25/08/2016 01:21, Bradford Wetmore wrote:
> Max/SeanC/SeanM,
>
> The latest update:
>
>     http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/
>
> On 8/17/2016 9:26 PM, Wang Weijun wrote:
>> Before this change, you require default policy in neither export nor 
>> import to be empty but do not care about the getMinimum() result. In 
>> this change, you make sure the final result is not empty. I assume 
>> this is a fix?
>
> I made the change to allow for our traditional (default) export/import 
> mechanism, but other additional styles could be added/used.  Since we 
> no longer sign, distros are free to edit, add and/or remove files.  
> But before doing any JCE operation, the environment needs to grant 
> something, otherwise there are no perms and no JCE available.
>
>> 283                     // Did we find a default perms?
>>
>> What does this line mean?
>
> I've moved to the right position in the file.  I meant did we find a 
> default perms file, vs an exempt.
>
>> 296                         // This should never happen
>>
>> But you can still print out the file name.
>
> I'm concerned that the exception might print out the entire path 
> instead of just the filename, which would include java.home and 
> probably should not be made available.
>
>> Can you rename policydir-tbd to something else? I am afraid it will 
>> be confused with policy.url.1 etc.
>
> Changed to:  crypto.policydir-tbd?
>
>> The original README.TXT in unlimited says "are exportable from the 
>> United States." and you have "is exportable." now. Is this intended? 
>> (IANAL)
>
> Changed.
>
>> TestUnlimited.java:
>> 45 "// Use the AES are the test Cipher", you mean "Use AES as the 
>> test Cipher"?
>> 51 "throw new Exception ("Unlimited policy is NOT active");". No 
>> space before "(".
>
> Fixed.
>
> Sean Mullan wrote:
>
>  > What about setting the default value to "limited"? And then this
>  > would only be changed to "unlimited" if the build --enable-unlimited-
>  > crypto option is specified?
>
> I could, but I'm concerned that a build with 
> --enabled-unlimited-crypto would expect that the compiled-in version 
> default would also be unlimited and would be surprised with limited.
>
> Upon Max's suggestion above, I've changed the name of the marker to 
> "crypto.policy=crypto.policydir-tbd."  Does that work for you?
>
>  > Instead of throwing an exception here, I wonder if it would make more
>  > sense to assume a default value of "limited" if the property is not
>  > set or is empty.
>
> We could, but see above.
>
> Sean Coffey wrote:
>
> > Please include the exception 'e' in your last exception here.
>
> Again, I'm concerned about outputting java.home, so I'm just going to 
> output the final directory name.
>
> > 3. Test case.
> >
> > The TestUnlimited.java testcase seems to be lacking. Do you want to
> > test other values for crypto.policy ? 'limited' would be one.
> > Throwing in some dummy value would also be good so that the exception
> > handling code gets exercised.
>
> Done.
>
>  * @run main/othervm TestUnlimited limited fail
>  * @run main/othervm TestUnlimited unlimited pass
>  * @run main/othervm TestUnlimited NosuchDir exception
>  * @run main/othervm TestUnlimited . exception
>  * @run main/othervm TestUnlimited /tmp/unlimited exception
>  * @run main/othervm TestUnlimited ../policy/unlimited exception
>  * @run main/othervm TestUnlimited ./unlimited exception
>
> > It needs to be run in ovm mode since you're setting a Security
> > property.
>
> Yes, good catch.
>
> Brad
>



From sean.mullan at oracle.com  Thu Aug 25 14:14:10 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 25 Aug 2016 10:14:10 -0400
Subject: RFR: 8151893: Add security property to configure XML Signature
	secure validation mode
In-Reply-To: <70555720-da56-4e4a-1a1a-52f7f1bcdfbb@oracle.com>
References: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>
	<b633d67f-1a92-5773-8352-8d68de0e2fb0@oracle.com>
	<1d90b7f3-1d75-d423-e177-39fd8e279bcd@oracle.com>
	<a3fb11e2-aa5e-1768-0569-23a65186cd87@oracle.com>
	<70555720-da56-4e4a-1a1a-52f7f1bcdfbb@oracle.com>
Message-ID: <4e16ea55-a71e-37a3-8ad9-05b0a0863386@oracle.com>

On 08/25/2016 09:47 AM, Xuelei Fan wrote:
>>> http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.01/
>
> Looks fine to me except the following minor comment.
>
> java.security
> -------------
>  818 #   AlgConstraint
>  819 #       "disallowAlg" Uri
>  ...
>  829 # For AlgConstraint, Uri is the algorithm URI String that is not
> allowed.
>
> The "disallowAlg" has said the same thing as line 829.  As you did not
> explain other options, may be this one can also be removed.  Minor comment.

I thought this one deserved a little bit of explanation, since unlike 
our other JCE APIs, XML Signature algorithms are specified as URIs and 
not Strings like "MD5", so I wanted to avoid confusion with the other 
properties that take algorithm Strings. I'd like to leave this one in.

As previously mentioned, the plan is still to add a section to one of 
our user guides which will go into more details on what each restriction 
means.

> Policy.java
> -----------
>   73   StringTokenizer st = new StringTokenizer(entry);
>
> StringTokenizer is a legacy class per its specification, may be better
> to use String.split:
>
>   String[] st = entry.split("\\s");

Ok.

>  103   disallowedRefUriSchemes.add(scheme.toLowerCase());
> Better to use toLowerCase(Locale.ENGLISH).  There are issues to use
> toUpperCase/toLowerCase when comparing two case-insensitive strings. See
> JDK-6972387.

Ok.

> The same comment for other use of toLowerCase().

Ok.

Thanks,
Sean


From xuelei.fan at oracle.com  Thu Aug 25 14:36:13 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 25 Aug 2016 22:36:13 +0800
Subject: RFR: 8151893: Add security property to configure XML Signature
	secure validation mode
In-Reply-To: <4e16ea55-a71e-37a3-8ad9-05b0a0863386@oracle.com>
References: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>
	<b633d67f-1a92-5773-8352-8d68de0e2fb0@oracle.com>
	<1d90b7f3-1d75-d423-e177-39fd8e279bcd@oracle.com>
	<a3fb11e2-aa5e-1768-0569-23a65186cd87@oracle.com>
	<70555720-da56-4e4a-1a1a-52f7f1bcdfbb@oracle.com>
	<4e16ea55-a71e-37a3-8ad9-05b0a0863386@oracle.com>
Message-ID: <d9d4468d-bef1-30ba-b1c9-9943950ef992@oracle.com>

On 8/25/2016 10:14 PM, Sean Mullan wrote:
> On 08/25/2016 09:47 AM, Xuelei Fan wrote:
>>>> http://cr.openjdk.java.net/~mullan/webrevs/8151893/webrev.01/
>>
>> Looks fine to me except the following minor comment.
>>
>> java.security
>> -------------
>>  818 #   AlgConstraint
>>  819 #       "disallowAlg" Uri
>>  ...
>>  829 # For AlgConstraint, Uri is the algorithm URI String that is not
>> allowed.
>>
>> The "disallowAlg" has said the same thing as line 829.  As you did not
>> explain other options, may be this one can also be removed.  Minor
>> comment.
>
> I thought this one deserved a little bit of explanation, since unlike
> our other JCE APIs, XML Signature algorithms are specified as URIs and
> not Strings like "MD5", so I wanted to avoid confusion with the other
> properties that take algorithm Strings. I'd like to leave this one in.
>
It's OK.

Xuelei


From weijun.wang at oracle.com  Thu Aug 25 14:51:39 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 25 Aug 2016 22:51:39 +0800
Subject: RFR: 8151893: Add security property to configure XML Signature
	secure validation mode
In-Reply-To: <4e16ea55-a71e-37a3-8ad9-05b0a0863386@oracle.com>
References: <7e43c2a5-ba2e-517d-8639-24b8a368591c@oracle.com>
	<b633d67f-1a92-5773-8352-8d68de0e2fb0@oracle.com>
	<1d90b7f3-1d75-d423-e177-39fd8e279bcd@oracle.com>
	<a3fb11e2-aa5e-1768-0569-23a65186cd87@oracle.com>
	<70555720-da56-4e4a-1a1a-52f7f1bcdfbb@oracle.com>
	<4e16ea55-a71e-37a3-8ad9-05b0a0863386@oracle.com>
Message-ID: <66493ce7-43b7-b83c-84d3-c2a3853c74da@oracle.com>

I prefer Locale.ROOT now.

--Max

On 8/25/2016 22:14, Sean Mullan wrote:
>>  103   disallowedRefUriSchemes.add(scheme.toLowerCase());
>> Better to use toLowerCase(Locale.ENGLISH).  There are issues to use
>> toUpperCase/toLowerCase when comparing two case-insensitive strings. See
>> JDK-6972387.
>
> Ok.
>
>> The same comment for other use of toLowerCase().
>
> Ok.


From svetlana.nikandrova at oracle.com  Thu Aug 25 15:00:54 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Thu, 25 Aug 2016 18:00:54 +0300
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java
	failed with "Error while cleaning up threads after test"
In-Reply-To: <101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
References: <57BDE5B1.3010601@oracle.com>
	<b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
	<101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
Message-ID: <57BF0826.6080609@oracle.com>

Hi Artem, Xuelei,

thank you for your comments. Please see inline.

On 25.08.2016 4:10, Xuelei Fan wrote:
>
>
> On 8/25/2016 3:55 AM, Artem Smotrakov wrote:
>> Hi Svetlana,
>>
>> Thank you for cleaning up this test. I have a couple of comments (mostly
>> about the original test).
>>
>> 1. I see that the test tries to connect to a server three times, but the
>> server accept only first connection, and then it stops. So test cases
>> #2-3 fail just because the connection was refused. The original test
>> behaves like this. This looks like a bug to me. What do you think?
>> Should the server have a loop of three iterations?
>>
> I think it's the purpose to test behavior of the close server socket.

Yes, the test checks that if connection was closed by server during 
handshake client will get exceptions from handshake, read and write. We 
don't need to connect 3 times to check it.

>
>> 2. Here is server's code:
>>
>>   95         @Override
>>   96         public void run() {
>>   97             try (Socket s = serverSocket.accept()) {
>>   98                 System.out.println("Server accepted connection");
>>   99                 // wait a bit before closing the socket to give
>>  100                 // the client time to send its hello message
>>  101                 Thread.currentThread().sleep(100);
>>  102                 s.close();
>>  103                 System.out.println("Server closed socket, done.");
>>  104             } catch (Exception e) {
>>  105                 throw new RuntimeException("Problem in test
>> execution", e);
>>  106             }
>>  107         }
>>
>> Not sure if it is a good assumption to expect that ClientHello is
>> received in 100 milliseconds. It might read first data, and then close
>> the socket. It also doesn't seem to be necessary to call close() there.
>>
Yes, you are right. Calling close() is unnecessary in try-with-resource 
block. Removed.
> It is not expected to perform handshaking for this test.  Get 
> connection, and immediately close the socket before handshaking, and 
> then see what happens in client side (connect/read/write).
>
> I have the same concern that 100 MS may be an issue.  Please consider 
> to make an improvement.
I also not totally happy with 100 MS assumption. As Artem suggested I've 
created separate issue for that improvement: JDK-8164804 
<https://bugs.openjdk.java.net/browse/JDK-8164804>
>
> BTW, please run the test in othervm mode.

I must admitted I'm confused. AFAIK othervm is forced for tests that 
change configuration. This test uses default one.
It won't kill me to add it to this test but I'd be grateful if we could 
clarify this for future testdev.

Thanks,
Svetlana

>
> Xuelei
>
>> Otherwise, the webrev looks good to me, but please note that I am not an
>> official reviewer. You may want to fix the issues above, or we can just
>> file a new bug.
>>
>> Artem
>>
>> On 08/24/2016 11:21 AM, Svetlana Nikandrova wrote:
>>> Hello,
>>>
>>> please review this test bug fix. Test failed because of staled threads
>>> left after execution.
>>> Added try-with-resources statements to make sure test closes it's
>>> resources. Also as test is overall quite old-fashioned I've done some
>>> refactoring (hope now it looks better).
>>>
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8164533
>>> Webrev:
>>> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/
>>> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/>
>>>
>>> Thank you,
>>> Svetlana
>>

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

From Xuelei.Fan at Oracle.Com  Thu Aug 25 16:02:41 2016
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Fri, 26 Aug 2016 00:02:41 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with
	"Error while cleaning up threads after test"
In-Reply-To: <57BF0826.6080609@oracle.com>
References: <57BDE5B1.3010601@oracle.com>
	<b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
	<101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
	<57BF0826.6080609@oracle.com>
Message-ID: <1034AB31-F855-41CC-B354-8FCBBD69160C@Oracle.Com>

Just a quick reply.

1. The close is necessary.
2. Run in othervm is safer.  Please see my comments in other replies.

If you still have questions, I will reply with more details tomorrow when I work on a PC.

Xuelei



> On Aug 25, 2016, at 11:00 PM, Svetlana Nikandrova <svetlana.nikandrova at oracle.com> wrote:
> 
> Hi Artem, Xuelei,
> 
> thank you for your comments. Please see inline.
> 
>> On 25.08.2016 4:10, Xuelei Fan wrote:
>> 
>> 
>>> On 8/25/2016 3:55 AM, Artem Smotrakov wrote: 
>>> Hi Svetlana, 
>>> 
>>> Thank you for cleaning up this test. I have a couple of comments (mostly 
>>> about the original test). 
>>> 
>>> 1. I see that the test tries to connect to a server three times, but the 
>>> server accept only first connection, and then it stops. So test cases 
>>> #2-3 fail just because the connection was refused. The original test 
>>> behaves like this. This looks like a bug to me. What do you think? 
>>> Should the server have a loop of three iterations?
>> I think it's the purpose to test behavior of the close server socket. 
> 
> Yes, the test checks that if connection was closed by server during handshake client will get exceptions from handshake, read and write. We don't need to connect 3 times to check it.
>   
>> 
>>> 2. Here is server's code: 
>>> 
>>>   95         @Override 
>>>   96         public void run() { 
>>>   97             try (Socket s = serverSocket.accept()) { 
>>>   98                 System.out.println("Server accepted connection"); 
>>>   99                 // wait a bit before closing the socket to give 
>>>  100                 // the client time to send its hello message 
>>>  101                 Thread.currentThread().sleep(100); 
>>>  102                 s.close(); 
>>>  103                 System.out.println("Server closed socket, done."); 
>>>  104             } catch (Exception e) { 
>>>  105                 throw new RuntimeException("Problem in test 
>>> execution", e); 
>>>  106             } 
>>>  107         } 
>>> 
>>> Not sure if it is a good assumption to expect that ClientHello is 
>>> received in 100 milliseconds. It might read first data, and then close 
>>> the socket. It also doesn't seem to be necessary to call close() there.
> Yes, you are right. Calling close() is unnecessary in try-with-resource block. Removed.
>> It is not expected to perform handshaking for this test.  Get connection, and immediately close the socket before handshaking, and then see what happens in client side (connect/read/write). 
>> 
>> I have the same concern that 100 MS may be an issue.  Please consider to make an improvement. 
> I also not totally happy with 100 MS assumption. As Artem suggested I've created separate issue for that improvement: JDK-8164804 
>> 
>> 
>> BTW, please run the test in othervm mode. 
> 
> I must admitted I'm confused. AFAIK othervm is forced for tests that change configuration. This test uses default one.  
> It won't kill me to add it to this test but I'd be grateful if we could clarify this for future testdev.
> 
> Thanks,
> Svetlana 
> 
>> 
>> Xuelei 
>> 
>>> Otherwise, the webrev looks good to me, but please note that I am not an 
>>> official reviewer. You may want to fix the issues above, or we can just 
>>> file a new bug. 
>>> 
>>> Artem 
>>> 
>>>> On 08/24/2016 11:21 AM, Svetlana Nikandrova wrote: 
>>>> Hello, 
>>>> 
>>>> please review this test bug fix. Test failed because of staled threads 
>>>> left after execution. 
>>>> Added try-with-resources statements to make sure test closes it's 
>>>> resources. Also as test is overall quite old-fashioned I've done some 
>>>> refactoring (hope now it looks better). 
>>>> 
>>>> JBS: 
>>>> https://bugs.openjdk.java.net/browse/JDK-8164533 
>>>> Webrev: 
>>>> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/ 
>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/> 
>>>> 
>>>> Thank you, 
>>>> Svetlana 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160826/4ceb206b/attachment.htm>

From artem.smotrakov at oracle.com  Thu Aug 25 16:43:33 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 25 Aug 2016 09:43:33 -0700
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <2f2756cb-00f0-eb20-4df3-64d9b8d46062@oracle.com>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
	<d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
	<ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>
	<2f2756cb-00f0-eb20-4df3-64d9b8d46062@oracle.com>
Message-ID: <ccdf4244-14a1-3e76-dad3-f27b1336c293@oracle.com>

Hi Xuelei,

I am not sure why you think it's too strong to follow to it. To me it's 
pretty easy to see if a test calls System.setProperty() or 
Security.setProperty() methods which modify default JSSE configuration.

Is there any other way to modify default JSSE configuration, so that it 
can't be changes then?

Artem


On 08/25/2016 12:43 AM, Xuelei Fan wrote:
> On 8/25/2016 2:06 PM, Weijun Wang wrote:
>> I think Artem is correct here.
>>
>> All those tests that modify static fields should run in othervm mode, so
>> that *each* runs in its *own* VM.  All other tests, which make no such
>> modifications, can share the *same* VM using agentvm.
>>
> It's too strong to follow.  And it is not easy to know there is no 
> static fields update in a test case.
>
> Xuelei
>
>> On 8/25/2016 13:31, Xuelei Fan wrote:
>>> On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
>>>> Those tests which modify default JSSE parameters should be run in
>>>> othervm mode. But other tests which don't do that can be safely run in
>>>> agent VM. This test doesn't seem to modify any default JSSE parameter.
>>>>
>>> If this test get booted, other test that need to do more customization
>>> may not work any more.
>>>
>>> For example, boolean variable A is a singleton static field, default is
>>> true.  If A get initialized in default mode, it is "true".  It is not
>>> possible to customize it to "false" any more in other test in
>>> agentvm/samevm mode.
>>
>> Shouldn't these "other" tests run in othervm mode?
>>
>> Or, do you mean that even if a JSSE test does not modify a static field
>> inside the test, it will modify some through innocent JSSE calls, so no
>> JSSE test should ever run in agentvm?
>>
>> I find this unnatural.
>>
>> Thanks
>> Max
>>
>>>
>>> This test has no impact in agentvm/samevm mode unless no test run in
>>> agentvm/samevm mode or all tests run in agentvm/samevm mode has the 
>>> same
>>> configuration as this one.   This assumption is too strong to follow.
>>>
>>> Xuelei
>>>
>>>> Artem



From Xuelei.Fan at Oracle.Com  Thu Aug 25 17:26:31 2016
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Fri, 26 Aug 2016 01:26:31 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with
	"Error while cleaning up threads after test"
In-Reply-To: <ccdf4244-14a1-3e76-dad3-f27b1336c293@oracle.com>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
	<d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
	<ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>
	<2f2756cb-00f0-eb20-4df3-64d9b8d46062@oracle.com>
	<ccdf4244-14a1-3e76-dad3-f27b1336c293@oracle.com>
Message-ID: <A6778953-DF5D-45AD-A9F0-6F79380C4377@Oracle.Com>



> On Aug 26, 2016, at 12:43 AM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
> 
> Hi Xuelei,
> 
> I am not sure why you think it's too strong to follow to it. To me it's pretty easy to see if a test calls System.setProperty() or Security.setProperty() methods which modify default JSSE configuration.
> 
> Is there any other way to modify default JSSE configuration, so that it can't be changes then?
> 
Yes.   And even it can only be set via explicit call to setProperty(), run it in agent vm is still not safe because we don't know where the set may be used other than this test case.  It is not only about this test, the impact need to consider all JDK test cases in a big picture, which is a huge number and we cannot actually evaluate so many test cases.   I will reply more details when I have a PC tomorrow.

Xuelei

> Artem
> 
> 
>> On 08/25/2016 12:43 AM, Xuelei Fan wrote:
>>> On 8/25/2016 2:06 PM, Weijun Wang wrote:
>>> I think Artem is correct here.
>>> 
>>> All those tests that modify static fields should run in othervm mode, so
>>> that *each* runs in its *own* VM.  All other tests, which make no such
>>> modifications, can share the *same* VM using agentvm.
>> It's too strong to follow.  And it is not easy to know there is no static fields update in a test case.
>> 
>> Xuelei
>> 
>>>> On 8/25/2016 13:31, Xuelei Fan wrote:
>>>>> On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
>>>>> Those tests which modify default JSSE parameters should be run in
>>>>> othervm mode. But other tests which don't do that can be safely run in
>>>>> agent VM. This test doesn't seem to modify any default JSSE parameter.
>>>> If this test get booted, other test that need to do more customization
>>>> may not work any more.
>>>> 
>>>> For example, boolean variable A is a singleton static field, default is
>>>> true.  If A get initialized in default mode, it is "true".  It is not
>>>> possible to customize it to "false" any more in other test in
>>>> agentvm/samevm mode.
>>> 
>>> Shouldn't these "other" tests run in othervm mode?
>>> 
>>> Or, do you mean that even if a JSSE test does not modify a static field
>>> inside the test, it will modify some through innocent JSSE calls, so no
>>> JSSE test should ever run in agentvm?
>>> 
>>> I find this unnatural.
>>> 
>>> Thanks
>>> Max
>>> 
>>>> 
>>>> This test has no impact in agentvm/samevm mode unless no test run in
>>>> agentvm/samevm mode or all tests run in agentvm/samevm mode has the same
>>>> configuration as this one.   This assumption is too strong to follow.
>>>> 
>>>> Xuelei
>>>> 
>>>>> Artem
> 



From artem.smotrakov at oracle.com  Thu Aug 25 17:33:13 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 25 Aug 2016 10:33:13 -0700
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <A6778953-DF5D-45AD-A9F0-6F79380C4377@Oracle.Com>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
	<d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
	<ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>
	<2f2756cb-00f0-eb20-4df3-64d9b8d46062@oracle.com>
	<ccdf4244-14a1-3e76-dad3-f27b1336c293@oracle.com>
	<A6778953-DF5D-45AD-A9F0-6F79380C4377@Oracle.Com>
Message-ID: <e8d0739e-9eec-69e3-76b8-441ce7e4db41@oracle.com>

Hi Xuelei,


On 08/25/2016 10:26 AM, Xuelei Fan wrote:
>
>> On Aug 26, 2016, at 12:43 AM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
>>
>> Hi Xuelei,
>>
>> I am not sure why you think it's too strong to follow to it. To me it's pretty easy to see if a test calls System.setProperty() or Security.setProperty() methods which modify default JSSE configuration.
>>
>> Is there any other way to modify default JSSE configuration, so that it can't be changes then?
>>
> Yes.
Could you give an example?
> And even it can only be set via explicit call to setProperty(), run it in agent vm is still not safe because we don't know where the set may be used other than this test case.
Those tests which modify default JSSE configuration should be run in 
othervm mode. This way they won't affect any other tests.
>   It is not only about this test, the impact need to consider all JDK test cases in a big picture, which is a huge number and we cannot actually evaluate so many test cases.
I think we just need to identify all tests that modify default JSSE 
configuration, and make them run in othervm mode. I believe that 
currently most of them run in othervm mode.

Artem
> I will reply more details when I have a PC tomorrow.
>
> Xuelei
>
>> Artem
>>
>>
>>> On 08/25/2016 12:43 AM, Xuelei Fan wrote:
>>>> On 8/25/2016 2:06 PM, Weijun Wang wrote:
>>>> I think Artem is correct here.
>>>>
>>>> All those tests that modify static fields should run in othervm mode, so
>>>> that *each* runs in its *own* VM.  All other tests, which make no such
>>>> modifications, can share the *same* VM using agentvm.
>>> It's too strong to follow.  And it is not easy to know there is no static fields update in a test case.
>>>
>>> Xuelei
>>>
>>>>> On 8/25/2016 13:31, Xuelei Fan wrote:
>>>>>> On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
>>>>>> Those tests which modify default JSSE parameters should be run in
>>>>>> othervm mode. But other tests which don't do that can be safely run in
>>>>>> agent VM. This test doesn't seem to modify any default JSSE parameter.
>>>>> If this test get booted, other test that need to do more customization
>>>>> may not work any more.
>>>>>
>>>>> For example, boolean variable A is a singleton static field, default is
>>>>> true.  If A get initialized in default mode, it is "true".  It is not
>>>>> possible to customize it to "false" any more in other test in
>>>>> agentvm/samevm mode.
>>>> Shouldn't these "other" tests run in othervm mode?
>>>>
>>>> Or, do you mean that even if a JSSE test does not modify a static field
>>>> inside the test, it will modify some through innocent JSSE calls, so no
>>>> JSSE test should ever run in agentvm?
>>>>
>>>> I find this unnatural.
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>> This test has no impact in agentvm/samevm mode unless no test run in
>>>>> agentvm/samevm mode or all tests run in agentvm/samevm mode has the same
>>>>> configuration as this one.   This assumption is too strong to follow.
>>>>>
>>>>> Xuelei
>>>>>
>>>>>> Artem



From Xuelei.Fan at Oracle.Com  Thu Aug 25 17:45:17 2016
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Fri, 26 Aug 2016 01:45:17 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with
	"Error while cleaning up threads after test"
In-Reply-To: <e8d0739e-9eec-69e3-76b8-441ce7e4db41@oracle.com>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
	<d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
	<ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>
	<2f2756cb-00f0-eb20-4df3-64d9b8d46062@oracle.com>
	<ccdf4244-14a1-3e76-dad3-f27b1336c293@oracle.com>
	<A6778953-DF5D-45AD-A9F0-6F79380C4377@Oracle.Com>
	<e8d0739e-9eec-69e3-76b8-441ce7e4db41@oracle.com>
Message-ID: <17DBE19C-98CD-434C-9CD4-13093C993FDC@Oracle.Com>


> On Aug 26, 2016, at 1:33 AM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
> 
> Hi Xuelei,
> 
> 
>> On 08/25/2016 10:26 AM, Xuelei Fan wrote:
>> 
>>> On Aug 26, 2016, at 12:43 AM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
>>> 
>>> Hi Xuelei,
>>> 
>>> I am not sure why you think it's too strong to follow to it. To me it's pretty easy to see if a test calls System.setProperty() or Security.setProperty() methods which modify default JSSE configuration.
>>> 
>>> Is there any other way to modify default JSSE configuration, so that it can't be changes then?
>> Yes.
> Could you give an example?
I will give some tomorrow.  If you want to make a research by yourself, please read the jsse reference guides.


>> And even it can only be set via explicit call to setProperty(), run it in agent vm is still not safe because we don't know where the set may be used other than this test case.
> Those tests which modify default JSSE configuration should be run in othervm mode. This way they won't affect any other tests.
"Should" is an assumption,but not the reality.  And we do not always make it right even we want that.

>>  It is not only about this test, the impact need to consider all JDK test cases in a big picture, which is a huge number and we cannot actually evaluate so many test cases.
> I think we just need to identify all tests that modify default JSSE configuration, and make them run in othervm mode. I believe that currently most of them run in othervm mode.
> 
To be safe, all is needed, most is not enough.  As I said, too much test case to make the evaluation and make all right.   Reality is reality.  I will try to find some out of the jsse components tomorrow. If you want to do by yourself you can search https or ocsp or ldaps on all JDK test, it may be able to find some hints.

Xuelei

> Artem
>> I will reply more details when I have a PC tomorrow.
>> 
>> Xuelei
>> 
>>> Artem
>>> 
>>> 
>>>>> On 08/25/2016 12:43 AM, Xuelei Fan wrote:
>>>>> On 8/25/2016 2:06 PM, Weijun Wang wrote:
>>>>> I think Artem is correct here.
>>>>> 
>>>>> All those tests that modify static fields should run in othervm mode, so
>>>>> that *each* runs in its *own* VM.  All other tests, which make no such
>>>>> modifications, can share the *same* VM using agentvm.
>>>> It's too strong to follow.  And it is not easy to know there is no static fields update in a test case.
>>>> 
>>>> Xuelei
>>>> 
>>>>>>> On 8/25/2016 13:31, Xuelei Fan wrote:
>>>>>>> On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
>>>>>>> Those tests which modify default JSSE parameters should be run in
>>>>>>> othervm mode. But other tests which don't do that can be safely run in
>>>>>>> agent VM. This test doesn't seem to modify any default JSSE parameter.
>>>>>> If this test get booted, other test that need to do more customization
>>>>>> may not work any more.
>>>>>> 
>>>>>> For example, boolean variable A is a singleton static field, default is
>>>>>> true.  If A get initialized in default mode, it is "true".  It is not
>>>>>> possible to customize it to "false" any more in other test in
>>>>>> agentvm/samevm mode.
>>>>> Shouldn't these "other" tests run in othervm mode?
>>>>> 
>>>>> Or, do you mean that even if a JSSE test does not modify a static field
>>>>> inside the test, it will modify some through innocent JSSE calls, so no
>>>>> JSSE test should ever run in agentvm?
>>>>> 
>>>>> I find this unnatural.
>>>>> 
>>>>> Thanks
>>>>> Max
>>>>> 
>>>>>> This test has no impact in agentvm/samevm mode unless no test run in
>>>>>> agentvm/samevm mode or all tests run in agentvm/samevm mode has the same
>>>>>> configuration as this one.   This assumption is too strong to follow.
>>>>>> 
>>>>>> Xuelei
>>>>>> 
>>>>>>> Artem
> 



From artem.smotrakov at oracle.com  Thu Aug 25 18:52:17 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 25 Aug 2016 11:52:17 -0700
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <17DBE19C-98CD-434C-9CD4-13093C993FDC@Oracle.Com>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
	<d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
	<ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>
	<2f2756cb-00f0-eb20-4df3-64d9b8d46062@oracle.com>
	<ccdf4244-14a1-3e76-dad3-f27b1336c293@oracle.com>
	<A6778953-DF5D-45AD-A9F0-6F79380C4377@Oracle.Com>
	<e8d0739e-9eec-69e3-76b8-441ce7e4db41@oracle.com>
	<17DBE19C-98CD-434C-9CD4-13093C993FDC@Oracle.Com>
Message-ID: <8eca1a17-92b2-0836-9ba3-39e9c1605c70@oracle.com>

Sure Xuelei, I read 
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization

If I understand correctly, the most settings can be done via 
system/security properties. But there may be some other ways like 
setDefaultHostnameVerifier(), setDefaultSSLSocketFactory() methods.

My point is that it's better to run tests which don't modify the default 
JSSE configuration in agent VM. It would speed up test execution. I 
don't think that it's too hard to identify those tests which modify the 
default JSSE configuration. and run them in a separate JVM. I believe 
most of test are fine now.

I rely on your expertise, and I'll let you decide about it.

Artem

On 08/25/2016 10:45 AM, Xuelei Fan wrote:
>> On Aug 26, 2016, at 1:33 AM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
>>
>> Hi Xuelei,
>>
>>
>>> On 08/25/2016 10:26 AM, Xuelei Fan wrote:
>>>
>>>> On Aug 26, 2016, at 12:43 AM, Artem Smotrakov <artem.smotrakov at oracle.com> wrote:
>>>>
>>>> Hi Xuelei,
>>>>
>>>> I am not sure why you think it's too strong to follow to it. To me it's pretty easy to see if a test calls System.setProperty() or Security.setProperty() methods which modify default JSSE configuration.
>>>>
>>>> Is there any other way to modify default JSSE configuration, so that it can't be changes then?
>>> Yes.
>> Could you give an example?
> I will give some tomorrow.  If you want to make a research by yourself, please read the jsse reference guides.
>
>
>>> And even it can only be set via explicit call to setProperty(), run it in agent vm is still not safe because we don't know where the set may be used other than this test case.
>> Those tests which modify default JSSE configuration should be run in othervm mode. This way they won't affect any other tests.
> "Should" is an assumption,but not the reality.  And we do not always make it right even we want that.
>
>>>   It is not only about this test, the impact need to consider all JDK test cases in a big picture, which is a huge number and we cannot actually evaluate so many test cases.
>> I think we just need to identify all tests that modify default JSSE configuration, and make them run in othervm mode. I believe that currently most of them run in othervm mode.
>>
> To be safe, all is needed, most is not enough.  As I said, too much test case to make the evaluation and make all right.   Reality is reality.  I will try to find some out of the jsse components tomorrow. If you want to do by yourself you can search https or ocsp or ldaps on all JDK test, it may be able to find some hints.
>
> Xuelei
>
>> Artem
>>> I will reply more details when I have a PC tomorrow.
>>>
>>> Xuelei
>>>
>>>> Artem
>>>>
>>>>
>>>>>> On 08/25/2016 12:43 AM, Xuelei Fan wrote:
>>>>>> On 8/25/2016 2:06 PM, Weijun Wang wrote:
>>>>>> I think Artem is correct here.
>>>>>>
>>>>>> All those tests that modify static fields should run in othervm mode, so
>>>>>> that *each* runs in its *own* VM.  All other tests, which make no such
>>>>>> modifications, can share the *same* VM using agentvm.
>>>>> It's too strong to follow.  And it is not easy to know there is no static fields update in a test case.
>>>>>
>>>>> Xuelei
>>>>>
>>>>>>>> On 8/25/2016 13:31, Xuelei Fan wrote:
>>>>>>>> On 8/25/2016 12:31 PM, Artem Smotrakov wrote:
>>>>>>>> Those tests which modify default JSSE parameters should be run in
>>>>>>>> othervm mode. But other tests which don't do that can be safely run in
>>>>>>>> agent VM. This test doesn't seem to modify any default JSSE parameter.
>>>>>>> If this test get booted, other test that need to do more customization
>>>>>>> may not work any more.
>>>>>>>
>>>>>>> For example, boolean variable A is a singleton static field, default is
>>>>>>> true.  If A get initialized in default mode, it is "true".  It is not
>>>>>>> possible to customize it to "false" any more in other test in
>>>>>>> agentvm/samevm mode.
>>>>>> Shouldn't these "other" tests run in othervm mode?
>>>>>>
>>>>>> Or, do you mean that even if a JSSE test does not modify a static field
>>>>>> inside the test, it will modify some through innocent JSSE calls, so no
>>>>>> JSSE test should ever run in agentvm?
>>>>>>
>>>>>> I find this unnatural.
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>>> This test has no impact in agentvm/samevm mode unless no test run in
>>>>>>> agentvm/samevm mode or all tests run in agentvm/samevm mode has the same
>>>>>>> configuration as this one.   This assumption is too strong to follow.
>>>>>>>
>>>>>>> Xuelei
>>>>>>>
>>>>>>>> Artem



From sean.mullan at oracle.com  Thu Aug 25 19:55:44 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 25 Aug 2016 15:55:44 -0400
Subject: RFR: 8150158: Update bugs.sun.com references to bugs.java.com
Message-ID: <f9ec091e-1b35-f8eb-7dbf-f4de1b1120ed@oracle.com>

Real trivial fix, just updating obsolete bug URLs in code comments.

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

$ hg diff --nodates -a -U 1
diff -r 9c7eb3e1799f 
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
--- 
a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
+++ 
b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
@@ -152,3 +152,3 @@
              // reinstantiate Mac object to work around bug in JDK
-            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
+            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
              Mac mac = this.macAlgorithm;
diff -r 9c7eb3e1799f 
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
--- 
a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
+++ 
b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
@@ -114,3 +114,3 @@
              // reinstantiate Signature object to work around bug in JDK
-            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
+            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
              Signature sig = this.signatureAlgorithm;
diff -r 9c7eb3e1799f 
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
--- 
a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
+++ 
b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
@@ -141,3 +141,3 @@
              // reinstantiate Signature object to work around bug in JDK
-            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
+            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
              Signature sig = this.signatureAlgorithm;
diff -r 9c7eb3e1799f 
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
--- 
a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
+++ 
b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
@@ -254,3 +254,3 @@
              // reinstantiate Signature object to work around bug in JDK
-            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
+            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
              Signature sig = this.signatureAlgorithm;

--Sean


From anthony.scarpino at oracle.com  Thu Aug 25 20:58:28 2016
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 25 Aug 2016 13:58:28 -0700
Subject: RFR: 8150158: Update bugs.sun.com references to bugs.java.com
In-Reply-To: <f9ec091e-1b35-f8eb-7dbf-f4de1b1120ed@oracle.com>
References: <f9ec091e-1b35-f8eb-7dbf-f4de1b1120ed@oracle.com>
Message-ID: <57BF5BF4.4030304@oracle.com>

Looks fine to me.

Tony

On 08/25/2016 12:55 PM, Sean Mullan wrote:
> Real trivial fix, just updating obsolete bug URLs in code comments.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8150158
>
> $ hg diff --nodates -a -U 1
> diff -r 9c7eb3e1799f
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
>
> ---
> a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
>
> +++
> b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
>
> @@ -152,3 +152,3 @@
>               // reinstantiate Mac object to work around bug in JDK
> -            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
> +            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
>               Mac mac = this.macAlgorithm;
> diff -r 9c7eb3e1799f
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
>
> ---
> a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
>
> +++
> b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
>
> @@ -114,3 +114,3 @@
>               // reinstantiate Signature object to work around bug in JDK
> -            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
> +            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
>               Signature sig = this.signatureAlgorithm;
> diff -r 9c7eb3e1799f
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
>
> ---
> a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
>
> +++
> b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
>
> @@ -141,3 +141,3 @@
>               // reinstantiate Signature object to work around bug in JDK
> -            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
> +            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
>               Signature sig = this.signatureAlgorithm;
> diff -r 9c7eb3e1799f
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
>
> ---
> a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
>
> +++
> b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
>
> @@ -254,3 +254,3 @@
>               // reinstantiate Signature object to work around bug in JDK
> -            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
> +            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
>               Signature sig = this.signatureAlgorithm;
>
> --Sean



From anthony.scarpino at oracle.com  Thu Aug 25 21:20:51 2016
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 25 Aug 2016 14:20:51 -0700
Subject: RFR 8074838: Resolve disabled warnings for libj2pkcs11
Message-ID: <57BF6133.9070206@oracle.com>

Hi,

Can I get a review of this change to remove the warning suppression and 
fix the minor compiler issues that it was hiding in the pkcs11 wrapper 
library.

http://cr.openjdk.java.net/~ascarpino/8074838/webrev/

thanks

Tony



From bradford.wetmore at oracle.com  Thu Aug 25 22:56:58 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 25 Aug 2016 15:56:58 -0700
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <8bcfa44a-ecb4-ad02-0611-069cb98d1dcc@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
	<8bcfa44a-ecb4-ad02-0611-069cb98d1dcc@oracle.com>
Message-ID: <76bc1268-f9b9-c934-4c81-0cb750e2b91d@oracle.com>

Last call:

     http://cr.openjdk.java.net/~wetmore/8061842/webrev.03/

Changes from .02:

added null check for cryptoPolicyProperty
renamed javaHomePolicyPath
tweaked exception wording "files in"
added test for empty string ("").


On 8/24/2016 6:22 PM, Weijun Wang wrote:
> +        Path javaHomePath = Paths.get(javaHomeProperty, "conf",
> "security",
> +                "policy").normalize();
>
> This is not javaHomePath, but policyPath.

Renamed as javaHomePolicyPath.

> You added "cryptoPolicyProperty" to some exceptions, but the exception
> titles are "Unexpected jurisdiction policy filename found: " and
> "Couldn't parse jurisdiction policy files: ". cryptoPolicyProperty is
> not file(s). Maybe "... file(s) in " + cryptoPolicyProperty?

Sure.  Sounds good.

Tony wrote:
 > So by having no crypto.policy defined we have no JCA?

With no crypto.policy, that shuts down the JceSecurity init, and the app 
will exit with an ExceptionInInitializerError, like it does if the 
policy files are missing today.

Thanks Sean for pointing out my new NPE I just introduced! ("Maybe add a 
null check to be cleaner?")  Drat!  I would add a new test case, but 
Security.setProperty() doesn't allow for "null."

 > Does that mean no
 > operations at all (No MessageDigest, etc) or no restrictable crypto
 > ops?

Recall that our JCA/JCE Permissions model is based on positive 
permission model checks.  It would mean no CryptoPermissions would be 
created, thus any operation that needs a CryptoPermissions (implies()) 
would fail.  So if you were somehow able to get the system to have no 
policy, there would be no Permissions granted to do any JCE operations.


As an aside, it would only fail JCE (Cipher/Mac/KeyAgreement), JCA would 
be unaffected as it doesn't use permissions.

 > Since we know a limited number of countries have import issues, can we
 > make no crypto.policy property defined as unlimited policy?  Defining
 > the property would be for only limiting the access.  We could get rid of
 > the unlimited policy file and just ship a limited policy file.

I'm very hesitant to do that, we need to be limited by default.

On 8/25/2016 6:56 AM, Sean Coffey wrote:
 > I missed the "crypto.policy=crypto.policydir-tbd" approach in 1st
 > revision. Isn't it going to confuse people studying the code ? This
 > value gets replaced at build time - right ?

Yes.

 > What about changing it to
 > something like :
 > "crypto.policy=$crypto.policydir-tbd //replaced at build time"
 >
 > and having the make files search for that string instead ? I think it
 > makes the intent more obvious.

We're doing the same thing with "tbd" during the provider slot 
assignment. I'd like to keep it somewhat similar.

Brad



> No other comment.
>
> Thanks
> Max
>
> On 8/25/2016 8:21, Bradford Wetmore wrote:
>> Max/SeanC/SeanM,
>>
>> The latest update:
>>
>>     http://cr.openjdk.java.net/~wetmore/8061842/webrev.02/
>>
>> On 8/17/2016 9:26 PM, Wang Weijun wrote:
>>> Before this change, you require default policy in neither export nor
>>> import to be empty but do not care about the getMinimum() result. In
>>> this change, you make sure the final result is not empty. I assume
>>> this is a fix?
>>
>> I made the change to allow for our traditional (default) export/import
>> mechanism, but other additional styles could be added/used.  Since we no
>> longer sign, distros are free to edit, add and/or remove files.  But
>> before doing any JCE operation, the environment needs to grant
>> something, otherwise there are no perms and no JCE available.
>>
>>> 283                     // Did we find a default perms?
>>>
>>> What does this line mean?
>>
>> I've moved to the right position in the file.  I meant did we find a
>> default perms file, vs an exempt.
>>
>>> 296                         // This should never happen
>>>
>>> But you can still print out the file name.
>>
>> I'm concerned that the exception might print out the entire path instead
>> of just the filename, which would include java.home and probably should
>> not be made available.
>>
>>> Can you rename policydir-tbd to something else? I am afraid it will be
>>> confused with policy.url.1 etc.
>>
>> Changed to:  crypto.policydir-tbd?
>>
>>> The original README.TXT in unlimited says "are exportable from the
>>> United States." and you have "is exportable." now. Is this intended?
>>> (IANAL)
>>
>> Changed.
>>
>>> TestUnlimited.java:
>>> 45 "// Use the AES are the test Cipher", you mean "Use AES as the test
>>> Cipher"?
>>> 51 "throw new Exception ("Unlimited policy is NOT active");". No space
>>> before "(".
>>
>> Fixed.
>>
>> Sean Mullan wrote:
>>
>>  > What about setting the default value to "limited"? And then this
>>  > would only be changed to "unlimited" if the build --enable-unlimited-
>>  > crypto option is specified?
>>
>> I could, but I'm concerned that a build with --enabled-unlimited-crypto
>> would expect that the compiled-in version default would also be
>> unlimited and would be surprised with limited.
>>
>> Upon Max's suggestion above, I've changed the name of the marker to
>> "crypto.policy=crypto.policydir-tbd."  Does that work for you?
>>
>>  > Instead of throwing an exception here, I wonder if it would make more
>>  > sense to assume a default value of "limited" if the property is not
>>  > set or is empty.
>>
>> We could, but see above.
>>
>> Sean Coffey wrote:
>>
>>> Please include the exception 'e' in your last exception here.
>>
>> Again, I'm concerned about outputting java.home, so I'm just going to
>> output the final directory name.
>>
>>> 3. Test case.
>>>
>>> The TestUnlimited.java testcase seems to be lacking. Do you want to
>>> test other values for crypto.policy ? 'limited' would be one.
>>> Throwing in some dummy value would also be good so that the exception
>>> handling code gets exercised.
>>
>> Done.
>>
>>  * @run main/othervm TestUnlimited limited fail
>>  * @run main/othervm TestUnlimited unlimited pass
>>  * @run main/othervm TestUnlimited NosuchDir exception
>>  * @run main/othervm TestUnlimited . exception
>>  * @run main/othervm TestUnlimited /tmp/unlimited exception
>>  * @run main/othervm TestUnlimited ../policy/unlimited exception
>>  * @run main/othervm TestUnlimited ./unlimited exception
>>
>>> It needs to be run in ovm mode since you're setting a Security
>>> property.
>>
>> Yes, good catch.
>>
>> Brad
>>


From bradford.wetmore at oracle.com  Thu Aug 25 23:10:48 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 25 Aug 2016 16:10:48 -0700
Subject: RFR 8074838: Resolve disabled warnings for libj2pkcs11
In-Reply-To: <57BF6133.9070206@oracle.com>
References: <57BF6133.9070206@oracle.com>
Message-ID: <4ab96d2d-5a6b-e039-226f-29fd51e67c0c@oracle.com>

Looks ok to me...

I had to look at the C declaration one twice.  Too much Java, not enough 
C lately.

Brad



On 8/25/2016 2:20 PM, Anthony Scarpino wrote:
> Hi,
>
> Can I get a review of this change to remove the warning suppression and
> fix the minor compiler issues that it was hiding in the pkcs11 wrapper
> library.
>
> http://cr.openjdk.java.net/~ascarpino/8074838/webrev/
>
> thanks
>
> Tony
>


From weijun.wang at oracle.com  Fri Aug 26 03:05:47 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 26 Aug 2016 11:05:47 +0800
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <76bc1268-f9b9-c934-4c81-0cb750e2b91d@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
	<8bcfa44a-ecb4-ad02-0611-069cb98d1dcc@oracle.com>
	<76bc1268-f9b9-c934-4c81-0cb750e2b91d@oracle.com>
Message-ID: <f369e2d0-a61c-e97b-2da2-f84d3205410d@oracle.com>

Can you add a new @run line which is the getNameCount()==1 but 
getParent() != policyPath case?

+ * @run main/othervm TestUnlimited /unlimited exception

No other comment.

On 8/26/2016 6:56, Bradford Wetmore wrote:
> Last call:
>
>     http://cr.openjdk.java.net/~wetmore/8061842/webrev.03/
>
> Thanks Sean for pointing out my new NPE I just introduced! ("Maybe add a
> null check to be cleaner?")  Drat!  I would add a new test case, but
> Security.setProperty() doesn't allow for "null."

I always wanted a Security::clearProperty().

--Max


From weijun.wang at oracle.com  Fri Aug 26 04:14:07 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 26 Aug 2016 12:14:07 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <8eca1a17-92b2-0836-9ba3-39e9c1605c70@oracle.com>
References: <b63b9ee1-7f88-4697-9f48-c323e8eb2680@default>
	<d41fd2c8-8c35-2d38-eab6-b35fdd8734ab@oracle.com>
	<ee653d54-58c0-7c97-3f60-924780de468a@oracle.com>
	<2f2756cb-00f0-eb20-4df3-64d9b8d46062@oracle.com>
	<ccdf4244-14a1-3e76-dad3-f27b1336c293@oracle.com>
	<A6778953-DF5D-45AD-A9F0-6F79380C4377@Oracle.Com>
	<e8d0739e-9eec-69e3-76b8-441ce7e4db41@oracle.com>
	<17DBE19C-98CD-434C-9CD4-13093C993FDC@Oracle.Com>
	<8eca1a17-92b2-0836-9ba3-39e9c1605c70@oracle.com>
Message-ID: <adc511dc-6a95-b705-2a6b-975add23c4b1@oracle.com>

On 8/26/2016 2:52, Artem Smotrakov wrote:
> My point is that it's better to run tests which don't modify the default
> JSSE configuration in agent VM. It would speed up test execution.

Another benefit of this is that if the test still fails it might reveal 
a real bug.

--Max


From erik.joelsson at oracle.com  Fri Aug 26 07:19:09 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 26 Aug 2016 09:19:09 +0200
Subject: RFR 8074838: Resolve disabled warnings for libj2pkcs11
In-Reply-To: <57BF6133.9070206@oracle.com>
References: <57BF6133.9070206@oracle.com>
Message-ID: <cfe18e40-7548-24c5-3a60-5db930b30e19@oracle.com>

Looks ok to me.

/Erik

On 2016-08-25 23:20, Anthony Scarpino wrote:
> Hi,
>
> Can I get a review of this change to remove the warning suppression 
> and fix the minor compiler issues that it was hiding in the pkcs11 
> wrapper library.
>
> http://cr.openjdk.java.net/~ascarpino/8074838/webrev/
>
> thanks
>
> Tony
>



From sibabrata.sahoo at oracle.com  Fri Aug 26 10:39:20 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Fri, 26 Aug 2016 03:39:20 -0700 (PDT)
Subject: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java
	fails with Timeout error
In-Reply-To: <c0578e90-ca11-4234-ba72-a2b1818a34e6@default>
References: <c0578e90-ca11-4234-ba72-a2b1818a34e6@default>
Message-ID: <b2220649-b129-4ec0-96fa-61579a16d8ca@default>

Hi,

 

Here is the latest webrev: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/

 

I have updated the test with these additional support,

1)      Verifying, if the port is reachable or PortUnreachableException is supported by the platform, otherwise the Test will terminate itself with warning.

2)      Removed the test from ProblemList.txt for MAC OS because of #1.

3)      Uses only one KDC port in the configuration file.

4)      Removed static "unreachable.krb5.conf" as the Test creates the file during runtime.

 

Thanks,

Siba

 

From: Sibabrata Sahoo 
Sent: Wednesday, August 24, 2016 9:46 PM
To: Weijun Wang; security-dev at openjdk.java.net
Subject: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java fails with Timeout error

 

Hi,

 

Please review the patch for "sun/security/krb5/auto/Unreachable.java fails with Timeout error"

 

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

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

 

Description:

When a KDC port is unreachable, Kerberos login module depends on PortUnreachableException to exit immediately. But as per JavaDoc for receive() in "java.net.DatagramSocket", the PortUnreachableException is not guaranteed. In such case the Login module waits for 90 second by default. But the JTREG Test timeout has been set for 10 second and because of that the Test gets timeout.

 

Since the "intermittent" failure is unavoidable due to  "PortUnreachableException is not guaranteed", I have provided a fix to print a warning message for such cases instead of making the Test timeout.

 

Thanks,

Siba

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

From svetlana.nikandrova at oracle.com  Fri Aug 26 10:51:12 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Fri, 26 Aug 2016 13:51:12 +0300
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java
	failed with "Error while cleaning up threads after test"
In-Reply-To: <1034AB31-F855-41CC-B354-8FCBBD69160C@Oracle.Com>
References: <57BDE5B1.3010601@oracle.com>
	<b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
	<101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
	<57BF0826.6080609@oracle.com>
	<1034AB31-F855-41CC-B354-8FCBBD69160C@Oracle.Com>
Message-ID: <57C01F20.5060507@oracle.com>

Ok, it's better to be safe than sorry. Added othervm:

http://cr.openjdk.java.net/~snikandrova/8164533/webrev.01/ 
<http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.01/>

Thank you,
Svetlana

On 25.08.2016 19:02, Xuelei Fan wrote:
> Just a quick reply.
>
> 1. The close is necessary.
> 2. Run in othervm is safer.  Please see my comments in other replies.
>
> If you still have questions, I will reply with more details tomorrow 
> when I work on a PC.
>
> Xuelei
>
>
>
> On Aug 25, 2016, at 11:00 PM, Svetlana Nikandrova 
> <svetlana.nikandrova at oracle.com 
> <mailto:svetlana.nikandrova at oracle.com>> wrote:
>
>> Hi Artem, Xuelei,
>>
>> thank you for your comments. Please see inline.
>>
>> On 25.08.2016 4:10, Xuelei Fan wrote:
>>>
>>>
>>> On 8/25/2016 3:55 AM, Artem Smotrakov wrote:
>>>> Hi Svetlana,
>>>>
>>>> Thank you for cleaning up this test. I have a couple of comments 
>>>> (mostly
>>>> about the original test).
>>>>
>>>> 1. I see that the test tries to connect to a server three times, 
>>>> but the
>>>> server accept only first connection, and then it stops. So test cases
>>>> #2-3 fail just because the connection was refused. The original test
>>>> behaves like this. This looks like a bug to me. What do you think?
>>>> Should the server have a loop of three iterations?
>>>>
>>> I think it's the purpose to test behavior of the close server socket.
>>
>> Yes, the test checks that if connection was closed by server during 
>> handshake client will get exceptions from handshake, read and write. 
>> We don't need to connect 3 times to check it.
>>
>>>
>>>> 2. Here is server's code:
>>>>
>>>>   95         @Override
>>>>   96         public void run() {
>>>>   97             try (Socket s = serverSocket.accept()) {
>>>>   98                 System.out.println("Server accepted connection");
>>>>   99                 // wait a bit before closing the socket to give
>>>>  100                 // the client time to send its hello message
>>>>  101                 Thread.currentThread().sleep(100);
>>>>  102                 s.close();
>>>>  103                 System.out.println("Server closed socket, 
>>>> done.");
>>>>  104             } catch (Exception e) {
>>>>  105                 throw new RuntimeException("Problem in test
>>>> execution", e);
>>>>  106             }
>>>>  107         }
>>>>
>>>> Not sure if it is a good assumption to expect that ClientHello is
>>>> received in 100 milliseconds. It might read first data, and then close
>>>> the socket. It also doesn't seem to be necessary to call close() 
>>>> there.
>>>>
>> Yes, you are right. Calling close() is unnecessary in 
>> try-with-resource block. Removed.
>>> It is not expected to perform handshaking for this test.  Get 
>>> connection, and immediately close the socket before handshaking, and 
>>> then see what happens in client side (connect/read/write).
>>>
>>> I have the same concern that 100 MS may be an issue.  Please 
>>> consider to make an improvement.
>> I also not totally happy with 100 MS assumption. As Artem suggested 
>> I've created separate issue for that improvement: JDK-8164804 
>> <https://bugs.openjdk.java.net/browse/JDK-8164804>
>>>
>>> BTW, please run the test in othervm mode.
>>
>> I must admitted I'm confused. AFAIK othervm is forced for tests that 
>> change configuration. This test uses default one.
>> It won't kill me to add it to this test but I'd be grateful if we 
>> could clarify this for future testdev.
>>
>> Thanks,
>> Svetlana
>>
>>>
>>> Xuelei
>>>
>>>> Otherwise, the webrev looks good to me, but please note that I am 
>>>> not an
>>>> official reviewer. You may want to fix the issues above, or we can 
>>>> just
>>>> file a new bug.
>>>>
>>>> Artem
>>>>
>>>> On 08/24/2016 11:21 AM, Svetlana Nikandrova wrote:
>>>>> Hello,
>>>>>
>>>>> please review this test bug fix. Test failed because of staled 
>>>>> threads
>>>>> left after execution.
>>>>> Added try-with-resources statements to make sure test closes it's
>>>>> resources. Also as test is overall quite old-fashioned I've done some
>>>>> refactoring (hope now it looks better).
>>>>>
>>>>> JBS:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8164533
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/>
>>>>>
>>>>> Thank you,
>>>>> Svetlana
>>>>
>>

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

From sean.mullan at oracle.com  Fri Aug 26 12:13:18 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 26 Aug 2016 08:13:18 -0400
Subject: RFR: 8024714: In java.security file, ocsp.responderCertSubjectName
	should not contain quotes
Message-ID: <ba728289-a5bd-a951-11fb-2ca1039bdc56@oracle.com>

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

A trivial fix to remove the quotes from the ocsp property name examples 
in the java.security file as they should not be included and will cause 
a parsing exception if included:

$ hg diff -U 1 --nodates
diff -r 8c0d4a9bfea1 src/java.base/share/conf/security/java.security
--- a/src/java.base/share/conf/security/java.security
+++ b/src/java.base/share/conf/security/java.security
@@ -492,3 +492,3 @@
  # Example,
-#   ocsp.responderCertSubjectName="CN=OCSP Responder, O=XYZ Corp"
+#   ocsp.responderCertSubjectName=CN=OCSP Responder, O=XYZ Corp

@@ -507,3 +507,3 @@
  # Example,
-#   ocsp.responderCertIssuerName="CN=Enterprise CA, O=XYZ Corp"
+#   ocsp.responderCertIssuerName=CN=Enterprise CA, O=XYZ Corp

Thanks,
Sean


From vincent.x.ryan at oracle.com  Fri Aug 26 12:15:22 2016
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 26 Aug 2016 13:15:22 +0100
Subject: RFR: 8024714: In java.security file,
	ocsp.responderCertSubjectName should not contain quotes
In-Reply-To: <ba728289-a5bd-a951-11fb-2ca1039bdc56@oracle.com>
References: <ba728289-a5bd-a951-11fb-2ca1039bdc56@oracle.com>
Message-ID: <F2E0574D-3F7A-45E7-B38E-C0539E451DA6@oracle.com>

Looks fine to me.

> On 26 Aug 2016, at 13:13, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8024714
> 
> A trivial fix to remove the quotes from the ocsp property name examples in the java.security file as they should not be included and will cause a parsing exception if included:
> 
> $ hg diff -U 1 --nodates
> diff -r 8c0d4a9bfea1 src/java.base/share/conf/security/java.security
> --- a/src/java.base/share/conf/security/java.security
> +++ b/src/java.base/share/conf/security/java.security
> @@ -492,3 +492,3 @@
> # Example,
> -#   ocsp.responderCertSubjectName="CN=OCSP Responder, O=XYZ Corp"
> +#   ocsp.responderCertSubjectName=CN=OCSP Responder, O=XYZ Corp
> 
> @@ -507,3 +507,3 @@
> # Example,
> -#   ocsp.responderCertIssuerName="CN=Enterprise CA, O=XYZ Corp"
> +#   ocsp.responderCertIssuerName=CN=Enterprise CA, O=XYZ Corp
> 
> Thanks,
> Sean



From xuelei.fan at oracle.com  Fri Aug 26 13:49:28 2016
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 26 Aug 2016 21:49:28 +0800
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error
	while cleaning up threads after test"
In-Reply-To: <57C01F20.5060507@oracle.com>
References: <57BDE5B1.3010601@oracle.com>
	<b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
	<101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
	<57BF0826.6080609@oracle.com>
	<1034AB31-F855-41CC-B354-8FCBBD69160C@Oracle.Com>
	<57C01F20.5060507@oracle.com>
Message-ID: <8f0be1c3-9a23-7a86-7ad0-b3ef49cc4e96@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 8/26/2016 6:51 PM, Svetlana Nikandrova wrote:
> Ok, it's better to be safe than sorry. Added othervm:
>
> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.01/
> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.01/>
>
> Thank you,
> Svetlana
>
> On 25.08.2016 19:02, Xuelei Fan wrote:
>> Just a quick reply.
>>
>> 1. The close is necessary.
>> 2. Run in othervm is safer.  Please see my comments in other replies.
>>
>> If you still have questions, I will reply with more details tomorrow
>> when I work on a PC.
>>
>> Xuelei
>>
>>
>>
>> On Aug 25, 2016, at 11:00 PM, Svetlana Nikandrova
>> <svetlana.nikandrova at oracle.com
>> <mailto:svetlana.nikandrova at oracle.com>> wrote:
>>
>>> Hi Artem, Xuelei,
>>>
>>> thank you for your comments. Please see inline.
>>>
>>> On 25.08.2016 4:10, Xuelei Fan wrote:
>>>>
>>>>
>>>> On 8/25/2016 3:55 AM, Artem Smotrakov wrote:
>>>>> Hi Svetlana,
>>>>>
>>>>> Thank you for cleaning up this test. I have a couple of comments
>>>>> (mostly
>>>>> about the original test).
>>>>>
>>>>> 1. I see that the test tries to connect to a server three times,
>>>>> but the
>>>>> server accept only first connection, and then it stops. So test cases
>>>>> #2-3 fail just because the connection was refused. The original test
>>>>> behaves like this. This looks like a bug to me. What do you think?
>>>>> Should the server have a loop of three iterations?
>>>>>
>>>> I think it's the purpose to test behavior of the close server socket.
>>>
>>> Yes, the test checks that if connection was closed by server during
>>> handshake client will get exceptions from handshake, read and write.
>>> We don't need to connect 3 times to check it.
>>>
>>>>
>>>>> 2. Here is server's code:
>>>>>
>>>>>   95         @Override
>>>>>   96         public void run() {
>>>>>   97             try (Socket s = serverSocket.accept()) {
>>>>>   98                 System.out.println("Server accepted connection");
>>>>>   99                 // wait a bit before closing the socket to give
>>>>>  100                 // the client time to send its hello message
>>>>>  101                 Thread.currentThread().sleep(100);
>>>>>  102                 s.close();
>>>>>  103                 System.out.println("Server closed socket,
>>>>> done.");
>>>>>  104             } catch (Exception e) {
>>>>>  105                 throw new RuntimeException("Problem in test
>>>>> execution", e);
>>>>>  106             }
>>>>>  107         }
>>>>>
>>>>> Not sure if it is a good assumption to expect that ClientHello is
>>>>> received in 100 milliseconds. It might read first data, and then close
>>>>> the socket. It also doesn't seem to be necessary to call close()
>>>>> there.
>>>>>
>>> Yes, you are right. Calling close() is unnecessary in
>>> try-with-resource block. Removed.
>>>> It is not expected to perform handshaking for this test.  Get
>>>> connection, and immediately close the socket before handshaking, and
>>>> then see what happens in client side (connect/read/write).
>>>>
>>>> I have the same concern that 100 MS may be an issue.  Please
>>>> consider to make an improvement.
>>> I also not totally happy with 100 MS assumption. As Artem suggested
>>> I've created separate issue for that improvement: JDK-8164804
>>> <https://bugs.openjdk.java.net/browse/JDK-8164804>
>>>>
>>>> BTW, please run the test in othervm mode.
>>>
>>> I must admitted I'm confused. AFAIK othervm is forced for tests that
>>> change configuration. This test uses default one.
>>> It won't kill me to add it to this test but I'd be grateful if we
>>> could clarify this for future testdev.
>>>
>>> Thanks,
>>> Svetlana
>>>
>>>>
>>>> Xuelei
>>>>
>>>>> Otherwise, the webrev looks good to me, but please note that I am
>>>>> not an
>>>>> official reviewer. You may want to fix the issues above, or we can
>>>>> just
>>>>> file a new bug.
>>>>>
>>>>> Artem
>>>>>
>>>>> On 08/24/2016 11:21 AM, Svetlana Nikandrova wrote:
>>>>>> Hello,
>>>>>>
>>>>>> please review this test bug fix. Test failed because of staled
>>>>>> threads
>>>>>> left after execution.
>>>>>> Added try-with-resources statements to make sure test closes it's
>>>>>> resources. Also as test is overall quite old-fashioned I've done some
>>>>>> refactoring (hope now it looks better).
>>>>>>
>>>>>> JBS:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8164533
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/>
>>>>>>
>>>>>> Thank you,
>>>>>> Svetlana
>>>>>
>>>
>


From svetlana.nikandrova at oracle.com  Fri Aug 26 15:45:49 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Fri, 26 Aug 2016 18:45:49 +0300
Subject: RFR 8164533: [TEST_BUG]
	sun/security/ssl/SSLSocketImpl/CloseSocket.java
	failed with "Error while cleaning up threads after test"
In-Reply-To: <8f0be1c3-9a23-7a86-7ad0-b3ef49cc4e96@oracle.com>
References: <57BDE5B1.3010601@oracle.com>
	<b43191a6-a04a-f029-26dc-29fe71d5e83b@oracle.com>
	<101564da-f528-72f2-c0dc-eaf6dcbf5dbc@oracle.com>
	<57BF0826.6080609@oracle.com>
	<1034AB31-F855-41CC-B354-8FCBBD69160C@Oracle.Com>
	<57C01F20.5060507@oracle.com>
	<8f0be1c3-9a23-7a86-7ad0-b3ef49cc4e96@oracle.com>
Message-ID: <57C0642D.9010408@oracle.com>

Thank you!

On 26.08.2016 16:49, Xuelei Fan wrote:
> Looks fine to me.
>
> Thanks,
> Xuelei
>
> On 8/26/2016 6:51 PM, Svetlana Nikandrova wrote:
>> Ok, it's better to be safe than sorry. Added othervm:
>>
>> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.01/
>> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.01/>
>>
>> Thank you,
>> Svetlana
>>
>> On 25.08.2016 19:02, Xuelei Fan wrote:
>>> Just a quick reply.
>>>
>>> 1. The close is necessary.
>>> 2. Run in othervm is safer.  Please see my comments in other replies.
>>>
>>> If you still have questions, I will reply with more details tomorrow
>>> when I work on a PC.
>>>
>>> Xuelei
>>>
>>>
>>>
>>> On Aug 25, 2016, at 11:00 PM, Svetlana Nikandrova
>>> <svetlana.nikandrova at oracle.com
>>> <mailto:svetlana.nikandrova at oracle.com>> wrote:
>>>
>>>> Hi Artem, Xuelei,
>>>>
>>>> thank you for your comments. Please see inline.
>>>>
>>>> On 25.08.2016 4:10, Xuelei Fan wrote:
>>>>>
>>>>>
>>>>> On 8/25/2016 3:55 AM, Artem Smotrakov wrote:
>>>>>> Hi Svetlana,
>>>>>>
>>>>>> Thank you for cleaning up this test. I have a couple of comments
>>>>>> (mostly
>>>>>> about the original test).
>>>>>>
>>>>>> 1. I see that the test tries to connect to a server three times,
>>>>>> but the
>>>>>> server accept only first connection, and then it stops. So test 
>>>>>> cases
>>>>>> #2-3 fail just because the connection was refused. The original test
>>>>>> behaves like this. This looks like a bug to me. What do you think?
>>>>>> Should the server have a loop of three iterations?
>>>>>>
>>>>> I think it's the purpose to test behavior of the close server socket.
>>>>
>>>> Yes, the test checks that if connection was closed by server during
>>>> handshake client will get exceptions from handshake, read and write.
>>>> We don't need to connect 3 times to check it.
>>>>
>>>>>
>>>>>> 2. Here is server's code:
>>>>>>
>>>>>>   95         @Override
>>>>>>   96         public void run() {
>>>>>>   97             try (Socket s = serverSocket.accept()) {
>>>>>>   98                 System.out.println("Server accepted 
>>>>>> connection");
>>>>>>   99                 // wait a bit before closing the socket to give
>>>>>>  100                 // the client time to send its hello message
>>>>>>  101                 Thread.currentThread().sleep(100);
>>>>>>  102                 s.close();
>>>>>>  103                 System.out.println("Server closed socket,
>>>>>> done.");
>>>>>>  104             } catch (Exception e) {
>>>>>>  105                 throw new RuntimeException("Problem in test
>>>>>> execution", e);
>>>>>>  106             }
>>>>>>  107         }
>>>>>>
>>>>>> Not sure if it is a good assumption to expect that ClientHello is
>>>>>> received in 100 milliseconds. It might read first data, and then 
>>>>>> close
>>>>>> the socket. It also doesn't seem to be necessary to call close()
>>>>>> there.
>>>>>>
>>>> Yes, you are right. Calling close() is unnecessary in
>>>> try-with-resource block. Removed.
>>>>> It is not expected to perform handshaking for this test.  Get
>>>>> connection, and immediately close the socket before handshaking, and
>>>>> then see what happens in client side (connect/read/write).
>>>>>
>>>>> I have the same concern that 100 MS may be an issue. Please
>>>>> consider to make an improvement.
>>>> I also not totally happy with 100 MS assumption. As Artem suggested
>>>> I've created separate issue for that improvement: JDK-8164804
>>>> <https://bugs.openjdk.java.net/browse/JDK-8164804>
>>>>>
>>>>> BTW, please run the test in othervm mode.
>>>>
>>>> I must admitted I'm confused. AFAIK othervm is forced for tests that
>>>> change configuration. This test uses default one.
>>>> It won't kill me to add it to this test but I'd be grateful if we
>>>> could clarify this for future testdev.
>>>>
>>>> Thanks,
>>>> Svetlana
>>>>
>>>>>
>>>>> Xuelei
>>>>>
>>>>>> Otherwise, the webrev looks good to me, but please note that I am
>>>>>> not an
>>>>>> official reviewer. You may want to fix the issues above, or we can
>>>>>> just
>>>>>> file a new bug.
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 08/24/2016 11:21 AM, Svetlana Nikandrova wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> please review this test bug fix. Test failed because of staled
>>>>>>> threads
>>>>>>> left after execution.
>>>>>>> Added try-with-resources statements to make sure test closes it's
>>>>>>> resources. Also as test is overall quite old-fashioned I've done 
>>>>>>> some
>>>>>>> refactoring (hope now it looks better).
>>>>>>>
>>>>>>> JBS:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8164533
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~snikandrova/8164533/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8164533/webrev.00/>
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Svetlana
>>>>>>
>>>>
>>



From sean.mullan at oracle.com  Fri Aug 26 15:57:01 2016
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 26 Aug 2016 11:57:01 -0400
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
Message-ID: <fd89c3bc-00cd-d8f8-dab6-0dd60541fddf@oracle.com>

On 08/24/2016 08:21 PM, Bradford Wetmore wrote:
> Sean Mullan wrote:
>
>  > What about setting the default value to "limited"? And then this
>  > would only be changed to "unlimited" if the build --enable-unlimited-
>  > crypto option is specified?
>
> I could, but I'm concerned that a build with --enabled-unlimited-crypto
> would expect that the compiled-in version default would also be
> unlimited and would be surprised with limited.
>
> Upon Max's suggestion above, I've changed the name of the marker to
> "crypto.policy=crypto.policydir-tbd."  Does that work for you?

Not really.

Why not just leave the property unset (or commented out)? That seems 
more intuitive to me. What if the placeholder value accidentally never 
gets replaced?

Anyway, if time is of the essence, go with what you have. This is not a 
significant issue.

--Sean


From svetlana.nikandrova at oracle.com  Fri Aug 26 17:58:01 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Fri, 26 Aug 2016 20:58:01 +0300
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
Message-ID: <57C08329.10401@oracle.com>

Hello,

please review this fix. It's not possible to read PKCS12 keystore with 
big undefined length DER value in it from SequenceInputStream. Root 
cause of the problem is that sun.security.util.DerValue relays on 
InputStream.available() to get a complete 'indefinite.length' section 
length and then read it, but for SequenceInputStream this method returns 
number of available bytes only for current input stream, not the whole 
sequence. Fixed to read all available data.

JBS:
https://bugs.openjdk.java.net/browse/JDK-8157404
Webrev:
http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/ 
<http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>

Thanks,
Svetlana
<http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20160826/50126949/attachment.htm>

From bradford.wetmore at oracle.com  Fri Aug 26 18:18:11 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 26 Aug 2016 11:18:11 -0700
Subject: RFR: 8150158: Update bugs.sun.com references to bugs.java.com
In-Reply-To: <f9ec091e-1b35-f8eb-7dbf-f4de1b1120ed@oracle.com>
References: <f9ec091e-1b35-f8eb-7dbf-f4de1b1120ed@oracle.com>
Message-ID: <0154d7ef-38e9-0913-440c-9fe7c06f7432@oracle.com>

Looks ok to me, or bugs.o.j.n which might be more permanent.

Brad


On 8/25/2016 12:55 PM, Sean Mullan wrote:
> Real trivial fix, just updating obsolete bug URLs in code comments.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8150158
>
> $ hg diff --nodates -a -U 1
> diff -r 9c7eb3e1799f
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
>
> ---
> a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
>
> +++
> b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java
>
> @@ -152,3 +152,3 @@
>              // reinstantiate Mac object to work around bug in JDK
> -            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
> +            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
>              Mac mac = this.macAlgorithm;
> diff -r 9c7eb3e1799f
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
>
> ---
> a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
>
> +++
> b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java
>
> @@ -114,3 +114,3 @@
>              // reinstantiate Signature object to work around bug in JDK
> -            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
> +            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
>              Signature sig = this.signatureAlgorithm;
> diff -r 9c7eb3e1799f
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
>
> ---
> a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
>
> +++
> b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java
>
> @@ -141,3 +141,3 @@
>              // reinstantiate Signature object to work around bug in JDK
> -            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
> +            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
>              Signature sig = this.signatureAlgorithm;
> diff -r 9c7eb3e1799f
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
>
> ---
> a/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
>
> +++
> b/src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java
>
> @@ -254,3 +254,3 @@
>              // reinstantiate Signature object to work around bug in JDK
> -            // see: http://bugs.sun.com/view_bug.do?bug_id=4953555
> +            // see: http://bugs.java.com/view_bug.do?bug_id=4953555
>              Signature sig = this.signatureAlgorithm;
>
> --Sean


From bradford.wetmore at oracle.com  Fri Aug 26 19:50:41 2016
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 26 Aug 2016 12:50:41 -0700
Subject: RFR: 8061842: Package jurisdiction policy files as something
	other than JAR
In-Reply-To: <f369e2d0-a61c-e97b-2da2-f84d3205410d@oracle.com>
References: <65380927-0e9e-c887-8537-b375733e5c0f@oracle.com>
	<53680482-2bbf-710f-071d-4277c2d985d7@oracle.com>
	<2d5572f1-5dc8-726a-9f44-2eed573f6157@oracle.com>
	<151C5E71-0DC6-4A93-8C2D-36EA599360A5@oracle.com>
	<d3832c25-5458-6b70-616c-1babf7289697@oracle.com>
	<8bcfa44a-ecb4-ad02-0611-069cb98d1dcc@oracle.com>
	<76bc1268-f9b9-c934-4c81-0cb750e2b91d@oracle.com>
	<f369e2d0-a61c-e97b-2da2-f84d3205410d@oracle.com>
Message-ID: <4aa6a93e-e3e4-f6c3-7de2-924eec053ad0@oracle.com>

http://cr.openjdk.java.net/~wetmore/8061842/webrev.04/

On 8/25/2016 8:05 PM, Weijun Wang wrote:
> Can you add a new @run line which is the getNameCount()==1 but
> getParent() != policyPath case?
>
> + * @run main/othervm TestUnlimited /unlimited exception

I think I finally developed a stable cross-platform case for this case. 
I've added this case and "unlimited/", which is an acceptable value.

On 8/26/2016 8:57 AM, Sean Mullan wrote:
 > On 08/24/2016 08:21 PM, Bradford Wetmore wrote:
 >> Sean Mullan wrote:
 >>
 >>  > What about setting the default value to "limited"? And then this
 >>  > would only be changed to "unlimited" if the build --enable-unlimited-
 >>  > crypto option is specified?
 >>
 >> I could, but I'm concerned that a build with --enabled-unlimited-crypto
 >> would expect that the compiled-in version default would also be
 >> unlimited and would be surprised with limited.
 >>
 >> Upon Max's suggestion above, I've changed the name of the marker to
 >> "crypto.policy=crypto.policydir-tbd."  Does that work for you?
 >
 > Not really.
 >
 > Why not just leave the property unset (or commented out)? That seems
 > more intuitive to me. What if the placeholder value accidentally never
 > gets replaced?

If the value is unset, commented out, or set to a directory value that 
doesn't exist (e.g. crypto.policydir-tbd), JCE will throw a 
ExceptionInInitializerError on first usage.  If the rewriting script 
somehow doesn't get called as part of the build, then 
security.provider.tbd will likely also cause problems.

I may just not be understanding your concern.

 > Anyway, if time is of the essence, go with what you have. This is not a
 > significant issue.

2pm...(possible fallback to Monday if there aren't any PIT failures)

Brad



From artem.smotrakov at oracle.com  Fri Aug 26 20:48:49 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Fri, 26 Aug 2016 13:48:49 -0700
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
In-Reply-To: <57C08329.10401@oracle.com>
References: <57C08329.10401@oracle.com>
Message-ID: <f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>

Hi Svetlana,

DerValue class may be implicitly used in different areas (x509, SSL/TLS, 
keystores, maybe krb5, etc). Please make sure that tests from 
jdk_security pass.

I'll leave the main review to someone who is more knowledgeable in this 
area, here are a couple of comments:
- Please update copyright year
- You may want to replace new byte[] + System.arraycopy() by 
Arrays.copyOfRange()
- It may be better to add a separate test case in ReadP12Test.java for 
SequenceInputStream instead of loading a keystore twice in each call to 
readTest(). One test with SequenceInputStream seems to be enough, and it 
would make the logic of readTest() clearer.

Artem

On 08/26/2016 10:58 AM, Svetlana Nikandrova wrote:
> Hello,
>
> please review this fix. It's not possible to read PKCS12 keystore with 
> big undefined length DER value in it from SequenceInputStream.  Root 
> cause of the problem is that sun.security.util.DerValue relays on 
> InputStream.available() to get a complete 'indefinite.length' section 
> length and then read it, but for SequenceInputStream this method 
> returns number of available bytes only for current input stream, not 
> the whole sequence. Fixed to read all available data.
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK-8157404
> Webrev:
> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/ 
> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
>
> Thanks,
> Svetlana
>

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

From weijun.wang at oracle.com  Mon Aug 29 01:05:42 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 29 Aug 2016 09:05:42 +0800
Subject: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java
	fails with Timeout error
In-Reply-To: <b2220649-b129-4ec0-96fa-61579a16d8ca@default>
References: <c0578e90-ca11-4234-ba72-a2b1818a34e6@default>
	<b2220649-b129-4ec0-96fa-61579a16d8ca@default>
Message-ID: <d32b404f-f15c-42bc-1ecb-e2f952ac9f8a@oracle.com>

Several comments:

1. findPortUnreachableExc() can be put outside of the Future and called 
directly.

2. When a TimeoutException is caught from future.get(), I think this 
should be treated as a failure. We have already used 
findPortUnreachableExc() to confirm PUE is available on this system and 
that port is not used by another process. If we still see timeout, it 
should be investigated. In fact, if the test succeeds in this case, it 
will never fail. Right?

3. Why not write 2 catch blocks here for each exception type?

  120         } catch (SocketTimeoutException | PortUnreachableException 
e) {
  121             if (e instanceof PortUnreachableException) {
  122                 return true;
  123             }
  124         }

Thanks
Max

On 8/26/2016 18:39, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Here is the latest webrev:
> http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
>
>
>
> I have updated the test with these additional support,
>
> 1)      Verifying, if the port is reachable or PortUnreachableException
> is supported by the platform, otherwise the Test will terminate itself
> with warning.
>
> 2)      Removed the test from ProblemList.txt for MAC OS because of #1.
>
> 3)      Uses only one KDC port in the configuration file.
>
> 4)      Removed static ?unreachable.krb5.conf? as the Test creates the
> file during runtime.
>
>
>
> Thanks,
>
> Siba
>
>
>
> *From:*Sibabrata Sahoo
> *Sent:* Wednesday, August 24, 2016 9:46 PM
> *To:* Weijun Wang; security-dev at openjdk.java.net
> *Subject:* [9] RFR: 8015595: Test
> sun/security/krb5/auto/Unreachable.java fails with Timeout error
>
>
>
> Hi,
>
>
>
> Please review the patch for ?sun/security/krb5/auto/Unreachable.java
> fails with Timeout error?
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8015595
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
>
>
>
> Description:
>
> When a KDC port is unreachable, Kerberos login module depends on
> PortUnreachableException to exit immediately. But as per JavaDoc for
> receive() in ?java.net.DatagramSocket?, the PortUnreachableException is
> not guaranteed. In such case the Login module waits for 90 second by
> default. But the JTREG Test timeout has been set for 10 second and
> because of that the Test gets timeout.
>
>
>
> Since the ?intermittent? failure is unavoidable due to
>  ?PortUnreachableException is not guaranteed?, I have provided a fix to
> print a warning message for such cases instead of making the Test timeout.
>
>
>
> Thanks,
>
> Siba
>
>
>


From Alan.Bateman at oracle.com  Mon Aug 29 12:18:39 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Aug 2016 13:18:39 +0100
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
Message-ID: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>

On 25/08/2016 04:55, Weijun Wang wrote:

> Hi All
>
> Please take a look at
>
>    http://cr.openjdk.java.net/~weijun/8164705/webrev.00
>
> From the beginning of JDK, FilePermission canonicalizes the input path 
> and use the result in implies() and equals(). This has been a big 
> performance hurt and leads to confusing results when symlinks are 
> involved.
>
> The code change above removes the canonicalization.
>
> This means FilePermission on "/the/current/working/directory/x" no 
> longer implies that on "x". Since this might bring quite some 
> compatibility risk, the code change includes some tweaks in permission 
> checking to make sure an app is still able to read "x" when the 
> FilePermission granted is on "/the/current/working/directory/x". 
> However, we still hope the policy to be updated to be consistent of 
> how a file is actually accessed.
>
> No tweak is devoted to make granting "/this/is/a/symlink" to imply 
> reading of "/the/actual/target/file", because we think it should not.
>
> This is quite a big behavior change. If it breaks your app/lib, or 
> does not work with your customized security manager or policy 
> implementation, please let us know.
>
> Feel free to provide any feedback.
>
> Finally, a new system property "jdk.filepermission.canonicalize" is 
> introduced and it can be "true", "false", or "compat". The out-of-box 
> default is "compat", which means no canonicalization with check tweaks.
I've taken a first pass over this. A general comment then it's great to 
see FilePermission changed to not do canonicalization. The "new 
behavior" approach to match paths and support absolute => relative and 
relative => absolute all makes sense.

I agree that having a property to revert to legacy behavior make sense. 
Is there any way to reduce this down to just current and legacy 
behavior, it's otherwise too complicated to describe the subtle 
differences between "false" and "compat". If it can be reduced to two 
settings then a name such as 
jdk.io.permissionsUseCanonicalPath=<boolean> could be better than the 
prototype name.

For the implementation then I think it will cleanup before this is ready 
to push. FilePermCompat is a ugly, particularly FilePermission changing 
its public fields. Also method names like impliesWithAltFP, 
newPermPlusAltPath, ... could be re-visited to make them much clearer.

For the test then it would be good if samepath.sh could be replaced with 
a non-shell test.

-Alan


From sibabrata.sahoo at oracle.com  Mon Aug 29 12:32:10 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Mon, 29 Aug 2016 05:32:10 -0700 (PDT)
Subject: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java
	fails with Timeout error
In-Reply-To: <d32b404f-f15c-42bc-1ecb-e2f952ac9f8a@oracle.com>
References: <c0578e90-ca11-4234-ba72-a2b1818a34e6@default>
	<b2220649-b129-4ec0-96fa-61579a16d8ca@default>
	<d32b404f-f15c-42bc-1ecb-e2f952ac9f8a@oracle.com>
Message-ID: <98ca24bf-3aed-416e-a311-3d5172cf4247@default>

Hi Max,

Please find the updated webrev addressing all comments bellow: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.01/

Thanks,
Siba

-----Original Message-----
From: Weijun Wang 
Sent: Monday, August 29, 2016 6:36 AM
To: Sibabrata Sahoo; security-dev at openjdk.java.net
Subject: Re: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java fails with Timeout error

Several comments:

1. findPortUnreachableExc() can be put outside of the Future and called directly.

2. When a TimeoutException is caught from future.get(), I think this should be treated as a failure. We have already used
findPortUnreachableExc() to confirm PUE is available on this system and that port is not used by another process. If we still see timeout, it should be investigated. In fact, if the test succeeds in this case, it will never fail. Right?

3. Why not write 2 catch blocks here for each exception type?

  120         } catch (SocketTimeoutException | PortUnreachableException 
e) {
  121             if (e instanceof PortUnreachableException) {
  122                 return true;
  123             }
  124         }

Thanks
Max

On 8/26/2016 18:39, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Here is the latest webrev:
> http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
>
>
>
> I have updated the test with these additional support,
>
> 1)      Verifying, if the port is reachable or PortUnreachableException
> is supported by the platform, otherwise the Test will terminate itself 
> with warning.
>
> 2)      Removed the test from ProblemList.txt for MAC OS because of #1.
>
> 3)      Uses only one KDC port in the configuration file.
>
> 4)      Removed static "unreachable.krb5.conf" as the Test creates the
> file during runtime.
>
>
>
> Thanks,
>
> Siba
>
>
>
> *From:*Sibabrata Sahoo
> *Sent:* Wednesday, August 24, 2016 9:46 PM
> *To:* Weijun Wang; security-dev at openjdk.java.net
> *Subject:* [9] RFR: 8015595: Test
> sun/security/krb5/auto/Unreachable.java fails with Timeout error
>
>
>
> Hi,
>
>
>
> Please review the patch for "sun/security/krb5/auto/Unreachable.java
> fails with Timeout error"
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8015595
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
>
>
>
> Description:
>
> When a KDC port is unreachable, Kerberos login module depends on 
> PortUnreachableException to exit immediately. But as per JavaDoc for
> receive() in "java.net.DatagramSocket", the PortUnreachableException 
> is not guaranteed. In such case the Login module waits for 90 second 
> by default. But the JTREG Test timeout has been set for 10 second and 
> because of that the Test gets timeout.
>
>
>
> Since the "intermittent" failure is unavoidable due to  
> "PortUnreachableException is not guaranteed", I have provided a fix to 
> print a warning message for such cases instead of making the Test timeout.
>
>
>
> Thanks,
>
> Siba
>
>
>


From weijun.wang at oracle.com  Mon Aug 29 12:44:26 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 29 Aug 2016 20:44:26 +0800
Subject: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java
	fails with Timeout error
In-Reply-To: <98ca24bf-3aed-416e-a311-3d5172cf4247@default>
References: <c0578e90-ca11-4234-ba72-a2b1818a34e6@default>
	<b2220649-b129-4ec0-96fa-61579a16d8ca@default>
	<d32b404f-f15c-42bc-1ecb-e2f952ac9f8a@oracle.com>
	<98ca24bf-3aed-416e-a311-3d5172cf4247@default>
Message-ID: <9d8310b7-fedc-29a6-e3a2-1ea216c5852a@oracle.com>

Looks fine mostly. Some nits:

   58         // - SocketTimeoutException may occur in MAC because it 
will not throw

s/in MAC/on Mac/.

   66                     + "occured or PortUnreachableException not 
thrown by the "

s/or/which means/.

   76                 File f = new File("unreachable.krb5.conf");
   77                 System.setProperty("java.security.krb5.conf", 
f.getPath());

How is this better than just set the property value to 
"unreachable.krb5.conf"?

Thanks
Max

On 8/29/2016 20:32, Sibabrata Sahoo wrote:
> Hi Max,
>
> Please find the updated webrev addressing all comments bellow: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.01/
>
> Thanks,
> Siba
>
> -----Original Message-----
> From: Weijun Wang
> Sent: Monday, August 29, 2016 6:36 AM
> To: Sibabrata Sahoo; security-dev at openjdk.java.net
> Subject: Re: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java fails with Timeout error
>
> Several comments:
>
> 1. findPortUnreachableExc() can be put outside of the Future and called directly.
>
> 2. When a TimeoutException is caught from future.get(), I think this should be treated as a failure. We have already used
> findPortUnreachableExc() to confirm PUE is available on this system and that port is not used by another process. If we still see timeout, it should be investigated. In fact, if the test succeeds in this case, it will never fail. Right?
>
> 3. Why not write 2 catch blocks here for each exception type?
>
>   120         } catch (SocketTimeoutException | PortUnreachableException
> e) {
>   121             if (e instanceof PortUnreachableException) {
>   122                 return true;
>   123             }
>   124         }
>
> Thanks
> Max
>
> On 8/26/2016 18:39, Sibabrata Sahoo wrote:
>> Hi,
>>
>>
>>
>> Here is the latest webrev:
>> http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
>>
>>
>>
>> I have updated the test with these additional support,
>>
>> 1)      Verifying, if the port is reachable or PortUnreachableException
>> is supported by the platform, otherwise the Test will terminate itself
>> with warning.
>>
>> 2)      Removed the test from ProblemList.txt for MAC OS because of #1.
>>
>> 3)      Uses only one KDC port in the configuration file.
>>
>> 4)      Removed static "unreachable.krb5.conf" as the Test creates the
>> file during runtime.
>>
>>
>>
>> Thanks,
>>
>> Siba
>>
>>
>>
>> *From:*Sibabrata Sahoo
>> *Sent:* Wednesday, August 24, 2016 9:46 PM
>> *To:* Weijun Wang; security-dev at openjdk.java.net
>> *Subject:* [9] RFR: 8015595: Test
>> sun/security/krb5/auto/Unreachable.java fails with Timeout error
>>
>>
>>
>> Hi,
>>
>>
>>
>> Please review the patch for "sun/security/krb5/auto/Unreachable.java
>> fails with Timeout error"
>>
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8015595
>>
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
>>
>>
>>
>> Description:
>>
>> When a KDC port is unreachable, Kerberos login module depends on
>> PortUnreachableException to exit immediately. But as per JavaDoc for
>> receive() in "java.net.DatagramSocket", the PortUnreachableException
>> is not guaranteed. In such case the Login module waits for 90 second
>> by default. But the JTREG Test timeout has been set for 10 second and
>> because of that the Test gets timeout.
>>
>>
>>
>> Since the "intermittent" failure is unavoidable due to
>> "PortUnreachableException is not guaranteed", I have provided a fix to
>> print a warning message for such cases instead of making the Test timeout.
>>
>>
>>
>> Thanks,
>>
>> Siba
>>
>>
>>


From weijun.wang at oracle.com  Mon Aug 29 13:13:58 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 29 Aug 2016 21:13:58 +0800
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
Message-ID: <43be470d-930e-e3f2-5ed4-ede6ff6f2398@oracle.com>

Hi Alan

I am glad you think this change is useful.

As for the 3-value property, in my opinion even the absolute <=> 
relative translation might not be really useful in a production 
environment. Who can guarantee a program is always launched from a 
certain directory and access a file using a relative path? I secretly 
wish this never happens and a brave user would set the property to false 
so that there is no need for any compatibility code.

And yes, samepath.sh was from a very early stage of this change and I 
should rewrite it.

Thanks
Max

On 8/29/2016 20:18, Alan Bateman wrote:
> On 25/08/2016 04:55, Weijun Wang wrote:
>
>> Hi All
>>
>> Please take a look at
>>
>>    http://cr.openjdk.java.net/~weijun/8164705/webrev.00
>>
>> From the beginning of JDK, FilePermission canonicalizes the input path
>> and use the result in implies() and equals(). This has been a big
>> performance hurt and leads to confusing results when symlinks are
>> involved.
>>
>> The code change above removes the canonicalization.
>>
>> This means FilePermission on "/the/current/working/directory/x" no
>> longer implies that on "x". Since this might bring quite some
>> compatibility risk, the code change includes some tweaks in permission
>> checking to make sure an app is still able to read "x" when the
>> FilePermission granted is on "/the/current/working/directory/x".
>> However, we still hope the policy to be updated to be consistent of
>> how a file is actually accessed.
>>
>> No tweak is devoted to make granting "/this/is/a/symlink" to imply
>> reading of "/the/actual/target/file", because we think it should not.
>>
>> This is quite a big behavior change. If it breaks your app/lib, or
>> does not work with your customized security manager or policy
>> implementation, please let us know.
>>
>> Feel free to provide any feedback.
>>
>> Finally, a new system property "jdk.filepermission.canonicalize" is
>> introduced and it can be "true", "false", or "compat". The out-of-box
>> default is "compat", which means no canonicalization with check tweaks.
> I've taken a first pass over this. A general comment then it's great to
> see FilePermission changed to not do canonicalization. The "new
> behavior" approach to match paths and support absolute => relative and
> relative => absolute all makes sense.
>
> I agree that having a property to revert to legacy behavior make sense.
> Is there any way to reduce this down to just current and legacy
> behavior, it's otherwise too complicated to describe the subtle
> differences between "false" and "compat". If it can be reduced to two
> settings then a name such as
> jdk.io.permissionsUseCanonicalPath=<boolean> could be better than the
> prototype name.
>
> For the implementation then I think it will cleanup before this is ready
> to push. FilePermCompat is a ugly, particularly FilePermission changing
> its public fields. Also method names like impliesWithAltFP,
> newPermPlusAltPath, ... could be re-visited to make them much clearer.
>
> For the test then it would be good if samepath.sh could be replaced with
> a non-shell test.
>
> -Alan


From sibabrata.sahoo at oracle.com  Mon Aug 29 13:36:06 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Mon, 29 Aug 2016 06:36:06 -0700 (PDT)
Subject: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java
	fails with Timeout error
In-Reply-To: <9d8310b7-fedc-29a6-e3a2-1ea216c5852a@oracle.com>
References: <c0578e90-ca11-4234-ba72-a2b1818a34e6@default>
	<b2220649-b129-4ec0-96fa-61579a16d8ca@default>
	<d32b404f-f15c-42bc-1ecb-e2f952ac9f8a@oracle.com>
	<98ca24bf-3aed-416e-a311-3d5172cf4247@default>
	<9d8310b7-fedc-29a6-e3a2-1ea216c5852a@oracle.com>
Message-ID: <f5ccf1a4-4412-402b-97e8-f0886e230320@default>

Hi Max,

Here is updated webrev: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.02/

Addressed all the following comments.

Thanks,
Siba

-----Original Message-----
From: Weijun Wang 
Sent: Monday, August 29, 2016 6:14 PM
To: Sibabrata Sahoo; security-dev at openjdk.java.net
Subject: Re: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java fails with Timeout error

Looks fine mostly. Some nits:

   58         // - SocketTimeoutException may occur in MAC because it 
will not throw

s/in MAC/on Mac/.

   66                     + "occured or PortUnreachableException not 
thrown by the "

s/or/which means/.

   76                 File f = new File("unreachable.krb5.conf");
   77                 System.setProperty("java.security.krb5.conf", 
f.getPath());

How is this better than just set the property value to "unreachable.krb5.conf"?

Thanks
Max

On 8/29/2016 20:32, Sibabrata Sahoo wrote:
> Hi Max,
>
> Please find the updated webrev addressing all comments bellow: 
> http://cr.openjdk.java.net/~ssahoo/8015595/webrev.01/
>
> Thanks,
> Siba
>
> -----Original Message-----
> From: Weijun Wang
> Sent: Monday, August 29, 2016 6:36 AM
> To: Sibabrata Sahoo; security-dev at openjdk.java.net
> Subject: Re: [9] RFR: 8015595: Test 
> sun/security/krb5/auto/Unreachable.java fails with Timeout error
>
> Several comments:
>
> 1. findPortUnreachableExc() can be put outside of the Future and called directly.
>
> 2. When a TimeoutException is caught from future.get(), I think this 
> should be treated as a failure. We have already used
> findPortUnreachableExc() to confirm PUE is available on this system and that port is not used by another process. If we still see timeout, it should be investigated. In fact, if the test succeeds in this case, it will never fail. Right?
>
> 3. Why not write 2 catch blocks here for each exception type?
>
>   120         } catch (SocketTimeoutException | PortUnreachableException
> e) {
>   121             if (e instanceof PortUnreachableException) {
>   122                 return true;
>   123             }
>   124         }
>
> Thanks
> Max
>
> On 8/26/2016 18:39, Sibabrata Sahoo wrote:
>> Hi,
>>
>>
>>
>> Here is the latest webrev:
>> http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
>>
>>
>>
>> I have updated the test with these additional support,
>>
>> 1)      Verifying, if the port is reachable or PortUnreachableException
>> is supported by the platform, otherwise the Test will terminate 
>> itself with warning.
>>
>> 2)      Removed the test from ProblemList.txt for MAC OS because of #1.
>>
>> 3)      Uses only one KDC port in the configuration file.
>>
>> 4)      Removed static "unreachable.krb5.conf" as the Test creates the
>> file during runtime.
>>
>>
>>
>> Thanks,
>>
>> Siba
>>
>>
>>
>> *From:*Sibabrata Sahoo
>> *Sent:* Wednesday, August 24, 2016 9:46 PM
>> *To:* Weijun Wang; security-dev at openjdk.java.net
>> *Subject:* [9] RFR: 8015595: Test
>> sun/security/krb5/auto/Unreachable.java fails with Timeout error
>>
>>
>>
>> Hi,
>>
>>
>>
>> Please review the patch for "sun/security/krb5/auto/Unreachable.java
>> fails with Timeout error"
>>
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8015595
>>
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.00/
>>
>>
>>
>> Description:
>>
>> When a KDC port is unreachable, Kerberos login module depends on 
>> PortUnreachableException to exit immediately. But as per JavaDoc for
>> receive() in "java.net.DatagramSocket", the PortUnreachableException 
>> is not guaranteed. In such case the Login module waits for 90 second 
>> by default. But the JTREG Test timeout has been set for 10 second and 
>> because of that the Test gets timeout.
>>
>>
>>
>> Since the "intermittent" failure is unavoidable due to 
>> "PortUnreachableException is not guaranteed", I have provided a fix 
>> to print a warning message for such cases instead of making the Test timeout.
>>
>>
>>
>> Thanks,
>>
>> Siba
>>
>>
>>


From weijun.wang at oracle.com  Mon Aug 29 14:00:27 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 29 Aug 2016 22:00:27 +0800
Subject: [9] RFR: 8015595: Test sun/security/krb5/auto/Unreachable.java
	fails with Timeout error
In-Reply-To: <f5ccf1a4-4412-402b-97e8-f0886e230320@default>
References: <c0578e90-ca11-4234-ba72-a2b1818a34e6@default>
	<b2220649-b129-4ec0-96fa-61579a16d8ca@default>
	<d32b404f-f15c-42bc-1ecb-e2f952ac9f8a@oracle.com>
	<98ca24bf-3aed-416e-a311-3d5172cf4247@default>
	<9d8310b7-fedc-29a6-e3a2-1ea216c5852a@oracle.com>
	<f5ccf1a4-4412-402b-97e8-f0886e230320@default>
Message-ID: <ae9430a4-cb3a-b9b7-f37f-37fcd79fdfb9@oracle.com>

Change looks fine.

Thanks
Max

On 8/29/2016 21:36, Sibabrata Sahoo wrote:
> Hi Max,
>
> Here is updated webrev: http://cr.openjdk.java.net/~ssahoo/8015595/webrev.02/
>
> Addressed all the following comments.
>
> Thanks,
> Siba
>


From sibabrata.sahoo at oracle.com  Mon Aug 29 15:20:35 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Mon, 29 Aug 2016 08:20:35 -0700 (PDT)
Subject: [9] RFR: 8164922: sun/security/provider/SecureRandom/AutoReseed.java
	failed with timeout in Ubuntu Linux.
Message-ID: <db5dbb20-e02b-45f4-82ac-e3e349baaf04@default>

Hi,

 

Please review the patch for "sun/security/provider/SecureRandom/AutoReseed.java failed with timeout"

 

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

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

 

Description:

The Test was blocked while generating seed. I have providing a fix by choosing a non-blocking mechanism while seeding by setting "java.security.egd" System property to "file:/dev/urandom".

 

Thanks,

Siba

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

From svetlana.nikandrova at oracle.com  Mon Aug 29 18:23:55 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Mon, 29 Aug 2016 21:23:55 +0300
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
In-Reply-To: <f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>
References: <57C08329.10401@oracle.com>
	<f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>
Message-ID: <57C47DBB.2040505@oracle.com>

Hi Artem,

thank you for your replay. I've updated copyright and made separate test 
for this bug.
As for Arrays.copyOfRange() unfortunately it won't simplify code in my 
case. I need to extend an array, not to get a sub-array of existing one.

http://cr.openjdk.java.net/~snikandrova/8157404/webrev.01/ 
<http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.01/>

Thanks,
Svetlana

On 26.08.2016 23:48, Artem Smotrakov wrote:
>
> Hi Svetlana,
>
> DerValue class may be implicitly used in different areas (x509, 
> SSL/TLS, keystores, maybe krb5, etc). Please make sure that tests from 
> jdk_security pass.
>
> I'll leave the main review to someone who is more knowledgeable in 
> this area, here are a couple of comments:
> - Please update copyright year
> - You may want to replace new byte[] + System.arraycopy() by 
> Arrays.copyOfRange()
> - It may be better to add a separate test case in ReadP12Test.java for 
> SequenceInputStream instead of loading a keystore twice in each call 
> to readTest(). One test with SequenceInputStream seems to be enough, 
> and it would make the logic of readTest() clearer.
>
> Artem
>
> On 08/26/2016 10:58 AM, Svetlana Nikandrova wrote:
>> Hello,
>>
>> please review this fix. It's not possible to read PKCS12 keystore 
>> with big undefined length DER value in it from SequenceInputStream.  
>> Root cause of the problem is that sun.security.util.DerValue relays 
>> on InputStream.available() to get a complete 'indefinite.length' 
>> section length and then read it, but for SequenceInputStream this 
>> method returns number of available bytes only for current input 
>> stream, not the whole sequence. Fixed to read all available data.
>>
>> JBS:
>> https://bugs.openjdk.java.net/browse/JDK-8157404
>> Webrev:
>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
>>
>> Thanks,
>> Svetlana
>>
>

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

From artem.smotrakov at oracle.com  Mon Aug 29 18:52:48 2016
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Mon, 29 Aug 2016 11:52:48 -0700
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
In-Reply-To: <57C47DBB.2040505@oracle.com>
References: <57C08329.10401@oracle.com>
	<f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>
	<57C47DBB.2040505@oracle.com>
Message-ID: <4dc4fe5d-b03b-413c-8dfa-c28ce4720bb7@oracle.com>

Hi Svetlana,

It looks fine, but I am not an official reviewer.

"keystorePath" in readTest() can be a static field.

I also meant that one test with SequenceInputStream seems to be enough, 
so you could just add a new test case to ReadP12Test.java. But it's fine.

I am not sure how DerIndefLenConverter works, but it looks a little 
strange to me that it needs to extend an array before passing it to 
DerIndefLenConverter. I see that convert() method also uses arraycopy() 
method. But it seems to be out of scope here.

Artem


On 08/29/2016 11:23 AM, Svetlana Nikandrova wrote:
> Hi Artem,
>
> thank you for your replay. I've updated copyright and made separate 
> test for this bug.
> As for Arrays.copyOfRange() unfortunately it won't simplify code in my 
> case. I need to extend an array, not to get a sub-array of existing one.
>
> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.01/ 
> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.01/>
>
> Thanks,
> Svetlana
>
> On 26.08.2016 23:48, Artem Smotrakov wrote:
>>
>> Hi Svetlana,
>>
>> DerValue class may be implicitly used in different areas (x509, 
>> SSL/TLS, keystores, maybe krb5, etc). Please make sure that tests 
>> from jdk_security pass.
>>
>> I'll leave the main review to someone who is more knowledgeable in 
>> this area, here are a couple of comments:
>> - Please update copyright year
>> - You may want to replace new byte[] + System.arraycopy() by 
>> Arrays.copyOfRange()
>> - It may be better to add a separate test case in ReadP12Test.java 
>> for SequenceInputStream instead of loading a keystore twice in each 
>> call to readTest(). One test with SequenceInputStream seems to be 
>> enough, and it would make the logic of readTest() clearer.
>>
>> Artem
>>
>> On 08/26/2016 10:58 AM, Svetlana Nikandrova wrote:
>>> Hello,
>>>
>>> please review this fix. It's not possible to read PKCS12 keystore 
>>> with big undefined length DER value in it from SequenceInputStream.  
>>> Root cause of the problem is that sun.security.util.DerValue relays 
>>> on InputStream.available() to get a complete 'indefinite.length' 
>>> section length and then read it, but for SequenceInputStream this 
>>> method returns number of available bytes only for current input 
>>> stream, not the whole sequence. Fixed to read all available data.
>>>
>>> JBS:
>>> https://bugs.openjdk.java.net/browse/JDK-8157404
>>> Webrev:
>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
>>>
>>> Thanks,
>>> Svetlana
>>>
>>
>

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

From valerie.peng at oracle.com  Mon Aug 29 23:18:57 2016
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 29 Aug 2016 16:18:57 -0700
Subject: [jdk9] (XS) RFR: 6474807: (smartcardio) CardTerminal.connect()
	throws CardException instead of CardNotPresentException
In-Reply-To: <d4cf87df-a560-7806-d373-71deb150e540@oracle.com>
References: <d4cf87df-a560-7806-d373-71deb150e540@oracle.com>
Message-ID: <5d35a0e1-7a85-c5a0-f1c4-8d027eed1c4e@oracle.com>


Changes look fine.
Thanks,
Valerie

On 8/23/2016 10:20 AM, Ivan Gerasimov wrote:
> Hello!
>
> When underlying PCSC driver returns the error SCARD_E_NO_SMARTCARD, we 
> should throw a more specialized exception of type 
> CardNotPresentException.
>
> Currently, the plain CardException is thrown, which makes some TCK 
> tests unhappy.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-6474807
> WEBREV: http://cr.openjdk.java.net/~igerasim/6474807/00/webrev/
>
> Would you please help review a simple fix?
>
> With kind regards,
> Ivan
>



From weijun.wang at oracle.com  Tue Aug 30 02:43:33 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 30 Aug 2016 10:43:33 +0800
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
In-Reply-To: <4dc4fe5d-b03b-413c-8dfa-c28ce4720bb7@oracle.com>
References: <57C08329.10401@oracle.com>
	<f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>
	<57C47DBB.2040505@oracle.com>
	<4dc4fe5d-b03b-413c-8dfa-c28ce4720bb7@oracle.com>
Message-ID: <d911ed7f-e812-6586-4820-efd60092731a@oracle.com>

readAllBytes() wants to real *all* data. If this is during a long time 
communication, and the peer sends a BER using indefinite length, and 
then wait for the next round of dialog without closing the stream, will 
readAllBytes() hang?

Is it possible to create a new method readAllAvailables() here? It kept 
read data until available() is zero and return the concatenated byte 
array. I think this method does not block and is able to read everything 
available from a SequenceInputStream.

In fact, IMO the DerValue is not implemented correctly. It should have 
been able to read the input data chunk by chunk until a BER is fully 
consumed, leaving data after the BER untouched, and block if the BER is 
not complete. To achieve this, it should read the header, read zero or 
more sub-data, read the EOC, recursively if necessary.

Thanks
Max

On 8/30/2016 2:52, Artem Smotrakov wrote:
> Hi Svetlana,
>
> It looks fine, but I am not an official reviewer.
>
> "keystorePath" in readTest() can be a static field.
>
> I also meant that one test with SequenceInputStream seems to be enough,
> so you could just add a new test case to ReadP12Test.java. But it's fine.
>
> I am not sure how DerIndefLenConverter works, but it looks a little
> strange to me that it needs to extend an array before passing it to
> DerIndefLenConverter. I see that convert() method also uses arraycopy()
> method. But it seems to be out of scope here.
>
> Artem
>
>
> On 08/29/2016 11:23 AM, Svetlana Nikandrova wrote:
>> Hi Artem,
>>
>> thank you for your replay. I've updated copyright and made separate
>> test for this bug.
>> As for Arrays.copyOfRange() unfortunately it won't simplify code in my
>> case. I need to extend an array, not to get a sub-array of existing one.
>>
>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.01/
>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.01/>
>>
>> Thanks,
>> Svetlana
>>
>> On 26.08.2016 23:48, Artem Smotrakov wrote:
>>>
>>> Hi Svetlana,
>>>
>>> DerValue class may be implicitly used in different areas (x509,
>>> SSL/TLS, keystores, maybe krb5, etc). Please make sure that tests
>>> from jdk_security pass.
>>>
>>> I'll leave the main review to someone who is more knowledgeable in
>>> this area, here are a couple of comments:
>>> - Please update copyright year
>>> - You may want to replace new byte[] + System.arraycopy() by
>>> Arrays.copyOfRange()
>>> - It may be better to add a separate test case in ReadP12Test.java
>>> for SequenceInputStream instead of loading a keystore twice in each
>>> call to readTest(). One test with SequenceInputStream seems to be
>>> enough, and it would make the logic of readTest() clearer.
>>>
>>> Artem
>>>
>>> On 08/26/2016 10:58 AM, Svetlana Nikandrova wrote:
>>>> Hello,
>>>>
>>>> please review this fix. It's not possible to read PKCS12 keystore
>>>> with big undefined length DER value in it from SequenceInputStream.
>>>> Root cause of the problem is that sun.security.util.DerValue relays
>>>> on InputStream.available() to get a complete 'indefinite.length'
>>>> section length and then read it, but for SequenceInputStream this
>>>> method returns number of available bytes only for current input
>>>> stream, not the whole sequence. Fixed to read all available data.
>>>>
>>>> JBS:
>>>> https://bugs.openjdk.java.net/browse/JDK-8157404
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
>>>>
>>>> Thanks,
>>>> Svetlana
>>>>
>>>
>>
>


From weijun.wang at oracle.com  Tue Aug 30 03:07:53 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 30 Aug 2016 11:07:53 +0800
Subject: RFR 8164705: Remove pathname canonicalization from FilePermission
In-Reply-To: <6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
References: <c7f467cf-eb51-1fc6-1a03-939f43d0b861@oracle.com>
	<6484addc-45a2-a164-46b9-38de8e85a8ff@oracle.com>
Message-ID: <6712f403-4418-dbae-1679-d43bf01d69f1@oracle.com>

On 8/29/2016 20:18, Alan Bateman wrote:
> FilePermCompat is a ugly, particularly FilePermission changing its
> public fields.

Do you prefer the traditional SharedSecrets way?

    SharedSecrets.setJavaIoFilePermissionAccess(
            new JavaIoFilePermissionAccessImpl());

> Also method names like impliesWithAltFP,
> newPermPlusAltPath, ... could be re-visited to make them much clearer.

Oh, I stuffed the verb and prepositional phrase into the method name to 
make it clearer. Or you don't like the abbreviations?

Thanks
Max


From weijun.wang at oracle.com  Tue Aug 30 08:10:23 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 30 Aug 2016 16:10:23 +0800
Subject: [9] RFR: 8164922:
	sun/security/provider/SecureRandom/AutoReseed.java failed with timeout
	in Ubuntu Linux.
In-Reply-To: <db5dbb20-e02b-45f4-82ac-e3e349baaf04@default>
References: <db5dbb20-e02b-45f4-82ac-e3e349baaf04@default>
Message-ID: <e31e51b1-26e9-beba-f17e-b3964d0b7c16@oracle.com>

Please just use othervm, and remove the finally block. If oldegd is null 
the code change will change the environment permanently.

--Max

On 8/29/2016 23:20, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for
> ?sun/security/provider/SecureRandom/AutoReseed.java failed with timeout?
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8164922
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8164922/webrev.00/
>
>
>
> Description:
>
> The Test was blocked while generating seed. I have providing a fix by
> choosing a non-blocking mechanism while seeding by setting
> "java.security.egd" System property to "file:/dev/urandom".
>
>
>
> Thanks,
>
> Siba
>
>
>


From sibabrata.sahoo at oracle.com  Tue Aug 30 10:45:59 2016
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 30 Aug 2016 03:45:59 -0700 (PDT)
Subject: [9] RFR: 8164922:
	sun/security/provider/SecureRandom/AutoReseed.java failed with timeout
	in Ubuntu Linux.
In-Reply-To: <e31e51b1-26e9-beba-f17e-b3964d0b7c16@oracle.com>
References: <db5dbb20-e02b-45f4-82ac-e3e349baaf04@default>
	<e31e51b1-26e9-beba-f17e-b3964d0b7c16@oracle.com>
Message-ID: <f70aad10-b1f4-4a4d-a2e9-8b091461754e@default>

Hi Max,

Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8164922/webrev.01/

I did a minor change other than addressing the following comment. I allowed all the test case to execute irrespective exception thrown.

Thanks,
Siba

-----Original Message-----
From: Weijun Wang 
Sent: Tuesday, August 30, 2016 1:40 PM
To: Sibabrata Sahoo; security-dev at openjdk.java.net
Subject: Re: [9] RFR: 8164922: sun/security/provider/SecureRandom/AutoReseed.java failed with timeout in Ubuntu Linux.

Please just use othervm, and remove the finally block. If oldegd is null the code change will change the environment permanently.

--Max

On 8/29/2016 23:20, Sibabrata Sahoo wrote:
> Hi,
>
>
>
> Please review the patch for
> "sun/security/provider/SecureRandom/AutoReseed.java failed with timeout"
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8164922
>
> Webrev: http://cr.openjdk.java.net/~ssahoo/8164922/webrev.00/
>
>
>
> Description:
>
> The Test was blocked while generating seed. I have providing a fix by 
> choosing a non-blocking mechanism while seeding by setting 
> "java.security.egd" System property to "file:/dev/urandom".
>
>
>
> Thanks,
>
> Siba
>
>
>


From weijun.wang at oracle.com  Tue Aug 30 14:33:57 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 30 Aug 2016 22:33:57 +0800
Subject: [9] RFR: 8164922:
	sun/security/provider/SecureRandom/AutoReseed.java failed with timeout
	in Ubuntu Linux.
In-Reply-To: <f70aad10-b1f4-4a4d-a2e9-8b091461754e@default>
References: <db5dbb20-e02b-45f4-82ac-e3e349baaf04@default>
	<e31e51b1-26e9-beba-f17e-b3964d0b7c16@oracle.com>
	<f70aad10-b1f4-4a4d-a2e9-8b091461754e@default>
Message-ID: <7dabe4c1-0b75-4a08-0d4d-0b829308986a@oracle.com>

Change looks fine.

Thanks
Max

On 8/30/2016 18:45, Sibabrata Sahoo wrote:
> Hi Max,
>
> Here is the updated webrev: http://cr.openjdk.java.net/~ssahoo/8164922/webrev.01/
>
> I did a minor change other than addressing the following comment. I allowed all the test case to execute irrespective exception thrown.
>
> Thanks,
> Siba
>
> -----Original Message-----
> From: Weijun Wang
> Sent: Tuesday, August 30, 2016 1:40 PM
> To: Sibabrata Sahoo; security-dev at openjdk.java.net
> Subject: Re: [9] RFR: 8164922: sun/security/provider/SecureRandom/AutoReseed.java failed with timeout in Ubuntu Linux.
>
> Please just use othervm, and remove the finally block. If oldegd is null the code change will change the environment permanently.
>
> --Max
>
> On 8/29/2016 23:20, Sibabrata Sahoo wrote:
>> Hi,
>>
>>
>>
>> Please review the patch for
>> "sun/security/provider/SecureRandom/AutoReseed.java failed with timeout"
>>
>>
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8164922
>>
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8164922/webrev.00/
>>
>>
>>
>> Description:
>>
>> The Test was blocked while generating seed. I have providing a fix by
>> choosing a non-blocking mechanism while seeding by setting
>> "java.security.egd" System property to "file:/dev/urandom".
>>
>>
>>
>> Thanks,
>>
>> Siba
>>
>>
>>


From svetlana.nikandrova at oracle.com  Tue Aug 30 16:46:19 2016
From: svetlana.nikandrova at oracle.com (Svetlana Nikandrova)
Date: Tue, 30 Aug 2016 19:46:19 +0300
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
In-Reply-To: <d911ed7f-e812-6586-4820-efd60092731a@oracle.com>
References: <57C08329.10401@oracle.com>
	<f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>
	<57C47DBB.2040505@oracle.com>
	<4dc4fe5d-b03b-413c-8dfa-c28ce4720bb7@oracle.com>
	<d911ed7f-e812-6586-4820-efd60092731a@oracle.com>
Message-ID: <57C5B85B.9060900@oracle.com>

Hi Max,

thank you for your replay. Please see inline.

On 30.08.2016 5:43, Weijun Wang wrote:
> readAllBytes() wants to real *all* data. If this is during a long time 
> communication, and the peer sends a BER using indefinite length, and 
> then wait for the next round of dialog without closing the stream, 
> will readAllBytes() hang?

readAllBytes() blocks until all remaining data has been read and end of 
stream is detected.
So if I understood your scenario correctly, yes, if EOF is not present 
it will hang. AFAIK when KeyStore.load completes successfully it 
consumes the input stream until EOF, so isn't it ok to expect it?

> Is it possible to create a new method readAllAvailables() here? It 
> kept read data until available() is zero and return the concatenated 
> byte array. I think this method does not block and is able to read 
> everything available from a SequenceInputStream.

Yes, I think it is possible to read data by portions, but unfortunately 
straight forward approach like "while(is.available() !=0)" won't work. 
As soon as we reach the end of the first stream in SequenceInputStream 
sequence is.available() will return 0 until we switch to the next stream 
by calling read(). I'm afraid it will look a little bit confusing.

> In fact, IMO the DerValue is not implemented correctly. It should have 
> been able to read the input data chunk by chunk until a BER is fully 
> consumed, leaving data after the BER untouched, and block if the BER 
> is not complete. To achieve this, it should read the header, read zero 
> or more sub-data, read the EOC, recursively if necessary.

It asks for some investigation. Should I create a separate issue?

Thank you,
Svetlana

>
> Thanks
> Max
>
> On 8/30/2016 2:52, Artem Smotrakov wrote:
>> Hi Svetlana,
>>
>> It looks fine, but I am not an official reviewer.
>>
>> "keystorePath" in readTest() can be a static field.
>>
>> I also meant that one test with SequenceInputStream seems to be enough,
>> so you could just add a new test case to ReadP12Test.java. But it's 
>> fine.
>>
>> I am not sure how DerIndefLenConverter works, but it looks a little
>> strange to me that it needs to extend an array before passing it to
>> DerIndefLenConverter. I see that convert() method also uses arraycopy()
>> method. But it seems to be out of scope here.
>>
>> Artem
>>
>>
>> On 08/29/2016 11:23 AM, Svetlana Nikandrova wrote:
>>> Hi Artem,
>>>
>>> thank you for your replay. I've updated copyright and made separate
>>> test for this bug.
>>> As for Arrays.copyOfRange() unfortunately it won't simplify code in my
>>> case. I need to extend an array, not to get a sub-array of existing 
>>> one.
>>>
>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.01/
>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.01/>
>>>
>>> Thanks,
>>> Svetlana
>>>
>>> On 26.08.2016 23:48, Artem Smotrakov wrote:
>>>>
>>>> Hi Svetlana,
>>>>
>>>> DerValue class may be implicitly used in different areas (x509,
>>>> SSL/TLS, keystores, maybe krb5, etc). Please make sure that tests
>>>> from jdk_security pass.
>>>>
>>>> I'll leave the main review to someone who is more knowledgeable in
>>>> this area, here are a couple of comments:
>>>> - Please update copyright year
>>>> - You may want to replace new byte[] + System.arraycopy() by
>>>> Arrays.copyOfRange()
>>>> - It may be better to add a separate test case in ReadP12Test.java
>>>> for SequenceInputStream instead of loading a keystore twice in each
>>>> call to readTest(). One test with SequenceInputStream seems to be
>>>> enough, and it would make the logic of readTest() clearer.
>>>>
>>>> Artem
>>>>
>>>> On 08/26/2016 10:58 AM, Svetlana Nikandrova wrote:
>>>>> Hello,
>>>>>
>>>>> please review this fix. It's not possible to read PKCS12 keystore
>>>>> with big undefined length DER value in it from SequenceInputStream.
>>>>> Root cause of the problem is that sun.security.util.DerValue relays
>>>>> on InputStream.available() to get a complete 'indefinite.length'
>>>>> section length and then read it, but for SequenceInputStream this
>>>>> method returns number of available bytes only for current input
>>>>> stream, not the whole sequence. Fixed to read all available data.
>>>>>
>>>>> JBS:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8157404
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/
>>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
>>>>>
>>>>> Thanks,
>>>>> Svetlana
>>>>>
>>>>
>>>
>>

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

From weijun.wang at oracle.com  Wed Aug 31 01:18:23 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 31 Aug 2016 09:18:23 +0800
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
In-Reply-To: <57C5B85B.9060900@oracle.com>
References: <57C08329.10401@oracle.com>
	<f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>
	<57C47DBB.2040505@oracle.com>
	<4dc4fe5d-b03b-413c-8dfa-c28ce4720bb7@oracle.com>
	<d911ed7f-e812-6586-4820-efd60092731a@oracle.com>
	<57C5B85B.9060900@oracle.com>
Message-ID: <fb8ffbad-c87d-9b48-b7f8-111615e98d16@oracle.com>



On 8/31/2016 0:46, Svetlana Nikandrova wrote:
> Hi Max,
>
> thank you for your replay. Please see inline.
>
> On 30.08.2016 5:43, Weijun Wang wrote:
>> readAllBytes() wants to real *all* data. If this is during a long time
>> communication, and the peer sends a BER using indefinite length, and
>> then wait for the next round of dialog without closing the stream,
>> will readAllBytes() hang?
>
> readAllBytes() blocks until all remaining data has been read and end of
> stream is detected.
> So if I understood your scenario correctly, yes, if EOF is not present
> it will hang. AFAIK when KeyStore.load completes successfully it
> consumes the input stream until EOF, so isn't it ok to expect it?

The KeyStore::load method makes no assumption on the InputStream 
parameter. More important, DerValue is used much wider than pkcs12 keystore.

>
>> Is it possible to create a new method readAllAvailables() here? It
>> kept read data until available() is zero and return the concatenated
>> byte array. I think this method does not block and is able to read
>> everything available from a SequenceInputStream.
>
> Yes, I think it is possible to read data by portions, but unfortunately
> straight forward approach like "while(is.available() !=0)" won't work.
> As soon as we reach the end of the first stream in SequenceInputStream
> sequence is.available() will return 0 until we switch to the next stream
> by calling read(). I'm afraid it will look a little bit confusing.

Well, this is unfortunate.

I also cannot think of a simple fix now. Maybe after see that "not all 
indef len BER resolved" error you can try read more.

>
>> In fact, IMO the DerValue is not implemented correctly. It should have
>> been able to read the input data chunk by chunk until a BER is fully
>> consumed, leaving data after the BER untouched, and block if the BER
>> is not complete. To achieve this, it should read the header, read zero
>> or more sub-data, read the EOC, recursively if necessary.
>
> It asks for some investigation. Should I create a separate issue?

You can, but please set the target version to major-tbd unless you want 
to work on it now.

Thanks
Max

>
> Thank you,
> Svetlana
>
>>
>> Thanks
>> Max
>>
>> On 8/30/2016 2:52, Artem Smotrakov wrote:
>>> Hi Svetlana,
>>>
>>> It looks fine, but I am not an official reviewer.
>>>
>>> "keystorePath" in readTest() can be a static field.
>>>
>>> I also meant that one test with SequenceInputStream seems to be enough,
>>> so you could just add a new test case to ReadP12Test.java. But it's
>>> fine.
>>>
>>> I am not sure how DerIndefLenConverter works, but it looks a little
>>> strange to me that it needs to extend an array before passing it to
>>> DerIndefLenConverter. I see that convert() method also uses arraycopy()
>>> method. But it seems to be out of scope here.
>>>
>>> Artem
>>>
>>>
>>> On 08/29/2016 11:23 AM, Svetlana Nikandrova wrote:
>>>> Hi Artem,
>>>>
>>>> thank you for your replay. I've updated copyright and made separate
>>>> test for this bug.
>>>> As for Arrays.copyOfRange() unfortunately it won't simplify code in my
>>>> case. I need to extend an array, not to get a sub-array of existing
>>>> one.
>>>>
>>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.01/
>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.01/>
>>>>
>>>> Thanks,
>>>> Svetlana
>>>>
>>>> On 26.08.2016 23:48, Artem Smotrakov wrote:
>>>>>
>>>>> Hi Svetlana,
>>>>>
>>>>> DerValue class may be implicitly used in different areas (x509,
>>>>> SSL/TLS, keystores, maybe krb5, etc). Please make sure that tests
>>>>> from jdk_security pass.
>>>>>
>>>>> I'll leave the main review to someone who is more knowledgeable in
>>>>> this area, here are a couple of comments:
>>>>> - Please update copyright year
>>>>> - You may want to replace new byte[] + System.arraycopy() by
>>>>> Arrays.copyOfRange()
>>>>> - It may be better to add a separate test case in ReadP12Test.java
>>>>> for SequenceInputStream instead of loading a keystore twice in each
>>>>> call to readTest(). One test with SequenceInputStream seems to be
>>>>> enough, and it would make the logic of readTest() clearer.
>>>>>
>>>>> Artem
>>>>>
>>>>> On 08/26/2016 10:58 AM, Svetlana Nikandrova wrote:
>>>>>> Hello,
>>>>>>
>>>>>> please review this fix. It's not possible to read PKCS12 keystore
>>>>>> with big undefined length DER value in it from SequenceInputStream.
>>>>>> Root cause of the problem is that sun.security.util.DerValue relays
>>>>>> on InputStream.available() to get a complete 'indefinite.length'
>>>>>> section length and then read it, but for SequenceInputStream this
>>>>>> method returns number of available bytes only for current input
>>>>>> stream, not the whole sequence. Fixed to read all available data.
>>>>>>
>>>>>> JBS:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157404
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
>>>>>>
>>>>>> Thanks,
>>>>>> Svetlana
>>>>>>
>>>>>
>>>>
>>>
>


From ecki at zusammenkunft.net  Wed Aug 31 01:44:30 2016
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 31 Aug 2016 03:44:30 +0200
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
In-Reply-To: <fb8ffbad-c87d-9b48-b7f8-111615e98d16@oracle.com>
References: <57C08329.10401@oracle.com>
	<f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>
	<57C47DBB.2040505@oracle.com>
	<4dc4fe5d-b03b-413c-8dfa-c28ce4720bb7@oracle.com>
	<d911ed7f-e812-6586-4820-efd60092731a@oracle.com>
	<57C5B85B.9060900@oracle.com>
	<fb8ffbad-c87d-9b48-b7f8-111615e98d16@oracle.com>
Message-ID: <20160831034430.0000407e.ecki@zusammenkunft.net>

Hello,

readBytes read all bytes of a specified length. If the length is not
known it is not usefull to use. Besides it is also not usefull to only
read available() bytes, as the nmber of bytes read might be up to all
kinds of factors (including io request and tcp segment boundaries). 

It is not a valid abstraction to model records basd on read sizes. I
think using available() is almost always a bug. (But I am not sure what
the specific datastructures involved are).

Gruss
Bernd



Am Wed, 31 Aug 2016 09:18:23 +0800
schrieb Weijun Wang <weijun.wang at oracle.com>:
> 
> 
> On 8/31/2016 0:46, Svetlana Nikandrova wrote:
> > Hi Max,
> >
> > thank you for your replay. Please see inline.
> >
> > On 30.08.2016 5:43, Weijun Wang wrote:
> >> readAllBytes() wants to real *all* data. If this is during a long
> >> time communication, and the peer sends a BER using indefinite
> >> length, and then wait for the next round of dialog without closing
> >> the stream, will readAllBytes() hang?
> >
> > readAllBytes() blocks until all remaining data has been read and
> > end of stream is detected.
> > So if I understood your scenario correctly, yes, if EOF is not
> > present it will hang. AFAIK when KeyStore.load completes
> > successfully it consumes the input stream until EOF, so isn't it ok
> > to expect it?
> 
> The KeyStore::load method makes no assumption on the InputStream 
> parameter. More important, DerValue is used much wider than pkcs12
> keystore.
> 
> >
> >> Is it possible to create a new method readAllAvailables() here? It
> >> kept read data until available() is zero and return the
> >> concatenated byte array. I think this method does not block and is
> >> able to read everything available from a SequenceInputStream.
> >
> > Yes, I think it is possible to read data by portions, but
> > unfortunately straight forward approach like
> > "while(is.available() !=0)" won't work. As soon as we reach the end
> > of the first stream in SequenceInputStream sequence is.available()
> > will return 0 until we switch to the next stream by calling read().
> > I'm afraid it will look a little bit confusing.
> 
> Well, this is unfortunate.
> 
> I also cannot think of a simple fix now. Maybe after see that "not
> all indef len BER resolved" error you can try read more.
> 
> >
> >> In fact, IMO the DerValue is not implemented correctly. It should
> >> have been able to read the input data chunk by chunk until a BER
> >> is fully consumed, leaving data after the BER untouched, and block
> >> if the BER is not complete. To achieve this, it should read the
> >> header, read zero or more sub-data, read the EOC, recursively if
> >> necessary.
> >
> > It asks for some investigation. Should I create a separate issue?
> 
> You can, but please set the target version to major-tbd unless you
> want to work on it now.
> 
> Thanks
> Max
> 
> >
> > Thank you,
> > Svetlana
> >
> >>
> >> Thanks
> >> Max
> >>
> >> On 8/30/2016 2:52, Artem Smotrakov wrote:
> >>> Hi Svetlana,
> >>>
> >>> It looks fine, but I am not an official reviewer.
> >>>
> >>> "keystorePath" in readTest() can be a static field.
> >>>
> >>> I also meant that one test with SequenceInputStream seems to be
> >>> enough, so you could just add a new test case to
> >>> ReadP12Test.java. But it's fine.
> >>>
> >>> I am not sure how DerIndefLenConverter works, but it looks a
> >>> little strange to me that it needs to extend an array before
> >>> passing it to DerIndefLenConverter. I see that convert() method
> >>> also uses arraycopy() method. But it seems to be out of scope
> >>> here.
> >>>
> >>> Artem
> >>>
> >>>
> >>> On 08/29/2016 11:23 AM, Svetlana Nikandrova wrote:
> >>>> Hi Artem,
> >>>>
> >>>> thank you for your replay. I've updated copyright and made
> >>>> separate test for this bug.
> >>>> As for Arrays.copyOfRange() unfortunately it won't simplify code
> >>>> in my case. I need to extend an array, not to get a sub-array of
> >>>> existing one.
> >>>>
> >>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.01/
> >>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.01/>
> >>>>
> >>>> Thanks,
> >>>> Svetlana
> >>>>
> >>>> On 26.08.2016 23:48, Artem Smotrakov wrote:
> >>>>>
> >>>>> Hi Svetlana,
> >>>>>
> >>>>> DerValue class may be implicitly used in different areas (x509,
> >>>>> SSL/TLS, keystores, maybe krb5, etc). Please make sure that
> >>>>> tests from jdk_security pass.
> >>>>>
> >>>>> I'll leave the main review to someone who is more knowledgeable
> >>>>> in this area, here are a couple of comments:
> >>>>> - Please update copyright year
> >>>>> - You may want to replace new byte[] + System.arraycopy() by
> >>>>> Arrays.copyOfRange()
> >>>>> - It may be better to add a separate test case in
> >>>>> ReadP12Test.java for SequenceInputStream instead of loading a
> >>>>> keystore twice in each call to readTest(). One test with
> >>>>> SequenceInputStream seems to be enough, and it would make the
> >>>>> logic of readTest() clearer.
> >>>>>
> >>>>> Artem
> >>>>>
> >>>>> On 08/26/2016 10:58 AM, Svetlana Nikandrova wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> please review this fix. It's not possible to read PKCS12
> >>>>>> keystore with big undefined length DER value in it from
> >>>>>> SequenceInputStream. Root cause of the problem is that
> >>>>>> sun.security.util.DerValue relays on InputStream.available()
> >>>>>> to get a complete 'indefinite.length' section length and then
> >>>>>> read it, but for SequenceInputStream this method returns
> >>>>>> number of available bytes only for current input stream, not
> >>>>>> the whole sequence. Fixed to read all available data.
> >>>>>>
> >>>>>> JBS:
> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8157404
> >>>>>> Webrev:
> >>>>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/
> >>>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Svetlana
> >>>>>>
> >>>>>
> >>>>
> >>>
> >



From weijun.wang at oracle.com  Wed Aug 31 02:04:18 2016
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 31 Aug 2016 10:04:18 +0800
Subject: RFR 8157404: Unable to read certain PKCS12 keystores from
	SequenceInputStream
In-Reply-To: <20160831034430.0000407e.ecki@zusammenkunft.net>
References: <57C08329.10401@oracle.com>
	<f6477183-d302-b0e5-bd8e-d5973ee033ee@oracle.com>
	<57C47DBB.2040505@oracle.com>
	<4dc4fe5d-b03b-413c-8dfa-c28ce4720bb7@oracle.com>
	<d911ed7f-e812-6586-4820-efd60092731a@oracle.com>
	<57C5B85B.9060900@oracle.com>
	<fb8ffbad-c87d-9b48-b7f8-111615e98d16@oracle.com>
	<20160831034430.0000407e.ecki@zusammenkunft.net>
Message-ID: <a7e3fd91-2f25-5039-d9fd-9797f5bd506c@oracle.com>

Yes, that's why I said it's not implemented correctly, but it has worked 
fine until this bug appears.

--Max

On 8/31/2016 9:44, Bernd Eckenfels wrote:
> Hello,
>
> readBytes read all bytes of a specified length. If the length is not
> known it is not usefull to use. Besides it is also not usefull to only
> read available() bytes, as the nmber of bytes read might be up to all
> kinds of factors (including io request and tcp segment boundaries).
>
> It is not a valid abstraction to model records basd on read sizes. I
> think using available() is almost always a bug. (But I am not sure what
> the specific datastructures involved are).
>
> Gruss
> Bernd
>
>
>
> Am Wed, 31 Aug 2016 09:18:23 +0800
> schrieb Weijun Wang <weijun.wang at oracle.com>:
>>
>>
>> On 8/31/2016 0:46, Svetlana Nikandrova wrote:
>>> Hi Max,
>>>
>>> thank you for your replay. Please see inline.
>>>
>>> On 30.08.2016 5:43, Weijun Wang wrote:
>>>> readAllBytes() wants to real *all* data. If this is during a long
>>>> time communication, and the peer sends a BER using indefinite
>>>> length, and then wait for the next round of dialog without closing
>>>> the stream, will readAllBytes() hang?
>>>
>>> readAllBytes() blocks until all remaining data has been read and
>>> end of stream is detected.
>>> So if I understood your scenario correctly, yes, if EOF is not
>>> present it will hang. AFAIK when KeyStore.load completes
>>> successfully it consumes the input stream until EOF, so isn't it ok
>>> to expect it?
>>
>> The KeyStore::load method makes no assumption on the InputStream
>> parameter. More important, DerValue is used much wider than pkcs12
>> keystore.
>>
>>>
>>>> Is it possible to create a new method readAllAvailables() here? It
>>>> kept read data until available() is zero and return the
>>>> concatenated byte array. I think this method does not block and is
>>>> able to read everything available from a SequenceInputStream.
>>>
>>> Yes, I think it is possible to read data by portions, but
>>> unfortunately straight forward approach like
>>> "while(is.available() !=0)" won't work. As soon as we reach the end
>>> of the first stream in SequenceInputStream sequence is.available()
>>> will return 0 until we switch to the next stream by calling read().
>>> I'm afraid it will look a little bit confusing.
>>
>> Well, this is unfortunate.
>>
>> I also cannot think of a simple fix now. Maybe after see that "not
>> all indef len BER resolved" error you can try read more.
>>
>>>
>>>> In fact, IMO the DerValue is not implemented correctly. It should
>>>> have been able to read the input data chunk by chunk until a BER
>>>> is fully consumed, leaving data after the BER untouched, and block
>>>> if the BER is not complete. To achieve this, it should read the
>>>> header, read zero or more sub-data, read the EOC, recursively if
>>>> necessary.
>>>
>>> It asks for some investigation. Should I create a separate issue?
>>
>> You can, but please set the target version to major-tbd unless you
>> want to work on it now.
>>
>> Thanks
>> Max
>>
>>>
>>> Thank you,
>>> Svetlana
>>>
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>> On 8/30/2016 2:52, Artem Smotrakov wrote:
>>>>> Hi Svetlana,
>>>>>
>>>>> It looks fine, but I am not an official reviewer.
>>>>>
>>>>> "keystorePath" in readTest() can be a static field.
>>>>>
>>>>> I also meant that one test with SequenceInputStream seems to be
>>>>> enough, so you could just add a new test case to
>>>>> ReadP12Test.java. But it's fine.
>>>>>
>>>>> I am not sure how DerIndefLenConverter works, but it looks a
>>>>> little strange to me that it needs to extend an array before
>>>>> passing it to DerIndefLenConverter. I see that convert() method
>>>>> also uses arraycopy() method. But it seems to be out of scope
>>>>> here.
>>>>>
>>>>> Artem
>>>>>
>>>>>
>>>>> On 08/29/2016 11:23 AM, Svetlana Nikandrova wrote:
>>>>>> Hi Artem,
>>>>>>
>>>>>> thank you for your replay. I've updated copyright and made
>>>>>> separate test for this bug.
>>>>>> As for Arrays.copyOfRange() unfortunately it won't simplify code
>>>>>> in my case. I need to extend an array, not to get a sub-array of
>>>>>> existing one.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.01/
>>>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.01/>
>>>>>>
>>>>>> Thanks,
>>>>>> Svetlana
>>>>>>
>>>>>> On 26.08.2016 23:48, Artem Smotrakov wrote:
>>>>>>>
>>>>>>> Hi Svetlana,
>>>>>>>
>>>>>>> DerValue class may be implicitly used in different areas (x509,
>>>>>>> SSL/TLS, keystores, maybe krb5, etc). Please make sure that
>>>>>>> tests from jdk_security pass.
>>>>>>>
>>>>>>> I'll leave the main review to someone who is more knowledgeable
>>>>>>> in this area, here are a couple of comments:
>>>>>>> - Please update copyright year
>>>>>>> - You may want to replace new byte[] + System.arraycopy() by
>>>>>>> Arrays.copyOfRange()
>>>>>>> - It may be better to add a separate test case in
>>>>>>> ReadP12Test.java for SequenceInputStream instead of loading a
>>>>>>> keystore twice in each call to readTest(). One test with
>>>>>>> SequenceInputStream seems to be enough, and it would make the
>>>>>>> logic of readTest() clearer.
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 08/26/2016 10:58 AM, Svetlana Nikandrova wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> please review this fix. It's not possible to read PKCS12
>>>>>>>> keystore with big undefined length DER value in it from
>>>>>>>> SequenceInputStream. Root cause of the problem is that
>>>>>>>> sun.security.util.DerValue relays on InputStream.available()
>>>>>>>> to get a complete 'indefinite.length' section length and then
>>>>>>>> read it, but for SequenceInputStream this method returns
>>>>>>>> number of available bytes only for current input stream, not
>>>>>>>> the whole sequence. Fixed to read all available data.
>>>>>>>>
>>>>>>>> JBS:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157404
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~snikandrova/8157404/webrev.00/
>>>>>>>> <http://cr.openjdk.java.net/%7Esnikandrova/8157404/webrev.00/>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Svetlana
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>


From sean.coffey at oracle.com  Wed Aug 31 15:17:06 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 31 Aug 2016 16:17:06 +0100
Subject: RFR: 8164846: CertificateException missing cause of underlying
	exception
Message-ID: <57C6F4F2.6070508@oracle.com>

bug ID : https://bugs.openjdk.java.net/browse/JDK-8164846
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8164846.jdk9/webrev/

A CertificateException in SSLContextImpl doesn't include information 
about the cause of the exception. This can often contain a valuable 
snippet of information about the exact reason for the exception (like a 
constraint failure).

-- 
Regards,
Sean.

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