From weijun.wang at oracle.com  Tue Dec  1 01:32:29 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 1 Dec 2015 09:32:29 +0800
Subject: S4U2Self and OpenJDK 8
In-Reply-To: <CAH2S7UA8eGRCUWEpC8igOauTQ6fadxVUdE100_jWdAfJ2RhGxg@mail.gmail.com>
References: <CAH2S7UA8eGRCUWEpC8igOauTQ6fadxVUdE100_jWdAfJ2RhGxg@mail.gmail.com>
Message-ID: <BA9565CB-0267-412A-8925-A9BDC47D4993@oracle.com>

Hi Marc

Looks like the problem is below:

>> KrbKdcRep.check: at #1. request for true, received false

We've already fixed this in jdk9 at

  https://bugs.openjdk.java.net/browse/JDK-8022582
  http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ae6449bc523f

you can see the check now starts at #2.

Can you try out the latest jdk9 at https://jdk9.java.net/download/?

Meanwhile, I'll file a backport request to jdk8u.

Thanks
Max


From bradford.wetmore at oracle.com  Tue Dec  1 01:32:47 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 30 Nov 2015 17:32:47 -0800
Subject: Request for review: 8144093: JEP 244/8051498 - TLS
	Application-Layer Protocol Negotiation Extension
In-Reply-To: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
Message-ID: <565CF8BF.50200@oracle.com>


On 11/29/2015 4:08 PM, Vincent Ryan wrote:

 > Following on from Brad?s recent email, here is the full webrev of the
 > API and the implementation classes for ALPN:
 > http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/
 >
 > In adds the implementation classes (sun/security/ssl) to the public API
 > classes (javax/net/ssl) which have already been agreed.
 > Some basic tests (test/javax/net/ssl) are also included.

SSLEngineAlpnTest.java
======================

333:  A minor comment here. I think you should test NONE like this:

     if (ap == null) {
         throw new Exception(
             "Handshake was completed but null was received");
     }
     if (expectedAP.equals("NONE")) {
         if (!ap.isEmpty()) {
             throw new Exception();
         } else {
             System.out.println("No ALPN value negotiated, as expected");
         }
     } else if (!expectedAP.equals(ap)) {
         throw new Exception(expectedAP +
             " ALPN value not available on negotiated connection");
     }

BTW, the indentions here at 331/332/334 are off.  The rest are all ok.

We had also talked privately about testing 
getHandshakeApplicationProtocol(), but I don't see it here.  Let me know 
if you didn't understand my comments about adding a 
X509ExtendedKeyManager (or X509ExtendedTrustManager), or else please 
file a RFE for it if it won't be ready for the initial integration.

298:  This test is not actually calling into checkResult on the server 
side.  Ooops!  You need to check the output of the wrap() before calling 
unwrap() as it overwrites the serverResult.  You need to put in a 
similar checkResult() before doing the flip()s.


SSLSocketAlpnTest.java
======================

Same concern here as above.


On 11/29/2015 10:30 PM, Xuelei Fan wrote:
 > line 538-546
 > ------------
 >     String negotiatedValue = null;
 >     List<String> protocols = clientHelloALPN.getPeerAPs();
 >
 >     for (String ap : localApl) {
 >         if (protocols.contains(ap)) {
 >             negotiatedValue = ap;
 >             break;
 >         }
 >     }
 >
 > I think the above order prefer the server preference order of
 > application protocols.  It's OK per Section 3.2 of RFC 7301.

Correct:

    In that case, the server SHOULD select the most
    highly preferred protocol that it supports and that is also
    advertised by the client.

 > However RFC 7301 also defines the client preference order.  Looks like
 > the client preference order is not necessary.  It's a little bit
 > confusing, and may result in different behaviors for different TLS 
vendors.
 >
 > Maybe, we can add an option to honor server preference order in the 
future.

That was the plan if needed.

Vincent wrote:
 > If necessary I think we can add support for controlling this via a
 > property, later.

Or a new API (when possible):  a new "preferPeerOrder" method and an 
update to the setApplicationProtocols() text:

     Unless configured by the preferPeerOrder() method, the first
     matched value becomes the negotiated value.

On 11/30/2015 3:08 PM, Vincent Ryan wrote:
 >> SSLEngineImpl.java
 >> >==================
 >> >
 >> >line 1411-1412:
 >> >private Ciphertext writeRecord(ByteBuffer[] appData,
 >> >    int offset, int length, ByteBuffer netData) throws IOException {
 >> >    ...
 >> >  if (...) {
 >> >    ...
 >> >    // set connection ALPN value
 >> >    applicationProtocol =
 >> >        handshaker.getHandshakeApplicationProtocol();
 >> >    ...
 >> >  }
 >> >}
 >> >
 >> >Is it redundant to set applicationProtocol here.  I was wondering, the
 >> >value should set in the processInputRecord() method.
 >
 > My understanding is the the wrapping is performed here and the unwrapping
 > performed in processInputRecord(). Isn?t the assignment required in 
both places?

Apparently it's not, I thought it was.  When unwrapping the final 
inbound Finished message around line 1069, it advances the internal 
state and writes its own Finished message into the outbound queue, but 
doesn't actually return hs=FINISHED until the outbound queue is drained.

I had to step through it to confirm.  So you can remove it.

Thanks, Vinnie, looks good.

Brad


From xuelei.fan at oracle.com  Tue Dec  1 01:53:23 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 1 Dec 2015 09:53:23 +0800
Subject: Request for review: 8144093: JEP 244/8051498 - TLS
	Application-Layer Protocol Negotiation Extension
In-Reply-To: <A1B7D72B-9109-48D4-B842-0EC8D37342AF@oracle.com>
References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
	<565BED18.70202@oracle.com>
	<A1B7D72B-9109-48D4-B842-0EC8D37342AF@oracle.com>
Message-ID: <565CFD93.6030807@oracle.com>

Looks fine to me.  Thanks for the update.

Xuelei

On 12/1/2015 7:08 AM, Vincent Ryan wrote:
> Thanks for your review. Comments in-line.
> 
>> On 30 Nov 2015, at 06:30, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> Looks fine to me.  Just a few minor comments.
>>
>> ServerHandshaker.java
>> =====================
>> There is a typo of the first line.
>> - /* Copyright (c) 1996, 2015, ...
>> + /*
>> +  * Copyright (c) 1996, 2015 ?
>>
> Done.
> 
>>
>> line 538-546
>> ------------
>>   String negotiatedValue = null;
>>   List<String> protocols = clientHelloALPN.getPeerAPs();
>>
>>   for (String ap : localApl) {
>>       if (protocols.contains(ap)) {
>>           negotiatedValue = ap;
>>           break;
>>       }
>>   }
>>
>> I think the above order prefer the server preference order of
>> application protocols.  It's OK per Section 3.2 of RFC 7301.
>>
>> However RFC 7301 also defines the client preference order.  Looks like
>> the client preference order is not necessary.  It's a little bit
>> confusing, and may result in different behaviors for different TLS vendors.
>>
>> Maybe, we can add an option to honor server preference order in the future.
> 
> I added a comment to show that server-preference is used.
> If necessary I think we can add support for controlling this via a property, later.
> 
> 
>>
>> ALPNExtension.java
>> ==================
>> 96    listLength = s.getInt16(); // list length
>>
>> The code would throws SSLException if the remaining input is not
>> sufficient.  I was wondering, SSLProtocolException may be more suitable
>> here.  May be nice to check the "len" argument value if sufficient for
>> the list length.  Otherwise, a SSLProtocolException would be thrown.
>>
>>    if (len >= 2) {
>>        listLength = s.getInt16(); // list length
>>        ...
>>    } else {
>>        throw new SSLProtocolException(...);
>>    }
> 
> I added the exception and more detailed message.
> 
>>
>> -----------
>> 104   byte[] bytes = s.getBytes8();
>> 105   String p =
>> 106       new String(bytes, StandardCharsets.UTF_8); // app protocol
>>
>> Do you want to check that the app protocol cannot be empty?
>>
>>     // opaque ProtocolName<1..2^8-1>;  // RFC 7301
>>     byte[] bytes = s.getBytes8();
>> +    if (bytes.length == 0) {
>> +        throw new SSLProtocolException("Empty ...");
>> +    }
> 
> Done.
> 
> 
>>
>> ---------
>> Personally, I would prefer to use unmodifiableList for the protocolNames
>> variable.
> 
> It is accessible only to classes in this package.
> 
> 
>>
>>
>> HelloExtensions.java
>> ====================
>> line 34-37:
>> * This file contains all the classes relevant to TLS Extensions for the
>> * ClientHello and ServerHello messages. The extension mechanism and
>> * several extensions are defined in RFC 3546. Additional extensions are
>> * defined in the ECC RFC 4492.The ALPN extension is defined in RFC7301.
>>
>> I may put the "Additional extensions ..." at the end.  BTW, as you are
>> here already, would you mind update RFC 3546 to RFC 6066?  RFC 6066 is
>> the newest revision of RFC 3546.
> 
> I concatenated the final sentence.
> 
> 
>>
>> * This file contains all the classes relevant to TLS Extensions for the
>> * ClientHello and ServerHello messages. The extension mechanism and
>> * several extensions are defined in RFC 6066. The ALPN extension is
>> * defined in RFC 7301.  Additional extensions are defined in the ECC
>> * RFC 4492.
>>
>> SSLEngineImpl.java
>> ==================
>>
>> line 1411-1412:
>> private Ciphertext writeRecord(ByteBuffer[] appData,
>>    int offset, int length, ByteBuffer netData) throws IOException {
>>    ...
>>  if (...) {
>>    ...
>>    // set connection ALPN value
>>    applicationProtocol =
>>        handshaker.getHandshakeApplicationProtocol();
>>    ...
>>  }
>> }
>>
>> Is it redundant to set applicationProtocol here.  I was wondering, the
>> value should set in the processInputRecord() method.
> 
> My understanding is the the wrapping is performed here and the unwrapping 
> performed in processInputRecord(). Isn?t the assignment required in both places?
> 
> 
> 
>>
>> Cheers,
>> Xuelei
>>
>> On 11/30/2015 8:08 AM, Vincent Ryan wrote:
>>> Hello,
>>>
>>> Following on from Brad?s recent email, here is the full webrev of the
>>> API and the implementation classes for ALPN:
>>>  http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/
>>>
>>> In adds the implementation classes (sun/security/ssl) to the public API
>>> classes (javax/net/ssl) which have already been agreed.
>>> Some basic tests (test/javax/net/ssl) are also included.
>>>
>>> Please send any code review comments by close-of-business on Tuesday 1
>>> December.
>>> Thanks.
>>
> 


From marc.boorshtein at tremolosecurity.com  Tue Dec  1 02:38:27 2015
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Mon, 30 Nov 2015 21:38:27 -0500
Subject: S4U2Self and OpenJDK 8
In-Reply-To: <BA9565CB-0267-412A-8925-A9BDC47D4993@oracle.com>
References: <CAH2S7UA8eGRCUWEpC8igOauTQ6fadxVUdE100_jWdAfJ2RhGxg@mail.gmail.com>
	<BA9565CB-0267-412A-8925-A9BDC47D4993@oracle.com>
Message-ID: <CAH2S7UBL4AP==P=TT38XNVpQ7WJvhrri=y2A0sZiPS7Kd+kf1Q@mail.gmail.com>

Thank Max.  On OSX with the latest 1.9 I get the following:

>>> KeyTabInputStream, readName(): RHELENT.LAN
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): s4u.rhelent.lan
>>> KeyTab: load() entry length: 83; type: 18
>>> KeyTabInputStream, readName(): RHELENT.LAN
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): s4u.rhelent.lan
>>> KeyTab: load() entry length: 67; type: 17
>>> KeyTabInputStream, readName(): RHELENT.LAN
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): s4u.rhelent.lan
>>> KeyTab: load() entry length: 75; type: 16
>>> KeyTabInputStream, readName(): RHELENT.LAN
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): s4u.rhelent.lan
>>> KeyTab: load() entry length: 67; type: 23
Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN
Java config name: null
Native config name: /etc/krb5.conf
Loading krb5 profile at /etc/krb5.conf
Loaded from native config
Added key: 23version: 1
Added key: 16version: 1
Added key: 17version: 1
Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN
>>> KdcAccessibility: reset
Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN
Added key: 23version: 1
Added key: 16version: 1
Added key: 17version: 1
Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN
default etypes for default_tkt_enctypes: 17 23 16.
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=175
>>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=175
>>> KrbKdcReq send: #bytes read=327
>>>Pre-Authentication Data:
PA-DATA type = 136

>>>Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null
PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB<CQ#Vq,Ls&, s2kparams = null
PA-ETYPE-INFO2 etype = 23, salt = Wl=W>9)&A{.`Y;1k, s2kparams = null

>>>Pre-Authentication Data:
PA-DATA type = 2
PA-ENC-TIMESTAMP
>>>Pre-Authentication Data:
PA-DATA type = 133

>>> KdcAccessibility: remove freeipa.rhelent.lan
>>> KDCRep: init() encoding tag is 126 req type is 11
>>>KRBError:
cTime is Sat Jan 20 19:00:57 EST 1996 822182457000
sTime is Mon Nov 30 21:35:51 EST 2015 1448937351000
suSec is 558140
error code is 25
error Message is Additional pre-authentication required
cname is HTTP/s4u.rhelent.lan at RHELENT.LAN
sname is krbtgt/RHELENT.LAN at RHELENT.LAN
eData provided.
msgType is 30
>>>Pre-Authentication Data:
PA-DATA type = 136

>>>Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null
PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB<CQ#Vq,Ls&, s2kparams = null
PA-ETYPE-INFO2 etype = 23, salt = Wl=W>9)&A{.`Y;1k, s2kparams = null

>>>Pre-Authentication Data:
PA-DATA type = 2
PA-ENC-TIMESTAMP
>>>Pre-Authentication Data:
PA-DATA type = 133

KRBError received: NEEDED_PREAUTH
KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ
default etypes for default_tkt_enctypes: 17 23 16.
Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN
Added key: 23version: 1
Added key: 16version: 1
Added key: 17version: 1
Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN
Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN
Added key: 23version: 1
Added key: 16version: 1
Added key: 17version: 1
Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN
default etypes for default_tkt_enctypes: 17 23 16.
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsReq creating message
>>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=264
>>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=264
>>> KrbKdcReq send: #bytes read=691
>>> KdcAccessibility: remove freeipa.rhelent.lan
Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN
Added key: 23version: 1
Added key: 16version: 1
Added key: 17version: 1
Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbAsRep cons in KrbAsReq.getReply HTTP/s4u.rhelent.lan
Service subject: Subject:
Principal: HTTP/s4u.rhelent.lan at RHELENT.LAN
Private Credential: Ticket (hex) =
0000: 61 82 01 51 30 82 01 4D   A0 03 02 01 05 A1 0D 1B  a..Q0..M........
0010: 0B 52 48 45 4C 45 4E 54   2E 4C 41 4E A2 20 30 1E  .RHELENT.LAN. 0.
0020: A0 03 02 01 02 A1 17 30   15 1B 06 6B 72 62 74 67  .......0...krbtg
0030: 74 1B 0B 52 48 45 4C 45   4E 54 2E 4C 41 4E A3 82  t..RHELENT.LAN..
0040: 01 13 30 82 01 0F A0 03   02 01 12 A1 03 02 01 01  ..0.............
0050: A2 82 01 01 04 81 FE 04   0B 24 5B A6 36 2A 4B C7  .........$[.6*K.
0060: 0D 58 1A EB 79 20 62 BE   16 44 28 93 5D 87 5B FD  .X..y b..D(.].[.
0070: DE 20 7D CF 79 4C 0E CC   77 90 40 06 10 11 9F 70  . ..yL..w. at ....p
0080: 9E B4 7E B5 CA 14 27 23   DD CD D6 6E 31 1F FC CA  ......'#...n1...
0090: 65 CB 98 47 2B F0 C8 3B   96 C3 D6 AF EB DB 91 2F  e..G+..;......./
00A0: 1D 88 66 53 4F 03 7B 47   3C 32 E8 F2 CE 3E B1 E7  ..fSO..G<2...>..
00B0: 78 80 B3 37 6F 5E 18 76   68 F4 AE C6 C7 C2 B8 99  x..7o^.vh.......
00C0: 61 A3 42 A1 5D 32 69 BB   0D 42 C5 98 46 B8 8A C6  a.B.]2i..B..F...
00D0: 4A 68 88 E3 79 D0 E2 F7   DD 62 0F DD E6 6A 97 7B  Jh..y....b...j..
00E0: 4B A1 A0 1C 45 17 97 E4   CC 71 D2 86 61 52 40 34  K...E....q..aR at 4
00F0: DE EF 45 5E 21 94 AB 5C   76 91 CE 68 DB A1 94 5F  ..E^!..\v..h..._
0100: 14 CC 54 BB 35 85 EB 56   F0 FC 83 B5 CB 41 48 A1  ..T.5..V.....AH.
0110: AE C8 2F 22 C6 48 B9 14   CD 5F 9B B5 14 2B CC D5  ../".H..._...+..
0120: B7 DC C3 74 4C 98 19 10   72 83 5D F6 BC A0 A1 9F  ...tL...r.].....
0130: 19 1F 63 07 AF C1 35 EE   1A 82 FE A5 88 CE 7A DF  ..c...5.......z.
0140: 0F 43 E4 55 EC CC 0C 34   47 B4 B8 E1 C2 90 AC 63  .C.U...4G......c
0150: 19 01 A1 87 A5                                     .....

Client Principal = HTTP/s4u.rhelent.lan at RHELENT.LAN
Server Principal = krbtgt/RHELENT.LAN at RHELENT.LAN
Session Key = EncryptionKey: keyType=17 keyBytes (hex dump)=
0000: D9 D2 7F 9D 3F 5F 32 1A   41 10 4D 9F 0C 7D C5 D8  ....?_2.A.M.....


Forwardable Ticket true
Forwarded Ticket false
Proxiable Ticket false
Proxy Ticket false
Postdated Ticket false
Renewable Ticket true
Initial Ticket true
Auth Time = Mon Nov 30 21:35:51 EST 2015
Start Time = Mon Nov 30 21:35:51 EST 2015
End Time = Tue Dec 01 21:35:51 EST 2015
Renew Till = Mon Dec 07 21:35:51 EST 2015
Client Addresses  Null
Private Credential: /Users/mlb/Documents/localdev.keytab for
HTTP/s4u.rhelent.lan at RHELENT.LAN

Search Subject for Kerberos V5 INIT cred (<<DEF>>,
sun.security.jgss.krb5.Krb5InitCredential)
Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to
krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 21:35:51 EST
2015
Search Subject for SPNEGO INIT cred (<<DEF>>,
sun.security.jgss.spnego.SpNegoCredElement)
Search Subject for Kerberos V5 INIT cred (<<DEF>>,
sun.security.jgss.krb5.Krb5InitCredential)
Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to
krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 21:35:51 EST
2015
>>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType
default etypes for default_tgs_enctypes: 17 23 16.
>>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
>>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=772
>>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=772
>>> KrbKdcReq send: #bytes read=582
>>> KdcAccessibility: remove freeipa.rhelent.lan
>>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
GSSException: Failure unspecified at GSS-API level (Mechanism level:
Attempt to obtain S4U2self credentials failed!)
at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357)
at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:92)
at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:153)
at test24u2.KerberosDemo$1.run(KerberosDemo.java:128)
at test24u2.KerberosDemo$1.run(KerberosDemo.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at test24u2.KerberosDemo.impersonate(KerberosDemo.java:121)
at test24u2.KerberosDemo.generateToken(KerberosDemo.java:179)
at test24u2.KerberosDemo.main(KerberosDemo.java:215)
Caused by: KrbException: S4U2self ticket must be FORWARDABLE
at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:75)
at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463)
at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353)
... 9 more

Seems it looks like its still doing the check for forwardable.

Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
(703) 828-4902


On Mon, Nov 30, 2015 at 8:32 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> Hi Marc
>
> Looks like the problem is below:
>
>>> KrbKdcRep.check: at #1. request for true, received false
>
> We've already fixed this in jdk9 at
>
>   https://bugs.openjdk.java.net/browse/JDK-8022582
>   http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ae6449bc523f
>
> you can see the check now starts at #2.
>
> Can you try out the latest jdk9 at https://jdk9.java.net/download/?
>
> Meanwhile, I'll file a backport request to jdk8u.
>
> Thanks
> Max
>

From weijun.wang at oracle.com  Tue Dec  1 03:01:37 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 1 Dec 2015 11:01:37 +0800
Subject: S4U2Self and OpenJDK 8
In-Reply-To: <CAH2S7UBL4AP==P=TT38XNVpQ7WJvhrri=y2A0sZiPS7Kd+kf1Q@mail.gmail.com>
References: <CAH2S7UA8eGRCUWEpC8igOauTQ6fadxVUdE100_jWdAfJ2RhGxg@mail.gmail.com>
	<BA9565CB-0267-412A-8925-A9BDC47D4993@oracle.com>
	<CAH2S7UBL4AP==P=TT38XNVpQ7WJvhrri=y2A0sZiPS7Kd+kf1Q@mail.gmail.com>
Message-ID: <7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com>

It is my understanding that if the S4U2self ticket is not forwardable then it cannot be used in a S4U2proxy request. That's we just threw an exception. Am I wrong? Or you don't intend to use it this way?

--Max


From weijun.wang at oracle.com  Tue Dec  1 06:17:37 2015
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 1 Dec 2015 14:17:37 +0800
Subject: RFR 8144294: jdk/security/jarsigner/Function.java failed to clean up
	files after test on Windows
Message-ID: <565D3B81.7040802@oracle.com>

Please review the fix at

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

A file was not closed.

Thanks
Max

From xuelei.fan at oracle.com  Tue Dec  1 07:04:57 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 1 Dec 2015 15:04:57 +0800
Subject: RFR 8144294: jdk/security/jarsigner/Function.java failed to clean
	up files after test on Windows
In-Reply-To: <565D3B81.7040802@oracle.com>
References: <565D3B81.7040802@oracle.com>
Message-ID: <565D4699.9030500@oracle.com>

Looks fine to me.

Xuelei

On 12/1/2015 2:17 PM, Weijun Wang wrote:
> Please review the fix at
> 
>    http://cr.openjdk.java.net/~weijun/8144294/webrev.00/
> 
> A file was not closed.
> 
> Thanks
> Max


From simone.bordet at gmail.com  Tue Dec  1 09:53:47 2015
From: simone.bordet at gmail.com (Simone Bordet)
Date: Tue, 1 Dec 2015 10:53:47 +0100
Subject: Request for review: 8144093: JEP 244/8051498 - TLS
	Application-Layer Protocol Negotiation Extension
In-Reply-To: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
Message-ID: <CAFWmRJ280TRDmF=5iQAwZmmvTAi15h65RoUgcZaOnOkqNfcttQ@mail.gmail.com>

Hi,

On Mon, Nov 30, 2015 at 1:08 AM, Vincent Ryan <vincent.x.ryan at oracle.com> wrote:
> Hello,
>
> Following on from Brad?s recent email, here is the full webrev of the API
> and the implementation classes for ALPN:
>   http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/
>
> In adds the implementation classes (sun/security/ssl) to the public API
> classes (javax/net/ssl) which have already been agreed.
> Some basic tests (test/javax/net/ssl) are also included.

I just would like to remind that session resumption is a very
important use case to support for ALPN.

I have not seen anything related to this review for session resumption.
Has it been tested ?

It is still not clear to me what a client and a server have to do to
support ALPN.

>From my understanding a server has to:

* read encrypted bytes into a ByteBuffer
* parse the TLS ClientHello frame on its own
* extract from the ClientHello the TLS Protocol version, the ALPN
extension, and the ciphers
* run some logic to determine the AP
** if no AP can be chosen, generate a TLS Alert frame on its own to
close the connection and bail out
* otherwise, an AP/cipher combo has been chosen
* sslParameters.setApplicationProtocols(AP) // just one protocol
* sslParameters.setCipherSuites(cipher) // just one cipher
* sslEngine.setSSLParameters(sslParameters)
* reset the ByteBuffer position to the beginning
* pass the ByteBuffer to sslEngine.unwrap()
* JDK implementation will re-parse the ClientHello, and use the
sslParameters data during handshake and when generating the
ServerHello


A client has to:

* read encrypted bytes into a ByteBuffer
* parse a ServerHello frame on its own
* extract the ALPN extension and the cipher
* run some logic to verify that the AP and the cipher can be used together
** if AP and cipher don't match, generate a TLS Alert frame on its own
to close the connection and bail out
* otherwise the AP/cipher combo is ok
* reset the ByteBuffer position to the beginning
* pass the ByteBuffer to sslEngine.unwrap()
* JDK implementation will re-parse the ServerHello and complete the
TLS handshake

Is that right ?

In that scenario, what is the use of
SSLEngine.getHandshakeApplicationProtocol() ?

Also, I don't understand how the above could work for SSLSocket ?
Can someone write down the steps a client and a server should do to
actually use ALPN with SSLSocket ?

Thanks !

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

From xuelei.fan at oracle.com  Tue Dec  1 10:48:21 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 1 Dec 2015 18:48:21 +0800
Subject: Code Review Request, 8144313, Test SessionTimeOutTests can be timeout
Message-ID: <565D7AF5.3000904@oracle.com>

Hi,

Please review this test update:

   http://cr.openjdk.java.net/~xuelei/8144313/webrev.00/

In test/javax/net/ssl/SSLSession/SessionTimeOutTests.java, the update of
"serverReady" variable was not synchronized when performing multiple
operations, as may result that the variable cannot be calculated
correctly, and result in timeout accordingly.

Update to use AtomicInteger for the atomic update.

Thanks,
Xuelei

From sean.mullan at oracle.com  Tue Dec  1 12:36:28 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 1 Dec 2015 07:36:28 -0500
Subject: Code Review Request, 8144313, Test SessionTimeOutTests can be
	timeout
In-Reply-To: <565D7AF5.3000904@oracle.com>
References: <565D7AF5.3000904@oracle.com>
Message-ID: <565D944C.1@oracle.com>

serverReady doesn't need to be volatile anymore.

Looks good otherwise.

--Sean

On 12/01/2015 05:48 AM, Xuelei Fan wrote:
> Hi,
>
> Please review this test update:
>
>     http://cr.openjdk.java.net/~xuelei/8144313/webrev.00/
>
> In test/javax/net/ssl/SSLSession/SessionTimeOutTests.java, the update of
> "serverReady" variable was not synchronized when performing multiple
> operations, as may result that the variable cannot be calculated
> correctly, and result in timeout accordingly.
>
> Update to use AtomicInteger for the atomic update.
>
> Thanks,
> Xuelei
>

From xuelei.fan at oracle.com  Tue Dec  1 12:49:56 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 1 Dec 2015 20:49:56 +0800
Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable
Message-ID: <565D9774.9000304@oracle.com>

Hi,

Please review the fix for JDK-8133070:

   http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/

In (Open)JDK 6, EC cipher suites get supported by Java.  However, there
is no default EC provider in JDK 6 at that time.  In order to support
third part's EC algorithm JCE provider dynamically, it is hard-coded to
check the cipher suite availability dynamically for EC algorithms in
SunJSSE provider.

Here is an example update in CipherSuite.java for the checking:

  -   static final boolean DYNAMIC_AVAILABILITY = false;
  +   static final boolean DYNAMIC_AVAILABILITY = true;

The dynamically checking impacts the performance significantly as:
1. the check of the availability is expensive as it involves crypto
operations.
2. a cache is used to maintain the availability of bulk ciphers in order
to mitigate the #1 performance impact.  However, access and update to
the cache need to be synchronized.
3. in order to support dynamically checking, the cache may be cleared if
a particular cipher is not found or a new SSLContext is generated. As
bring the performance impact of #1 back again.

Later, AEAD algorithm is defined by Java.  The same mechanism is used to
support AEAD ciphers.

Now, EC and GCM algorithms are supported in JDK crypto providers. The
hard-coded checking can get improved.  This fix updates:
1. remove the dynamically checking of cipher suite availability.
2. remove the cipher suite availability cache accordingly (need no
synchronization accordingly)
3. other updates that impact by the availability checking.

The performance improvement is tested with the following simple case.
Run the following code 1000, 2000, 3000 times in single thread mode and
measure the millisecond for each:

---------
String[] cipherSuites =
        {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"};
for (int i = 0; i < loops; i++) {  // loops: 1000, 2000, 3000
    SSLEngine engine = SSLContext.getDefault().createSSLEngine();
    engine.getEnabledCipherSuites();
    engine.getSupportedCipherSuites();
}
---------

The milliseconds for each test case (less is better) look like:

    loops   |  old    |  fixed
   ---------+---------+----------
   1000     |  2736   |  735
   ---------+---------+----------
   2000     |  3718   |  746
   ---------+---------+----------
   3000     |  4750   |  765
   ---------+---------+----------

This fix improves the performance.

The existing regression testing get passed.  No new regression test is
planned as this is a performance enhancement fix.

Thanks,
Xuelei

From sean.coffey at oracle.com  Tue Dec  1 13:53:42 2015
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 1 Dec 2015 13:53:42 +0000
Subject: Request for review: 8144093: JEP 244/8051498 - TLS
	Application-Layer Protocol Negotiation Extension
In-Reply-To: <565CFD93.6030807@oracle.com>
References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
	<565BED18.70202@oracle.com>
	<A1B7D72B-9109-48D4-B842-0EC8D37342AF@oracle.com>
	<565CFD93.6030807@oracle.com>
Message-ID: <565DA666.6040005@oracle.com>

Hey Vinnie,

question on SSLParameters.setApplicationProtocols(String[] protocols) method

What happens if you pass an empty array into this method. Shouldn't it 
throw an IllegalArgumentException  ?

====

In ALPNExtension.java :
> +            if (listLength < 2 || listLength + 2 != len) {
> +                throw new SSLProtocolException(
> +                    "Invalid " + type + " extension: incorrect list length");
Can you print the listLength value in exception message ?

> +            throw new SSLProtocolException(
> +                "Invalid " + type + " extension: too short");
Can you print the len value here ?

> +        if (remaining != 0) {
> +            throw new SSLProtocolException(
> +                "Invalid " + type + " extension: extra data");
Can you print remaining value here ?

Regards,
Sean.

On 01/12/2015 01:53, Xuelei Fan wrote:
> Looks fine to me.  Thanks for the update.
>
> Xuelei
>
> On 12/1/2015 7:08 AM, Vincent Ryan wrote:
>> Thanks for your review. Comments in-line.
>>
>>> On 30 Nov 2015, at 06:30, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>
>>> Looks fine to me.  Just a few minor comments.
>>>
>>> ServerHandshaker.java
>>> =====================
>>> There is a typo of the first line.
>>> - /* Copyright (c) 1996, 2015, ...
>>> + /*
>>> +  * Copyright (c) 1996, 2015 ?
>>>
>> Done.
>>
>>> line 538-546
>>> ------------
>>>    String negotiatedValue = null;
>>>    List<String> protocols = clientHelloALPN.getPeerAPs();
>>>
>>>    for (String ap : localApl) {
>>>        if (protocols.contains(ap)) {
>>>            negotiatedValue = ap;
>>>            break;
>>>        }
>>>    }
>>>
>>> I think the above order prefer the server preference order of
>>> application protocols.  It's OK per Section 3.2 of RFC 7301.
>>>
>>> However RFC 7301 also defines the client preference order.  Looks like
>>> the client preference order is not necessary.  It's a little bit
>>> confusing, and may result in different behaviors for different TLS vendors.
>>>
>>> Maybe, we can add an option to honor server preference order in the future.
>> I added a comment to show that server-preference is used.
>> If necessary I think we can add support for controlling this via a property, later.
>>
>>
>>> ALPNExtension.java
>>> ==================
>>> 96    listLength = s.getInt16(); // list length
>>>
>>> The code would throws SSLException if the remaining input is not
>>> sufficient.  I was wondering, SSLProtocolException may be more suitable
>>> here.  May be nice to check the "len" argument value if sufficient for
>>> the list length.  Otherwise, a SSLProtocolException would be thrown.
>>>
>>>     if (len >= 2) {
>>>         listLength = s.getInt16(); // list length
>>>         ...
>>>     } else {
>>>         throw new SSLProtocolException(...);
>>>     }
>> I added the exception and more detailed message.
>>
>>> -----------
>>> 104   byte[] bytes = s.getBytes8();
>>> 105   String p =
>>> 106       new String(bytes, StandardCharsets.UTF_8); // app protocol
>>>
>>> Do you want to check that the app protocol cannot be empty?
>>>
>>>      // opaque ProtocolName<1..2^8-1>;  // RFC 7301
>>>      byte[] bytes = s.getBytes8();
>>> +    if (bytes.length == 0) {
>>> +        throw new SSLProtocolException("Empty ...");
>>> +    }
>> Done.
>>
>>
>>> ---------
>>> Personally, I would prefer to use unmodifiableList for the protocolNames
>>> variable.
>> It is accessible only to classes in this package.
>>
>>
>>>
>>> HelloExtensions.java
>>> ====================
>>> line 34-37:
>>> * This file contains all the classes relevant to TLS Extensions for the
>>> * ClientHello and ServerHello messages. The extension mechanism and
>>> * several extensions are defined in RFC 3546. Additional extensions are
>>> * defined in the ECC RFC 4492.The ALPN extension is defined in RFC7301.
>>>
>>> I may put the "Additional extensions ..." at the end.  BTW, as you are
>>> here already, would you mind update RFC 3546 to RFC 6066?  RFC 6066 is
>>> the newest revision of RFC 3546.
>> I concatenated the final sentence.
>>
>>
>>> * This file contains all the classes relevant to TLS Extensions for the
>>> * ClientHello and ServerHello messages. The extension mechanism and
>>> * several extensions are defined in RFC 6066. The ALPN extension is
>>> * defined in RFC 7301.  Additional extensions are defined in the ECC
>>> * RFC 4492.
>>>
>>> SSLEngineImpl.java
>>> ==================
>>>
>>> line 1411-1412:
>>> private Ciphertext writeRecord(ByteBuffer[] appData,
>>>     int offset, int length, ByteBuffer netData) throws IOException {
>>>     ...
>>>   if (...) {
>>>     ...
>>>     // set connection ALPN value
>>>     applicationProtocol =
>>>         handshaker.getHandshakeApplicationProtocol();
>>>     ...
>>>   }
>>> }
>>>
>>> Is it redundant to set applicationProtocol here.  I was wondering, the
>>> value should set in the processInputRecord() method.
>> My understanding is the the wrapping is performed here and the unwrapping
>> performed in processInputRecord(). Isn?t the assignment required in both places?
>>
>>
>>
>>> Cheers,
>>> Xuelei
>>>
>>> On 11/30/2015 8:08 AM, Vincent Ryan wrote:
>>>> Hello,
>>>>
>>>> Following on from Brad?s recent email, here is the full webrev of the
>>>> API and the implementation classes for ALPN:
>>>>   http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/
>>>>
>>>> In adds the implementation classes (sun/security/ssl) to the public API
>>>> classes (javax/net/ssl) which have already been agreed.
>>>> Some basic tests (test/javax/net/ssl) are also included.
>>>>
>>>> Please send any code review comments by close-of-business on Tuesday 1
>>>> December.
>>>> Thanks.


From sean.mullan at oracle.com  Tue Dec  1 14:06:16 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 1 Dec 2015 09:06:16 -0500
Subject: RFR 8141457: keytool default cert fingerprint algorithm should be
	SHA-256
In-Reply-To: <FCE91530-EB7A-4970-B2DB-1D6F3F81D043@oracle.com>
References: <E9187F91-585F-4892-989B-AA4D1F93CB3D@oracle.com>
	<565454D3.4050007@oracle.com>
	<FCE91530-EB7A-4970-B2DB-1D6F3F81D043@oracle.com>
Message-ID: <565DA958.9020506@oracle.com>

On 11/25/2015 09:39 PM, Wang Weijun wrote:
> Updated at http://cr.openjdk.java.net/~weijun/8141457/webrev.01/.
>
> I was lazy last time.

Looks good.

--Sean

>
> --Max
>
>> On Nov 24, 2015, at 8:15 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> Looks good - although you could replace the MD5 fingerprints with the SHA256 fingerprints in the test files for some additional testing.
>>
>> --Sean
>>
>> On 11/23/2015 08:00 PM, Wang Weijun wrote:
>>> Hi All
>>>
>>> Please review a code change at
>>>
>>>     http://cr.openjdk.java.net/~weijun/8141457/webrev.00/
>>>
>>> SHA-256 is now the default fingerprint algorithm, and MD5 is removed in the full list.
>>>
>>> No new regression test, I consider the change trivial. If you think one is better, I'll add it.
>>>
>>> Thanks
>>> Max
>>>
>

From sean.mullan at oracle.com  Tue Dec  1 14:34:21 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 1 Dec 2015 09:34:21 -0500
Subject: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not
	complete
In-Reply-To: <4D579A3C-316E-4C5F-A45E-6B209AE1D564@oracle.com>
References: <DD0A4ABD-3176-4276-BFD4-86512F20E88C@oracle.com>
	<58FCE11C-3FCF-4CF9-BD85-4A1DF4B724F9@oracle.com>
	<5654458D.1080705@oracle.com> <5655CE04.2000004@oracle.com>
	<4D579A3C-316E-4C5F-A45E-6B209AE1D564@oracle.com>
Message-ID: <565DAFED.90408@oracle.com>

Looks good, although the location of the new test (test/sun/security) 
doesn't seem right. A new directory named test/conf/security would 
probably make the most sense, but I think putting it in the new 
test/jdk/security directory is also a better option.

--Sean

On 11/25/2015 09:36 PM, Wang Weijun wrote:
>
>> On Nov 25, 2015, at 11:04 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> The fix looks fine to me. For testing, can you create a test that uses a custom java.security file with "#ifndef solaris-sparc" in it, and check whether the property is used or not depending on what system is being tested?
>
> The tool is inside another repo. I can still write one though.
>
> Please take a look at the updated webrev:
>
>     http://cr.openjdk.java.net/~weijun/8141690/webrev.01/
>
> I also fixed a bug inside MakeJavaSecurity.java. If package.access or package.definition happens to be the last property, an NPE will be thrown.
>
> Thanks
> Max
>
>>
>> --Sean
>>>>>
>>>>>    http://cr.openjdk.java.net/~weijun/8141690/webrev.00/
>>>>>
>

From marc.boorshtein at tremolosecurity.com  Tue Dec  1 16:23:56 2015
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Tue, 1 Dec 2015 11:23:56 -0500
Subject: S4U2Self and OpenJDK 8
In-Reply-To: <7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com>
References: <CAH2S7UA8eGRCUWEpC8igOauTQ6fadxVUdE100_jWdAfJ2RhGxg@mail.gmail.com>
	<BA9565CB-0267-412A-8925-A9BDC47D4993@oracle.com>
	<CAH2S7UBL4AP==P=TT38XNVpQ7WJvhrri=y2A0sZiPS7Kd+kf1Q@mail.gmail.com>
	<7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com>
Message-ID: <CAH2S7UB4X1Be9V3--1YeEvRRJJuH66PgA8Nw8Mzk3P+ETzZFOA@mail.gmail.com>

Hmm, I think you are right.  Here's what the Microsoft docs say "The
S4U2proxy extension requires that the service ticket to the first
service has the forwardable flag set (see Service 1 in the figure
specifying Kerberos delegation with forwarded TGT, section 1.3.3).
This ticket can be obtained through an S4U2self protocol exchange.".
I'll followup with the folks at RedHat and FreeIPA.

Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
(703) 828-4902


On Mon, Nov 30, 2015 at 10:01 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> It is my understanding that if the S4U2self ticket is not forwardable then it cannot be used in a S4U2proxy request. That's we just threw an exception. Am I wrong? Or you don't intend to use it this way?
>
> --Max
>

From sean.mullan at oracle.com  Tue Dec  1 17:03:22 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 1 Dec 2015 12:03:22 -0500
Subject: openjdk 8 & 2048 bit DSA xml signing
In-Reply-To: <CAGafC-C15n8FMQSuQENv17bwAuiBKO8Y5F1c7DG=EGaU4kbbFw@mail.gmail.com>
References: <CAGafC-C15n8FMQSuQENv17bwAuiBKO8Y5F1c7DG=EGaU4kbbFw@mail.gmail.com>
Message-ID: <565DD2DA.4020503@oracle.com>

I opened a backport for this issue for a JDK 8 update release, see: 
https://bugs.openjdk.java.net/browse/JDK-8143905

The backport should be relatively straightforward, but I am not sure yet 
when or what release the fix will appear in.

--Sean

On 11/19/2015 04:53 AM, Basabendra Misra wrote:
> Hi,
>
> It seems there is a fix to support 2048 bit DSA signing in upcoming
> openjdk 9 release. However , could anyone please guide me what would be
> the safest way to incorporate the same in openjdk 8?
> Would really appreciate any help. We're stuck because some CA not
> offering 1024 bit DSA keys anymore.
>
> Thanks & regards,
> Basabendra Misra
> +91-9830527802

From marc.boorshtein at tremolosecurity.com  Tue Dec  1 17:59:04 2015
From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein)
Date: Tue, 1 Dec 2015 12:59:04 -0500
Subject: S4U2Self and OpenJDK 8
In-Reply-To: <CAH2S7UB4X1Be9V3--1YeEvRRJJuH66PgA8Nw8Mzk3P+ETzZFOA@mail.gmail.com>
References: <CAH2S7UA8eGRCUWEpC8igOauTQ6fadxVUdE100_jWdAfJ2RhGxg@mail.gmail.com>
	<BA9565CB-0267-412A-8925-A9BDC47D4993@oracle.com>
	<CAH2S7UBL4AP==P=TT38XNVpQ7WJvhrri=y2A0sZiPS7Kd+kf1Q@mail.gmail.com>
	<7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com>
	<CAH2S7UB4X1Be9V3--1YeEvRRJJuH66PgA8Nw8Mzk3P+ETzZFOA@mail.gmail.com>
Message-ID: <CAH2S7UC+3vb7ZZWh_f6=5n-jKkGSc48gzUSY75djWDSJD3+Y6Q@mail.gmail.com>

Max,

Closing the loop on this.  It turns out that there was an extra step
needed to get the user in freeipa setup as a delegate (the
documentation was written for S4U2Proxy, not S4U2Self).  Once I set
that flag delegation started working for BOTH Java 8 and Java 9.

Thanks again.
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein at tremolosecurity.com
(703) 828-4902


On Tue, Dec 1, 2015 at 11:23 AM, Marc Boorshtein
<marc.boorshtein at tremolosecurity.com> wrote:
> Hmm, I think you are right.  Here's what the Microsoft docs say "The
> S4U2proxy extension requires that the service ticket to the first
> service has the forwardable flag set (see Service 1 in the figure
> specifying Kerberos delegation with forwarded TGT, section 1.3.3).
> This ticket can be obtained through an S4U2self protocol exchange.".
> I'll followup with the folks at RedHat and FreeIPA.
>
> Thanks
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
> (703) 828-4902
>
>
> On Mon, Nov 30, 2015 at 10:01 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>> It is my understanding that if the S4U2self ticket is not forwardable then it cannot be used in a S4U2proxy request. That's we just threw an exception. Am I wrong? Or you don't intend to use it this way?
>>
>> --Max
>>

From vincent.x.ryan at oracle.com  Tue Dec  1 21:20:59 2015
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Tue, 1 Dec 2015 21:20:59 +0000
Subject: Request for review: 8144093: JEP 244/8051498 - TLS
	Application-Layer Protocol Negotiation Extension
In-Reply-To: <565CF8BF.50200@oracle.com>
References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
	<565CF8BF.50200@oracle.com>
Message-ID: <0DD900B1-69CC-4463-8DBD-D6CB88FFB2A8@oracle.com>

Thanks for the additional review comments.
Responses in-line below.

Updated webrev:
  http://cr.openjdk.java.net/~vinnie/8144093/webrev.02/


> On 1 Dec 2015, at 01:32, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
> 
> 
> On 11/29/2015 4:08 PM, Vincent Ryan wrote:
> 
> > Following on from Brad?s recent email, here is the full webrev of the
> > API and the implementation classes for ALPN:
> > http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/
> >
> > In adds the implementation classes (sun/security/ssl) to the public API
> > classes (javax/net/ssl) which have already been agreed.
> > Some basic tests (test/javax/net/ssl) are also included.
> 
> SSLEngineAlpnTest.java
> ======================
> 
> 333:  A minor comment here. I think you should test NONE like this:
> 
>    if (ap == null) {
>        throw new Exception(
>            "Handshake was completed but null was received");
>    }
>    if (expectedAP.equals("NONE")) {
>        if (!ap.isEmpty()) {
>            throw new Exception();
>        } else {
>            System.out.println("No ALPN value negotiated, as expected");
>        }
>    } else if (!expectedAP.equals(ap)) {
>        throw new Exception(expectedAP +
>            " ALPN value not available on negotiated connection");
>    }

Done.

> 
> BTW, the indentions here at 331/332/334 are off.  The rest are all ok.

Corrected.


> 
> We had also talked privately about testing getHandshakeApplicationProtocol(), but I don't see it here.  Let me know if you didn't understand my comments about adding a X509ExtendedKeyManager (or X509ExtendedTrustManager), or else please file a RFE for it if it won't be ready for the initial integration.

I?ll file an RFE for that.


> 
> 298:  This test is not actually calling into checkResult on the server side.  Ooops!  You need to check the output of the wrap() before calling unwrap() as it overwrites the serverResult.  You need to put in a similar checkResult() before doing the flip()s.

So checks are required before and after the buffer flips, right?


> 
> 
> SSLSocketAlpnTest.java
> ======================
> 
> Same concern here as above.

Done.

> 
> 
> On 11/29/2015 10:30 PM, Xuelei Fan wrote:
> > line 538-546
> > ------------
> >     String negotiatedValue = null;
> >     List<String> protocols = clientHelloALPN.getPeerAPs();
> >
> >     for (String ap : localApl) {
> >         if (protocols.contains(ap)) {
> >             negotiatedValue = ap;
> >             break;
> >         }
> >     }
> >
> > I think the above order prefer the server preference order of
> > application protocols.  It's OK per Section 3.2 of RFC 7301.
> 
> Correct:
> 
>   In that case, the server SHOULD select the most
>   highly preferred protocol that it supports and that is also
>   advertised by the client.
> 
> > However RFC 7301 also defines the client preference order.  Looks like
> > the client preference order is not necessary.  It's a little bit
> > confusing, and may result in different behaviors for different TLS vendors.
> >
> > Maybe, we can add an option to honor server preference order in the future.
> 
> That was the plan if needed.
> 
> Vincent wrote:
> > If necessary I think we can add support for controlling this via a
> > property, later.
> 
> Or a new API (when possible):  a new "preferPeerOrder" method and an update to the setApplicationProtocols() text:
> 
>    Unless configured by the preferPeerOrder() method, the first
>    matched value becomes the negotiated value.
> 
> On 11/30/2015 3:08 PM, Vincent Ryan wrote:
> >> SSLEngineImpl.java
> >> >==================
> >> >
> >> >line 1411-1412:
> >> >private Ciphertext writeRecord(ByteBuffer[] appData,
> >> >    int offset, int length, ByteBuffer netData) throws IOException {
> >> >    ...
> >> >  if (...) {
> >> >    ...
> >> >    // set connection ALPN value
> >> >    applicationProtocol =
> >> >        handshaker.getHandshakeApplicationProtocol();
> >> >    ...
> >> >  }
> >> >}
> >> >
> >> >Is it redundant to set applicationProtocol here.  I was wondering, the
> >> >value should set in the processInputRecord() method.
> >
> > My understanding is the the wrapping is performed here and the unwrapping
> > performed in processInputRecord(). Isn?t the assignment required in both places?
> 
> Apparently it's not, I thought it was.  When unwrapping the final inbound Finished message around line 1069, it advances the internal state and writes its own Finished message into the outbound queue, but doesn't actually return hs=FINISHED until the outbound queue is drained.
> 
> I had to step through it to confirm.  So you can remove it.

Done.

> 
> Thanks, Vinnie, looks good.
> 
> Brad
> 


From vincent.x.ryan at oracle.com  Tue Dec  1 21:21:11 2015
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Tue, 1 Dec 2015 21:21:11 +0000
Subject: Request for review: 8144093: JEP 244/8051498 - TLS
	Application-Layer Protocol Negotiation Extension
In-Reply-To: <565DA666.6040005@oracle.com>
References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
	<565BED18.70202@oracle.com>
	<A1B7D72B-9109-48D4-B842-0EC8D37342AF@oracle.com>
	<565CFD93.6030807@oracle.com> <565DA666.6040005@oracle.com>
Message-ID: <D83CB5BA-25CD-46EB-AF19-A0A8E2A59BDA@oracle.com>

Hello Sean,

An empty array is allowed: it means do not use ALPN.
I?ve updated the exception messages to display the offending length in each case.

--- ALPNExtension.java  Tue Dec  1 15:22:02 2015
+++ ALPNExtension.java  Tue Dec  1 14:56:12 2015
@@ -97,11 +97,13 @@
             listLength = s.getInt16(); // list length
             if (listLength < 2 || listLength + 2 != len) {
                 throw new SSLProtocolException(
-                    "Invalid " + type + " extension: incorrect list length");
+                    "Invalid " + type + " extension: incorrect list length " +
+                    "(length=" + listLength + ")");
             }
         } else {
             throw new SSLProtocolException(
-                "Invalid " + type + " extension: too short");
+                "Invalid " + type + " extension: insufficient data " +
+                "(length=" + len + ")");
         }

         int remaining = listLength;
@@ -121,7 +123,8 @@

         if (remaining != 0) {
             throw new SSLProtocolException(
-                "Invalid " + type + " extension: extra data");
+                "Invalid " + type + " extension: extra data " +
+                "(length=" + remaining + ")");
         }
     }




> On 1 Dec 2015, at 13:53, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Hey Vinnie,
> 
> question on SSLParameters.setApplicationProtocols(String[] protocols) method
> 
> What happens if you pass an empty array into this method. Shouldn't it throw an IllegalArgumentException  ?
> 
> ====
> 
> In ALPNExtension.java :
>> +            if (listLength < 2 || listLength + 2 != len) {
>> +                throw new SSLProtocolException(
>> +                    "Invalid " + type + " extension: incorrect list length");
> Can you print the listLength value in exception message ?
> 
>> +            throw new SSLProtocolException(
>> +                "Invalid " + type + " extension: too short");
> Can you print the len value here ?
> 
>> +        if (remaining != 0) {
>> +            throw new SSLProtocolException(
>> +                "Invalid " + type + " extension: extra data");
> Can you print remaining value here ?
> 
> Regards,
> Sean.
> 
> On 01/12/2015 01:53, Xuelei Fan wrote:
>> Looks fine to me.  Thanks for the update.
>> 
>> Xuelei
>> 
>> On 12/1/2015 7:08 AM, Vincent Ryan wrote:
>>> Thanks for your review. Comments in-line.
>>> 
>>>> On 30 Nov 2015, at 06:30, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>> 
>>>> Looks fine to me.  Just a few minor comments.
>>>> 
>>>> ServerHandshaker.java
>>>> =====================
>>>> There is a typo of the first line.
>>>> - /* Copyright (c) 1996, 2015, ...
>>>> + /*
>>>> +  * Copyright (c) 1996, 2015 ?
>>>> 
>>> Done.
>>> 
>>>> line 538-546
>>>> ------------
>>>>   String negotiatedValue = null;
>>>>   List<String> protocols = clientHelloALPN.getPeerAPs();
>>>> 
>>>>   for (String ap : localApl) {
>>>>       if (protocols.contains(ap)) {
>>>>           negotiatedValue = ap;
>>>>           break;
>>>>       }
>>>>   }
>>>> 
>>>> I think the above order prefer the server preference order of
>>>> application protocols.  It's OK per Section 3.2 of RFC 7301.
>>>> 
>>>> However RFC 7301 also defines the client preference order.  Looks like
>>>> the client preference order is not necessary.  It's a little bit
>>>> confusing, and may result in different behaviors for different TLS vendors.
>>>> 
>>>> Maybe, we can add an option to honor server preference order in the future.
>>> I added a comment to show that server-preference is used.
>>> If necessary I think we can add support for controlling this via a property, later.
>>> 
>>> 
>>>> ALPNExtension.java
>>>> ==================
>>>> 96    listLength = s.getInt16(); // list length
>>>> 
>>>> The code would throws SSLException if the remaining input is not
>>>> sufficient.  I was wondering, SSLProtocolException may be more suitable
>>>> here.  May be nice to check the "len" argument value if sufficient for
>>>> the list length.  Otherwise, a SSLProtocolException would be thrown.
>>>> 
>>>>    if (len >= 2) {
>>>>        listLength = s.getInt16(); // list length
>>>>        ...
>>>>    } else {
>>>>        throw new SSLProtocolException(...);
>>>>    }
>>> I added the exception and more detailed message.
>>> 
>>>> -----------
>>>> 104   byte[] bytes = s.getBytes8();
>>>> 105   String p =
>>>> 106       new String(bytes, StandardCharsets.UTF_8); // app protocol
>>>> 
>>>> Do you want to check that the app protocol cannot be empty?
>>>> 
>>>>     // opaque ProtocolName<1..2^8-1>;  // RFC 7301
>>>>     byte[] bytes = s.getBytes8();
>>>> +    if (bytes.length == 0) {
>>>> +        throw new SSLProtocolException("Empty ...");
>>>> +    }
>>> Done.
>>> 
>>> 
>>>> ---------
>>>> Personally, I would prefer to use unmodifiableList for the protocolNames
>>>> variable.
>>> It is accessible only to classes in this package.
>>> 
>>> 
>>>> 
>>>> HelloExtensions.java
>>>> ====================
>>>> line 34-37:
>>>> * This file contains all the classes relevant to TLS Extensions for the
>>>> * ClientHello and ServerHello messages. The extension mechanism and
>>>> * several extensions are defined in RFC 3546. Additional extensions are
>>>> * defined in the ECC RFC 4492.The ALPN extension is defined in RFC7301.
>>>> 
>>>> I may put the "Additional extensions ..." at the end.  BTW, as you are
>>>> here already, would you mind update RFC 3546 to RFC 6066?  RFC 6066 is
>>>> the newest revision of RFC 3546.
>>> I concatenated the final sentence.
>>> 
>>> 
>>>> * This file contains all the classes relevant to TLS Extensions for the
>>>> * ClientHello and ServerHello messages. The extension mechanism and
>>>> * several extensions are defined in RFC 6066. The ALPN extension is
>>>> * defined in RFC 7301.  Additional extensions are defined in the ECC
>>>> * RFC 4492.
>>>> 
>>>> SSLEngineImpl.java
>>>> ==================
>>>> 
>>>> line 1411-1412:
>>>> private Ciphertext writeRecord(ByteBuffer[] appData,
>>>>    int offset, int length, ByteBuffer netData) throws IOException {
>>>>    ...
>>>>  if (...) {
>>>>    ...
>>>>    // set connection ALPN value
>>>>    applicationProtocol =
>>>>        handshaker.getHandshakeApplicationProtocol();
>>>>    ...
>>>>  }
>>>> }
>>>> 
>>>> Is it redundant to set applicationProtocol here.  I was wondering, the
>>>> value should set in the processInputRecord() method.
>>> My understanding is the the wrapping is performed here and the unwrapping
>>> performed in processInputRecord(). Isn?t the assignment required in both places?
>>> 
>>> 
>>> 
>>>> Cheers,
>>>> Xuelei
>>>> 
>>>> On 11/30/2015 8:08 AM, Vincent Ryan wrote:
>>>>> Hello,
>>>>> 
>>>>> Following on from Brad?s recent email, here is the full webrev of the
>>>>> API and the implementation classes for ALPN:
>>>>>  http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/
>>>>> 
>>>>> In adds the implementation classes (sun/security/ssl) to the public API
>>>>> classes (javax/net/ssl) which have already been agreed.
>>>>> Some basic tests (test/javax/net/ssl) are also included.
>>>>> 
>>>>> Please send any code review comments by close-of-business on Tuesday 1
>>>>> December.
>>>>> Thanks.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151201/6a0fbff6/attachment-0001.html>

From anthony.scarpino at oracle.com  Tue Dec  1 23:44:55 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 1 Dec 2015 15:44:55 -0800
Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small
	size requests
Message-ID: <565E30F7.5060307@oracle.com>

Hi all,

I'd like a review of this change.  It improves nextBytes() performance 
by allowing the random buffer to grow and shrink as random data is 
needed and remove the high level synchronization.  Also disable 
SecureRandom for Solaris PKCS11 as it's not as fast as native.

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

Thanks

Tony

From bradford.wetmore at oracle.com  Tue Dec  1 23:58:01 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Tue, 1 Dec 2015 15:58:01 -0800
Subject: Request for review: 8144093: JEP 244/8051498 - TLS
	Application-Layer Protocol Negotiation Extension
In-Reply-To: <0DD900B1-69CC-4463-8DBD-D6CB88FFB2A8@oracle.com>
References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
	<565CF8BF.50200@oracle.com>
	<0DD900B1-69CC-4463-8DBD-D6CB88FFB2A8@oracle.com>
Message-ID: <565E3409.7040503@oracle.com>


>> 298:  This test is not actually calling into checkResult on the server side.  Ooops!  You need to check the output of the wrap() before calling unwrap() as it overwrites the serverResult.  You need to put in a similar checkResult() before doing the flip()s.
>
> So checks are required before and after the buffer flips, right?

Yes.  In a full handshake, the Handshake complete message could be the 
result of an unwrap (client) or wrap (server).

Brad



From bradford.wetmore at oracle.com  Wed Dec  2 00:04:41 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Tue, 1 Dec 2015 16:04:41 -0800
Subject: Request for review: 8144093: JEP 244/8051498 - TLS
	Application-Layer Protocol Negotiation Extension
In-Reply-To: <CAFWmRJ280TRDmF=5iQAwZmmvTAi15h65RoUgcZaOnOkqNfcttQ@mail.gmail.com>
References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com>
	<CAFWmRJ280TRDmF=5iQAwZmmvTAi15h65RoUgcZaOnOkqNfcttQ@mail.gmail.com>
Message-ID: <565E3599.3060201@oracle.com>


> I just would like to remind that session resumption is a very
> important use case to support for ALPN.

Understood.  The ALPN value is tied to a handshake, either already 
completed and active (getApplicationProtocol()) or still in progress 
(getHandshakeApplicationProtocol()).  Each handshake results in a 
complete ALPN negotiation.  So a session resumption will always do a 
ALPN negotiation from scratch.

> I have not seen anything related to this review for session resumption.
> Has it been tested ?

The current unit tests don't have resumption, but there should be a RFE 
(if not already) for resumption testing along with some other cases. 
Vinnie is working on these.

> It is still not clear to me what a client and a server have to do to
> support ALPN.

If you want to use the default behavior (server-prioritized list looking 
for a common element), just call SSLParameters.setApplicationProtocols() 
on both sides.

If you want to do very specific protocol/ciphersuite/alpn configuration 
before handshaking, then do the configuration before starting the 
handshake (more details and similar to what you suggested below).  This 
is what was decided back in October when we pulled out the Matcher 
mechanism in v6/v7.  [1]

>  From my understanding a server has to:
>
> * read encrypted bytes into a ByteBuffer

BTW, during the initial handshake on a connection, these are not encrypted.

> * parse the TLS ClientHello frame on its own
> * extract from the ClientHello the TLS Protocol version, the ALPN
> extension, and the ciphers
> * run some logic to determine the AP
> ** if no AP can be chosen, generate a TLS Alert frame on its own to
> close the connection and bail out

I would create a regular SSLContext/SSLEngine/configureALPN and start 
the handshake as usual.  The JSSE implementation will create the TLS 
ALPN Alert when it realizes it doesn't have any ALPN values in common. 
The server then should obtain those bytes from the wrap() and send to 
the peer, as usual.

> * otherwise, an AP/cipher combo has been chosen

Filling in a few more details:

SSLContext.getInstance("protocol"); // returns a context with
                                     // "protocol" and possibly
                                     // other protocols enabled.
SSLEngine ssle = SSLContext.createSSLEngine(...);

Read ClientHello from Socket/SocketChannel/AsynchronousSocketChannel/etc.

Parse ClientHello for requested protocol/alpn/ciphersuites

choose protocol/alpn/ciphersuite value(s)

SSLParameters sslParameters = ssle.getSSLParameters();
sslParameters.setProtocols(protocols);        // possibly just one
     // You could use some non-matching value like
     // "no_application_protocol" if you want to generate the
     // no_application_protocol alert.
sslParameters.setApplicationProtocols(APs);   // possibly just one
sslParameters.setCipherSuites(ciphers)        // possibly just one

sslEngine.setSSLParameters(sslParameters)

reset the ByteBuffer position to the beginning

sslEngine.unwrap()

JDK implementation will re-parse the ClientHello, and use the
sslParameters data during handshake and when generating the
ServerHello.  Any error alerts will be output by the SSLEngine as usual.

sslEngine.wrap()/unwrap() as usual.

> A client has to:
>
> * read encrypted bytes into a ByteBuffer
> * parse a ServerHello frame on its own
> * extract the ALPN extension and the cipher

You could parse this if you want, but wasn't expecting client apps 
would.  See below.

> * run some logic to verify that the AP and the cipher can be used together
> ** if AP and cipher don't match, generate a TLS Alert frame on its own
> to close the connection and bail out.

There is nothing in the ALPN RFC about this situation.  In the HTTP 
spec, if such a situation is negotiated, the application layer waits for 
the handshake completion, examines the state, sends a HTTP2 connection 
error of type INADEQUATE_SECURITY, then closes.

BTW, we would lose the ability to parse plaintext ServerHellos in 
TLSv1.3, as ServerHello is now encrypted.

> * otherwise the AP/cipher combo is ok
> * reset the ByteBuffer position to the beginning
> * pass the ByteBuffer to sslEngine.unwrap()
> * JDK implementation will re-parse the ServerHello and complete the
> TLS handshake
>
> Is that right ?

If you really want to parse it, yes.

> In that scenario, what is the use of
> SSLEngine.getHandshakeApplicationProtocol() ?

When either side needs to determine the selected ALPN value before the 
completion of the handshake, say during X509KeyManager selection or 
X509TrustManager verification.  On the server side, let's say we have 
two possible keys/certs, and we receive a ClientHello.

ClientHello  ->
                   JSSE chooses protocol/ALPN
                   JSSE iterates on ciphersuite
                   iter calls X509KeyManager to find a key
                     X509KM calls setHandshakeApplicationProtocol()
                     to see which protocol/ALPN value was negotiated,
                     uses that for selecting which key to use.
              <- ServerHello

> Also, I don't understand how the above could work for SSLSocket ?
> Can someone write down the steps a client and a server should do to
> actually use ALPN with SSLSocket ?

Server
======

Filing in a few more extra details so it's hopefully clear.

Open a plaintext ServerSocket
Socket socket = serverSocket.accept();
InputStream is = socket.getInputStream();
byte[] ba = is.readFully();

// extract from the ClientHello the TLS Protocol version, the ALPN
// extension, and the ciphers
parseTLSClientHello(ba);

determineProtocolALPNCiphersuites();

SSLContext ctx = \
     SSLContext.getInstance("protocol") // returns a context with
                                    // "protocol" and possibly
                                    // other protocols enabled.

SSLParameters sslParameters = ctx.getDefaultSSLParameters();

SSLParameters sslParameters =
     sslParameters.setProtocols(protocol);
sslParameters.setApplicationProtocols(AP) // just one protocol
sslParameters.setCipherSuites(cipher) // just one cipher

// Overlay the partially consumed InputStream
ByteArrayInputStream bais = new ByteArrayInputStream(ba);

SSLSocket sslSocket = \
     ctx.createSocketFactory(...).createSocket(socket, bais, ...);
sslSocket.setSSLParameters(sslParameters)
sslSocket.startHandshake();

Brad

[1] 
http://mail.openjdk.java.net/pipermail/security-dev/2015-October/012912.html

From weijun.wang at oracle.com  Wed Dec  2 00:51:38 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 2 Dec 2015 08:51:38 +0800
Subject: S4U2Self and OpenJDK 8
In-Reply-To: <CAH2S7UC+3vb7ZZWh_f6=5n-jKkGSc48gzUSY75djWDSJD3+Y6Q@mail.gmail.com>
References: <CAH2S7UA8eGRCUWEpC8igOauTQ6fadxVUdE100_jWdAfJ2RhGxg@mail.gmail.com>
	<BA9565CB-0267-412A-8925-A9BDC47D4993@oracle.com>
	<CAH2S7UBL4AP==P=TT38XNVpQ7WJvhrri=y2A0sZiPS7Kd+kf1Q@mail.gmail.com>
	<7077802C-37AE-4A09-8E5D-551A4B56BE74@oracle.com>
	<CAH2S7UB4X1Be9V3--1YeEvRRJJuH66PgA8Nw8Mzk3P+ETzZFOA@mail.gmail.com>
	<CAH2S7UC+3vb7ZZWh_f6=5n-jKkGSc48gzUSY75djWDSJD3+Y6Q@mail.gmail.com>
Message-ID: <8B5F8DCA-9550-4AA2-BB87-0BF8837DCB18@oracle.com>


> On Dec 2, 2015, at 1:59 AM, Marc Boorshtein <marc.boorshtein at tremolosecurity.com> wrote:
> 
> Max,
> 
> Closing the loop on this.  It turns out that there was an extra step
> needed to get the user in freeipa setup as a delegate (the
> documentation was written for S4U2Proxy, not S4U2Self).  Once I set
> that flag delegation started working for BOTH Java 8 and Java 9.

Nice to hear this. I'll lower the priority of https://bugs.openjdk.java.net/browse/JDK-8144288 then.

--Max

> 
> Thanks again.
> Marc Boorshtein
> CTO Tremolo Security
> marc.boorshtein at tremolosecurity.com
> (703) 828-4902


From xuelei.fan at oracle.com  Wed Dec  2 00:55:00 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 2 Dec 2015 08:55:00 +0800
Subject: Code Review Request 8143298 Test ReadTimeout.java fails intermittently
Message-ID: <565E4164.5040103@oracle.com>

Hi,

Please review the test fix for JDK-8143298:

   http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/

The root cause of the intermittent test failure is still unclear to me.
 I updated the test with more output messages, and clear the resources
in finally blocks.  Hope the update can expose the real cause if it
fails again in the future.

Thanks,
Xuelei

From weijun.wang at oracle.com  Wed Dec  2 01:05:08 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 2 Dec 2015 09:05:08 +0800
Subject: Code Review Request 8143298 Test ReadTimeout.java fails
	intermittently
In-Reply-To: <565E4164.5040103@oracle.com>
References: <565E4164.5040103@oracle.com>
Message-ID: <79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com>

Socket is a Closeable, so you can 

  try (Socket sock = ....) { ... }

If you want more debug messages, why not e.printStackTrace()? Message is enough?

Thanks
Max

> On Dec 2, 2015, at 8:55 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Hi,
> 
> Please review the test fix for JDK-8143298:
> 
>   http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/
> 
> The root cause of the intermittent test failure is still unclear to me.
> I updated the test with more output messages, and clear the resources
> in finally blocks.  Hope the update can expose the real cause if it
> fails again in the future.
> 
> Thanks,
> Xuelei


From xuelei.fan at oracle.com  Wed Dec  2 01:12:33 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 2 Dec 2015 09:12:33 +0800
Subject: Code Review Request 8143298 Test ReadTimeout.java fails
	intermittently
In-Reply-To: <79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com>
References: <565E4164.5040103@oracle.com>
	<79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com>
Message-ID: <565E4581.3050909@oracle.com>

On 12/2/2015 9:05 AM, Wang Weijun wrote:
> Socket is a Closeable, so you can 
> 
>   try (Socket sock = ....) { ... }
> 
Yes.  Better coding.  Updated in the same webrev.

> If you want more debug messages, why not e.printStackTrace()? Message is enough?
> 
I was wondering, the cached connection (which may be closed by server
thread after the client call) may be the cause.  Resource cleanup and
message may be enough.

Thanks,
Xuelei

> Thanks
> Max
> 
>> On Dec 2, 2015, at 8:55 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review the test fix for JDK-8143298:
>>
>>   http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/
>>
>> The root cause of the intermittent test failure is still unclear to me.
>> I updated the test with more output messages, and clear the resources
>> in finally blocks.  Hope the update can expose the real cause if it
>> fails again in the future.
>>
>> Thanks,
>> Xuelei
> 


From weijun.wang at oracle.com  Wed Dec  2 02:20:02 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 2 Dec 2015 10:20:02 +0800
Subject: Code Review Request 8143298 Test ReadTimeout.java fails
	intermittently
In-Reply-To: <565E4581.3050909@oracle.com>
References: <565E4164.5040103@oracle.com>
	<79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com>
	<565E4581.3050909@oracle.com>
Message-ID: <2512595B-7847-46DD-8F8D-C0D4F822AF50@oracle.com>


> On Dec 2, 2015, at 9:12 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 12/2/2015 9:05 AM, Wang Weijun wrote:
>> Socket is a Closeable, so you can 
>> 
>>  try (Socket sock = ....) { ... }
>> 
> Yes.  Better coding.  Updated in the same webrev.

Same sslSocket declared twice. Have you compiled the test?

You can also do the same with sslServerSocket if you like.

> 
>> If you want more debug messages, why not e.printStackTrace()? Message is enough?
>> 
> I was wondering, the cached connection (which may be closed by server
> thread after the client call) may be the cause.  Resource cleanup and
> message may be enough.

Good.

Thanks
Max

> 
> Thanks,
> Xuelei
> 
>> Thanks
>> Max
>> 
>>> On Dec 2, 2015, at 8:55 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Please review the test fix for JDK-8143298:
>>> 
>>>  http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/
>>> 
>>> The root cause of the intermittent test failure is still unclear to me.
>>> I updated the test with more output messages, and clear the resources
>>> in finally blocks.  Hope the update can expose the real cause if it
>>> fails again in the future.
>>> 
>>> Thanks,
>>> Xuelei
>> 
> 


From xuelei.fan at oracle.com  Wed Dec  2 02:48:09 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 2 Dec 2015 10:48:09 +0800
Subject: Code Review Request 8143298 Test ReadTimeout.java fails
	intermittently
In-Reply-To: <2512595B-7847-46DD-8F8D-C0D4F822AF50@oracle.com>
References: <565E4164.5040103@oracle.com>
	<79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com>
	<565E4581.3050909@oracle.com>
	<2512595B-7847-46DD-8F8D-C0D4F822AF50@oracle.com>
Message-ID: <565E5BE9.5000205@oracle.com>

On 12/2/2015 10:20 AM, Wang Weijun wrote:
> 
>> On Dec 2, 2015, at 9:12 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> On 12/2/2015 9:05 AM, Wang Weijun wrote:
>>> Socket is a Closeable, so you can 
>>>
>>>  try (Socket sock = ....) { ... }
>>>
>> Yes.  Better coding.  Updated in the same webrev.
> 
> Same sslSocket declared twice. Have you compiled the test?
> 
Updated.

> You can also do the same with sslServerSocket if you like.
> 
I'll leave it as it is.

Thanks,
Xuelei

>>
>>> If you want more debug messages, why not e.printStackTrace()? Message is enough?
>>>
>> I was wondering, the cached connection (which may be closed by server
>> thread after the client call) may be the cause.  Resource cleanup and
>> message may be enough.
> 
> Good.
> 
> Thanks
> Max
> 
>>
>> Thanks,
>> Xuelei
>>
>>> Thanks
>>> Max
>>>
>>>> On Dec 2, 2015, at 8:55 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review the test fix for JDK-8143298:
>>>>
>>>>  http://cr.openjdk.java.net/~xuelei/8143298/webrev.00/
>>>>
>>>> The root cause of the intermittent test failure is still unclear to me.
>>>> I updated the test with more output messages, and clear the resources
>>>> in finally blocks.  Hope the update can expose the real cause if it
>>>> fails again in the future.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>
>>
> 


From weijun.wang at oracle.com  Wed Dec  2 03:04:40 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 2 Dec 2015 11:04:40 +0800
Subject: Code Review Request 8143298 Test ReadTimeout.java fails
	intermittently
In-Reply-To: <565E5BE9.5000205@oracle.com>
References: <565E4164.5040103@oracle.com>
	<79ED746D-A2B8-4A31-BCFF-B37ED2A2AB05@oracle.com>
	<565E4581.3050909@oracle.com>
	<2512595B-7847-46DD-8F8D-C0D4F822AF50@oracle.com>
	<565E5BE9.5000205@oracle.com>
Message-ID: <0613C25A-575D-491A-82C5-9742096A262D@oracle.com>

Everything looks fine now.

Thanks
Max

> On Dec 2, 2015, at 10:48 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 12/2/2015 10:20 AM, Wang Weijun wrote:
>> 
>>> On Dec 2, 2015, at 9:12 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> 
>>> On 12/2/2015 9:05 AM, Wang Weijun wrote:
>>>> Socket is a Closeable, so you can 
>>>> 
>>>> try (Socket sock = ....) { ... }
>>>> 
>>> Yes.  Better coding.  Updated in the same webrev.
>> 
>> Same sslSocket declared twice. Have you compiled the test?
>> 
> Updated.
> 
>> You can also do the same with sslServerSocket if you like.
>> 
> I'll leave it as it is.
> 
> Thanks,
> Xuelei


From chris.hegarty at oracle.com  Wed Dec  2 12:08:38 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 2 Dec 2015 12:08:38 +0000
Subject: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder
	and BASE64Decoder
Message-ID: <565EDF46.2080602@oracle.com>

The regression tests in the jdk should be updated, where possible, to 
use java.util.Base64.

http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/

-Chris.

From paul.sandoz at oracle.com  Wed Dec  2 13:42:14 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 2 Dec 2015 14:42:14 +0100
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <565EDF46.2080602@oracle.com>
References: <565EDF46.2080602@oracle.com>
Message-ID: <FC01481A-3C58-4D17-910F-6B1EBDAAB554@oracle.com>


> On 2 Dec 2015, at 13:08, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> The regression tests in the jdk should be updated, where possible, to use java.util.Base64.
> 
> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
> 

+1

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151202/424215a8/signature.asc>

From Alan.Bateman at oracle.com  Wed Dec  2 14:03:01 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 2 Dec 2015 14:03:01 +0000
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <565EDF46.2080602@oracle.com>
References: <565EDF46.2080602@oracle.com>
Message-ID: <565EFA15.3050504@oracle.com>



On 02/12/2015 12:08, Chris Hegarty wrote:
> The regression tests in the jdk should be updated, where possible, to 
> use java.util.Base64.
>
> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
Should S11N be updated to serialize with JDK 8 so that the core 
reflection code isn't needed?

-Alan

From chris.hegarty at oracle.com  Wed Dec  2 14:15:10 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 2 Dec 2015 14:15:10 +0000
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <565EFA15.3050504@oracle.com>
References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com>
Message-ID: <565EFCEE.6010501@oracle.com>

On 02/12/15 14:03, Alan Bateman wrote:
>
> On 02/12/2015 12:08, Chris Hegarty wrote:
>> The regression tests in the jdk should be updated, where possible, to
>> use java.util.Base64.
>>
>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
> Should S11N be updated to serialize with JDK 8 so that the core
> reflection code isn't needed?

This is certainly possible and would make the test simpler, but
I followed the comments in the test ( it needs to be runnable on
older JDKs ).  I think this is a reasonable requirement since the
test contains bytes array that were generated on older JDKs. Of
course, the test could contain the older JDK code commented out.
If someone really wants to run it with 1.6, then they just make
the simple edits.

I'm ok with any of these solutions, or just removing the possibility
of running on older JDKs.

-Chris.

From weijun.wang at oracle.com  Wed Dec  2 14:36:59 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 2 Dec 2015 22:36:59 +0800
Subject: RFR 8058778: New APIs for some keytool functions
Message-ID: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>

Hi All

This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do.

code changes:

  http://cr.openjdk.java.net/~weijun/8058778/webrev.04
  http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/

spec:

  http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html

You will be able to 

 KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
 kpg.initialize(2048);
 KeyPair ca = kpg.generateKeyPair();
 KeyPair user = kpg.generateKeyPair();

 X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
      .subject(new X500Principal("CN=ca"))
      .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
      .addExtension("BasicConstraints", "", true)
      .signatureAlgorithm("SHA256withRSA")
      .selfSign();

 byte[] request = X509CertificateBuilder.fromKeyPair(user)
      .subject(new X500Principal("CN=user"))
      .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
      .request();

 X509Certificate userCert = X509CertificateBuilder.asCA(
          ca.getPrivate(), caCert)
      .signatureAlgorithm("SHA256withRSA")
      .honorExtensions("all")
      .sign(request);

Thanks
Max


From weijun.wang at oracle.com  Wed Dec  2 14:52:32 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 2 Dec 2015 22:52:32 +0800
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <565EFCEE.6010501@oracle.com>
References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com>
	<565EFCEE.6010501@oracle.com>
Message-ID: <CC67F1EE-07CA-4789-B5AC-E93A0B354C07@oracle.com>

My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix.

Thanks
Max

> On Dec 2, 2015, at 10:15 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> On 02/12/15 14:03, Alan Bateman wrote:
>> 
>> On 02/12/2015 12:08, Chris Hegarty wrote:
>>> The regression tests in the jdk should be updated, where possible, to
>>> use java.util.Base64.
>>> 
>>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
>> Should S11N be updated to serialize with JDK 8 so that the core
>> reflection code isn't needed?
> 
> This is certainly possible and would make the test simpler, but
> I followed the comments in the test ( it needs to be runnable on
> older JDKs ).  I think this is a reasonable requirement since the
> test contains bytes array that were generated on older JDKs. Of
> course, the test could contain the older JDK code commented out.
> If someone really wants to run it with 1.6, then they just make
> the simple edits.
> 
> I'm ok with any of these solutions, or just removing the possibility
> of running on older JDKs.
> 
> -Chris.


From chris.hegarty at oracle.com  Wed Dec  2 15:03:42 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 2 Dec 2015 15:03:42 +0000
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <565EFCEE.6010501@oracle.com>
References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com>
	<565EFCEE.6010501@oracle.com>
Message-ID: <565F084E.505@oracle.com>

Updated to remove all use of reflection. If someone really
wants to run S11N on an older JDK, then it is a simple
edit to uncomment/comment 3 lines.

http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/

-Chris.

On 02/12/15 14:15, Chris Hegarty wrote:
> On 02/12/15 14:03, Alan Bateman wrote:
>>
>> On 02/12/2015 12:08, Chris Hegarty wrote:
>>> The regression tests in the jdk should be updated, where possible, to
>>> use java.util.Base64.
>>>
>>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
>> Should S11N be updated to serialize with JDK 8 so that the core
>> reflection code isn't needed?
>
> This is certainly possible and would make the test simpler, but
> I followed the comments in the test ( it needs to be runnable on
> older JDKs ).  I think this is a reasonable requirement since the
> test contains bytes array that were generated on older JDKs. Of
> course, the test could contain the older JDK code commented out.
> If someone really wants to run it with 1.6, then they just make
> the simple edits.
>
> I'm ok with any of these solutions, or just removing the possibility
> of running on older JDKs.
>
> -Chris.

From weijun.wang at oracle.com  Wed Dec  2 15:13:47 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 2 Dec 2015 23:13:47 +0800
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <CC67F1EE-07CA-4789-B5AC-E93A0B354C07@oracle.com>
References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com>
	<565EFCEE.6010501@oracle.com>
	<CC67F1EE-07CA-4789-B5AC-E93A0B354C07@oracle.com>
Message-ID: <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com>


> On Dec 2, 2015, at 10:52 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix.
> 
> Thanks
> Max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S11N.java
Type: application/octet-stream
Size: 14102 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151202/b3a2899f/S11N.java>

From chris.hegarty at oracle.com  Wed Dec  2 15:26:07 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 2 Dec 2015 15:26:07 +0000
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com>
References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com>
	<565EFCEE.6010501@oracle.com>
	<CC67F1EE-07CA-4789-B5AC-E93A0B354C07@oracle.com>
	<85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com>
Message-ID: <565F0D8F.2070103@oracle.com>

Thanks Max,

I'm ok with this version, if you are. I'll include it in the final push.

-Chris.

On 02/12/15 15:13, Wang Weijun wrote:
>
>> On Dec 2, 2015, at 10:52 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>
>> My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix.
>>
>> Thanks
>> Max

From weijun.wang at oracle.com  Wed Dec  2 15:34:02 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 2 Dec 2015 23:34:02 +0800
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <565F0D8F.2070103@oracle.com>
References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com>
	<565EFCEE.6010501@oracle.com>
	<CC67F1EE-07CA-4789-B5AC-E93A0B354C07@oracle.com>
	<85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com>
	<565F0D8F.2070103@oracle.com>
Message-ID: <EA533FA4-751F-4567-AB7A-CEBA853FFBEB@oracle.com>


> On Dec 2, 2015, at 11:26 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> Thanks Max,
> 
> I'm ok with this version, if you are. I'll include it in the final push.

Please.

--Max

> 
> -Chris.
> 
> On 02/12/15 15:13, Wang Weijun wrote:
>> 
>>> On Dec 2, 2015, at 10:52 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>> 
>>> My fault to use an internal class. I should have simply used the hex encoding. Please wait a while and I'll send you a fix.
>>> 
>>> Thanks
>>> Max


From Alan.Bateman at oracle.com  Wed Dec  2 17:04:58 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 2 Dec 2015 17:04:58 +0000
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <565F0D8F.2070103@oracle.com>
References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com>
	<565EFCEE.6010501@oracle.com>
	<CC67F1EE-07CA-4789-B5AC-E93A0B354C07@oracle.com>
	<85738A51-561F-43E1-B805-5FE8D892C7F5@oracle.com>
	<565F0D8F.2070103@oracle.com>
Message-ID: <565F24BA.3000905@oracle.com>



On 02/12/2015 15:26, Chris Hegarty wrote:
> Thanks Max,
>
> I'm ok with this version, if you are. I'll include it in the final push.
>
This version looks okay to me too.

-Alan.

From mandy.chung at oracle.com  Wed Dec  2 18:38:11 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 2 Dec 2015 10:38:11 -0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
Message-ID: <BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>

Hi Max,

Is there any reason why this X509CertificateBuilder can?t be Java SE API?  Have you considered defining this builder API in java.security.cert.X509Certificate.Builder?

Mandy

> On Dec 2, 2015, at 6:36 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> Hi All
> 
> This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do.
> 
> code changes:
> 
>  http://cr.openjdk.java.net/~weijun/8058778/webrev.04
>  http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
> 
> spec:
> 
>  http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
> 
> You will be able to 
> 
> KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> kpg.initialize(2048);
> KeyPair ca = kpg.generateKeyPair();
> KeyPair user = kpg.generateKeyPair();
> 
> X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
>      .subject(new X500Principal("CN=ca"))
>      .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
>      .addExtension("BasicConstraints", "", true)
>      .signatureAlgorithm("SHA256withRSA")
>      .selfSign();
> 
> byte[] request = X509CertificateBuilder.fromKeyPair(user)
>      .subject(new X500Principal("CN=user"))
>      .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
>      .request();
> 
> X509Certificate userCert = X509CertificateBuilder.asCA(
>          ca.getPrivate(), caCert)
>      .signatureAlgorithm("SHA256withRSA")
>      .honorExtensions("all")
>      .sign(request);
> 
> Thanks
> Max
> 


From larry.mccay at gmail.com  Wed Dec  2 20:11:54 2015
From: larry.mccay at gmail.com (larry mccay)
Date: Wed, 2 Dec 2015 15:11:54 -0500
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
Message-ID: <CACRbFyjU_EQUn8p+1Rw64Q+2OzRta-084os=xjn0TZ_E3BB6Kg@mail.gmail.com>

Hi Max -

Happy to see this enhancement - it would be great if it made its way into
SE and other JVM implementations as a result!

If not, what would the added dependency be for consuming applications?

thanks,

--larry

On Wed, Dec 2, 2015 at 1:38 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> Hi Max,
>
> Is there any reason why this X509CertificateBuilder can?t be Java SE API?
> Have you considered defining this builder API in
> java.security.cert.X509Certificate.Builder?
>
> Mandy
>
> > On Dec 2, 2015, at 6:36 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> >
> > Hi All
> >
> > This enhancement creates a new jdk.security.cert.X509CertificateBuilder
> API that does what keytool -genkeypair/-certreq/-gencert can do.
> >
> > code changes:
> >
> >  http://cr.openjdk.java.net/~weijun/8058778/webrev.04
> >  http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
> >
> > spec:
> >
> >
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
> >
> > You will be able to
> >
> > KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> > kpg.initialize(2048);
> > KeyPair ca = kpg.generateKeyPair();
> > KeyPair user = kpg.generateKeyPair();
> >
> > X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
> >      .subject(new X500Principal("CN=ca"))
> >      .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
> >      .addExtension("BasicConstraints", "", true)
> >      .signatureAlgorithm("SHA256withRSA")
> >      .selfSign();
> >
> > byte[] request = X509CertificateBuilder.fromKeyPair(user)
> >      .subject(new X500Principal("CN=user"))
> >      .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
> >      .request();
> >
> > X509Certificate userCert = X509CertificateBuilder.asCA(
> >          ca.getPrivate(), caCert)
> >      .signatureAlgorithm("SHA256withRSA")
> >      .honorExtensions("all")
> >      .sign(request);
> >
> > Thanks
> > Max
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151202/20f7258b/attachment.html>

From weijun.wang at oracle.com  Thu Dec  3 01:25:07 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 3 Dec 2015 09:25:07 +0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
Message-ID: <A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>


> On Dec 3, 2015, at 2:38 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hi Max,
> 
> Is there any reason why this X509CertificateBuilder can?t be Java SE API?  

Well, not much.

When we first design the new API, it was meant to be a quick alternative to sun.security.tools.keytool.Main since that class will be invisible after jigsaw. So it's just a simple utility class and not fine polished.

One unpolished is the certificate request. It's now just a byte[]. We might need a base class CertificateRequest and a child X509CertificateRequest and some getters.

Another is the addExtension() method [1] that takes string values. Although I've tried my best to specify the precise format [1] I still think it's not mature enough as a Java SE API. Maybe I should just keep the addExtension(Extension) one [3] and create static methods in Extension (or shall I create a child named X509Extension) that generates known/unknown extension objects.

Maybe my understanding is biased, but when I am thinking of a Java SE API, it contains multiple classes and a clean structure. On the other hand, a JDK-specific tool can be a huge single class with every method inside (just like keytool itself).

> Have you considered defining this builder API in java.security.cert.X509Certificate.Builder?

That sounds like a good place.

Thanks
Max

[1] http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.lang.String-java.lang.String-boolean-

[2] http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#extensions

[3] http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.security.cert.Extension-

> 
> Mandy
> 
>> On Dec 2, 2015, at 6:36 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
>> 
>> Hi All
>> 
>> This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do.
>> 
>> code changes:
>> 
>> http://cr.openjdk.java.net/~weijun/8058778/webrev.04
>> http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
>> 
>> spec:
>> 
>> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
>> 
>> You will be able to 
>> 
>> KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
>> kpg.initialize(2048);
>> KeyPair ca = kpg.generateKeyPair();
>> KeyPair user = kpg.generateKeyPair();
>> 
>> X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
>>     .subject(new X500Principal("CN=ca"))
>>     .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
>>     .addExtension("BasicConstraints", "", true)
>>     .signatureAlgorithm("SHA256withRSA")
>>     .selfSign();
>> 
>> byte[] request = X509CertificateBuilder.fromKeyPair(user)
>>     .subject(new X500Principal("CN=user"))
>>     .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
>>     .request();
>> 
>> X509Certificate userCert = X509CertificateBuilder.asCA(
>>         ca.getPrivate(), caCert)
>>     .signatureAlgorithm("SHA256withRSA")
>>     .honorExtensions("all")
>>     .sign(request);
>> 
>> Thanks
>> Max
>> 
> 


From weijun.wang at oracle.com  Thu Dec  3 01:27:49 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 3 Dec 2015 09:27:49 +0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <CACRbFyjU_EQUn8p+1Rw64Q+2OzRta-084os=xjn0TZ_E3BB6Kg@mail.gmail.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<CACRbFyjU_EQUn8p+1Rw64Q+2OzRta-084os=xjn0TZ_E3BB6Kg@mail.gmail.com>
Message-ID: <6CC644EB-E5EE-48CA-9748-38449B5D48AF@oracle.com>


> On Dec 3, 2015, at 4:11 AM, larry mccay <larry.mccay at gmail.com> wrote:
> 
> Hi Max -
> 
> Happy to see this enhancement - it would be great if it made its way into SE and other JVM implementations as a result!

I replied to Mandy's mail.

> 
> If not, what would the added dependency be for consuming applications?

They will need the jdk.security.cert module. It will be in JRE (I added it into boot.modules) but if you want to create your own runtime you will need to add it using jimage or jlink things. (I am not a module expert but you know it).

Thanks
Max

> 
> thanks,
> 
> --larry
> 
> On Wed, Dec 2, 2015 at 1:38 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> Hi Max,
> 
> Is there any reason why this X509CertificateBuilder can?t be Java SE API?  Have you considered defining this builder API in java.security.cert.X509Certificate.Builder?
> 
> Mandy
> 
> > On Dec 2, 2015, at 6:36 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> >
> > Hi All
> >
> > This enhancement creates a new jdk.security.cert.X509CertificateBuilder API that does what keytool -genkeypair/-certreq/-gencert can do.
> >
> > code changes:
> >
> >  http://cr.openjdk.java.net/~weijun/8058778/webrev.04
> >  http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
> >
> > spec:
> >
> >  http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
> >
> > You will be able to
> >
> > KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> > kpg.initialize(2048);
> > KeyPair ca = kpg.generateKeyPair();
> > KeyPair user = kpg.generateKeyPair();
> >
> > X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
> >      .subject(new X500Principal("CN=ca"))
> >      .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
> >      .addExtension("BasicConstraints", "", true)
> >      .signatureAlgorithm("SHA256withRSA")
> >      .selfSign();
> >
> > byte[] request = X509CertificateBuilder.fromKeyPair(user)
> >      .subject(new X500Principal("CN=user"))
> >      .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
> >      .request();
> >
> > X509Certificate userCert = X509CertificateBuilder.asCA(
> >          ca.getPrivate(), caCert)
> >      .signatureAlgorithm("SHA256withRSA")
> >      .honorExtensions("all")
> >      .sign(request);
> >
> > Thanks
> > Max
> >
> 
> 


From larry.mccay at gmail.com  Thu Dec  3 02:43:10 2015
From: larry.mccay at gmail.com (larry mccay)
Date: Wed, 2 Dec 2015 21:43:10 -0500
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
Message-ID: <CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>

Applications that depend on such APIs are currently jumping through hoops
to provide the same functionality on multiple JVMs.
We have some nasty reflection based code in order to deal with build-time
dependencies.

It really should be formalized and made part of the SE API.
It will be great that I can not worry about the new API going away in
openJDK and oracle - but I'll need to continue to use the reflection
because of IBM.

Baby steps, maybe?

On Wed, Dec 2, 2015 at 8:25 PM, Wang Weijun <weijun.wang at oracle.com> wrote:

>
> > On Dec 3, 2015, at 2:38 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
> >
> > Hi Max,
> >
> > Is there any reason why this X509CertificateBuilder can?t be Java SE API?
>
> Well, not much.
>
> When we first design the new API, it was meant to be a quick alternative
> to sun.security.tools.keytool.Main since that class will be invisible after
> jigsaw. So it's just a simple utility class and not fine polished.
>
> One unpolished is the certificate request. It's now just a byte[]. We
> might need a base class CertificateRequest and a child
> X509CertificateRequest and some getters.
>
> Another is the addExtension() method [1] that takes string values.
> Although I've tried my best to specify the precise format [1] I still think
> it's not mature enough as a Java SE API. Maybe I should just keep the
> addExtension(Extension) one [3] and create static methods in Extension (or
> shall I create a child named X509Extension) that generates known/unknown
> extension objects.
>
> Maybe my understanding is biased, but when I am thinking of a Java SE API,
> it contains multiple classes and a clean structure. On the other hand, a
> JDK-specific tool can be a huge single class with every method inside (just
> like keytool itself).
>
> > Have you considered defining this builder API in
> java.security.cert.X509Certificate.Builder?
>
> That sounds like a good place.
>
> Thanks
> Max
>
> [1]
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.lang.String-java.lang.String-boolean-
>
> [2]
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#extensions
>
> [3]
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html#addExtension-java.security.cert.Extension-
>
> >
> > Mandy
> >
> >> On Dec 2, 2015, at 6:36 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> >>
> >> Hi All
> >>
> >> This enhancement creates a new jdk.security.cert.X509CertificateBuilder
> API that does what keytool -genkeypair/-certreq/-gencert can do.
> >>
> >> code changes:
> >>
> >> http://cr.openjdk.java.net/~weijun/8058778/webrev.04
> >> http://cr.openjdk.java.net/~weijun/8058778/dev/webrev.01/
> >>
> >> spec:
> >>
> >>
> http://cr.openjdk.java.net/~weijun/8058778/webrev.04/ktspec/jdk/security/cert/X509CertificateBuilder.html
> >>
> >> You will be able to
> >>
> >> KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
> >> kpg.initialize(2048);
> >> KeyPair ca = kpg.generateKeyPair();
> >> KeyPair user = kpg.generateKeyPair();
> >>
> >> X509Certificate caCert = X509CertificateBuilder.fromKeyPair(ca)
> >>     .subject(new X500Principal("CN=ca"))
> >>     .validity(Instant.now(), Instant.now().plus(Period.ofDays(3650)))
> >>     .addExtension("BasicConstraints", "", true)
> >>     .signatureAlgorithm("SHA256withRSA")
> >>     .selfSign();
> >>
> >> byte[] request = X509CertificateBuilder.fromKeyPair(user)
> >>     .subject(new X500Principal("CN=user"))
> >>     .addExtension("KeyUsage", "digitalSignature,keyEncipherment", true)
> >>     .request();
> >>
> >> X509Certificate userCert = X509CertificateBuilder.asCA(
> >>         ca.getPrivate(), caCert)
> >>     .signatureAlgorithm("SHA256withRSA")
> >>     .honorExtensions("all")
> >>     .sign(request);
> >>
> >> Thanks
> >> Max
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151202/ff1daedf/attachment-0001.html>

From amy.lu at oracle.com  Thu Dec  3 05:24:34 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 3 Dec 2015 13:24:34 +0800
Subject: RFR [9] 8144480: Remove test dependencies on
	sun.misc.BASE64Encoder and BASE64Decoder
In-Reply-To: <565F084E.505@oracle.com>
References: <565EDF46.2080602@oracle.com> <565EFA15.3050504@oracle.com>
	<565EFCEE.6010501@oracle.com> <565F084E.505@oracle.com>
Message-ID: <565FD212.5070505@oracle.com>

(I'm not a reviewer)

Just a minor question.

jdk/test/sun/misc/Encode/GetBytes.java also use sun.misc.BASE64Encoder 
and BASE64Decoder, but is not included in this fix.
Missed? or justbecause this test will be totally removed soon in a 
separate bugid?

Thanks,
Amy

On 12/2/15 11:03 PM, Chris Hegarty wrote:
> Updated to remove all use of reflection. If someone really
> wants to run S11N on an older JDK, then it is a simple
> edit to uncomment/comment 3 lines.
>
> http://cr.openjdk.java.net/~chegar/Base64-test-updates.01/webrev/
>
> -Chris.
>
> On 02/12/15 14:15, Chris Hegarty wrote:
>> On 02/12/15 14:03, Alan Bateman wrote:
>>>
>>> On 02/12/2015 12:08, Chris Hegarty wrote:
>>>> The regression tests in the jdk should be updated, where possible, to
>>>> use java.util.Base64.
>>>>
>>>> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
>>> Should S11N be updated to serialize with JDK 8 so that the core
>>> reflection code isn't needed?
>>
>> This is certainly possible and would make the test simpler, but
>> I followed the comments in the test ( it needs to be runnable on
>> older JDKs ).  I think this is a reasonable requirement since the
>> test contains bytes array that were generated on older JDKs. Of
>> course, the test could contain the older JDK code commented out.
>> If someone really wants to run it with 1.6, then they just make
>> the simple edits.
>>
>> I'm ok with any of these solutions, or just removing the possibility
>> of running on older JDKs.
>>
>> -Chris.


From weijun.wang at oracle.com  Thu Dec  3 08:31:00 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 3 Dec 2015 16:31:00 +0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
Message-ID: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>

I tried.

It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better.

Extension
---------

Turns out java.security.cert.Extension is already defined for X.509, and there exists an X509Extension class in the same package (which should have been named SomethingHasX509Extensions). In case one day we want to define an extension for non-X.509 certs, I would still like to add static methods into X509Extension that returns an Extension:

  static Extension newExtension(String oid, byte[] content, boolean isCritical);
  static Extension newExtension(String oid, String value, boolean isCritical);

The string-value version will also use oid as name since OID is the only language used in methods of Extension and X509Extension. Constants will be defined in X509Extension for known OIDs, say,

  static final String KEYUSAGE = "2.5.29.16".

The "for example" comment of getExtensionValue() will be gone.

CertificateRequest
------------------

A new CertificateRequest will be added which looks a lot like Certificate, it will have

  String getType();
  byte[] getEncoded();
  PublicKey getPublicKey();

and serialization but no verify(). It is always self-signed so the constructor can verify.

It will have a child X509CertificateRequest which looks a lot like X509Certificate which even implements X509Extension. It will have

  byte[] getCertificationRequestInfo;
  X500Principal getSubjectX500Principal();
  byte[] getSignature();
  String getSigAlgName();
  String getSigAlgOID();
  byte[] getSigAlgParams();
  int getVersion();

(Or maybe not all getSigXXX() methods?)

CertificateFactory should have a new method

  CertificateRequest generateCertificateRequest(InputStream)

and CertificateFactorySpi needs a corresponding engine method throwing UOE.

The X509Factory implementation will read it.


All these sound straightforward, worth doing?

Thanks
Max



From larry.mccay at gmail.com  Thu Dec  3 12:21:21 2015
From: larry.mccay at gmail.com (larry mccay)
Date: Thu, 3 Dec 2015 07:21:21 -0500
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
	<428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
Message-ID: <CACRbFyh3VgrEVXK1-UREp_tjzs2Y1qnWXhkL5TxJDa8QUyyi9w@mail.gmail.com>

+1 :)

On Thu, Dec 3, 2015 at 3:31 AM, Wang Weijun <weijun.wang at oracle.com> wrote:

> I tried.
>
> It's quite easy to move the new X509CertificateBuilder class into
> java.security.cert.X509Certificate as an inner class, but I still want to
> make Extension and CertificateRequest better.
>
> Extension
> ---------
>
> Turns out java.security.cert.Extension is already defined for X.509, and
> there exists an X509Extension class in the same package (which should have
> been named SomethingHasX509Extensions). In case one day we want to define
> an extension for non-X.509 certs, I would still like to add static methods
> into X509Extension that returns an Extension:
>
>   static Extension newExtension(String oid, byte[] content, boolean
> isCritical);
>   static Extension newExtension(String oid, String value, boolean
> isCritical);
>
> The string-value version will also use oid as name since OID is the only
> language used in methods of Extension and X509Extension. Constants will be
> defined in X509Extension for known OIDs, say,
>
>   static final String KEYUSAGE = "2.5.29.16".
>
> The "for example" comment of getExtensionValue() will be gone.
>
> CertificateRequest
> ------------------
>
> A new CertificateRequest will be added which looks a lot like Certificate,
> it will have
>
>   String getType();
>   byte[] getEncoded();
>   PublicKey getPublicKey();
>
> and serialization but no verify(). It is always self-signed so the
> constructor can verify.
>
> It will have a child X509CertificateRequest which looks a lot like
> X509Certificate which even implements X509Extension. It will have
>
>   byte[] getCertificationRequestInfo;
>   X500Principal getSubjectX500Principal();
>   byte[] getSignature();
>   String getSigAlgName();
>   String getSigAlgOID();
>   byte[] getSigAlgParams();
>   int getVersion();
>
> (Or maybe not all getSigXXX() methods?)
>
> CertificateFactory should have a new method
>
>   CertificateRequest generateCertificateRequest(InputStream)
>
> and CertificateFactorySpi needs a corresponding engine method throwing UOE.
>
> The X509Factory implementation will read it.
>
>
> All these sound straightforward, worth doing?
>
> Thanks
> Max
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151203/da224ea8/attachment.html>

From artem.smotrakov at oracle.com  Thu Dec  3 14:10:46 2015
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 3 Dec 2015 17:10:46 +0300
Subject: [9] RFR: 8140470:
	javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java failed
	with java.security.AccessControlException
Message-ID: <56604D66.5050603@oracle.com>

Hello,

Please review this small fix which updates XMLDSigWithSecMgr.java test 
to extend the default security policy instead of override. Please see 
details here:

https://bugs.openjdk.java.net/browse/JDK-8140470?focusedCommentId=13873347&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13873347

The test could use "@run main/othervm/java.security.policy" action, but 
sometimes it may be better to enable a security manager during test 
execution to avoid granting many additional permissions if a test 
requires some setup. I tried to set "java.security.policy" system 
property just before enabling a security manager, and it seems to work fine.

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

Artem

From artem.smotrakov at oracle.com  Thu Dec  3 14:18:20 2015
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Thu, 3 Dec 2015 17:18:20 +0300
Subject: [9] RFR: 8140470:
	javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java failed
	with java.security.AccessControlException
In-Reply-To: <56604D66.5050603@oracle.com>
References: <56604D66.5050603@oracle.com>
Message-ID: <56604F2C.6000401@oracle.com>

I sent a wrong version of webrev, please use the following one

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

Artem

On 12/03/2015 05:10 PM, Artem Smotrakov wrote:
> Hello,
>
> Please review this small fix which updates XMLDSigWithSecMgr.java test 
> to extend the default security policy instead of override. Please see 
> details here:
>
> https://bugs.openjdk.java.net/browse/JDK-8140470?focusedCommentId=13873347&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13873347 
>
>
> The test could use "@run main/othervm/java.security.policy" action, 
> but sometimes it may be better to enable a security manager during 
> test execution to avoid granting many additional permissions if a test 
> requires some setup. I tried to set "java.security.policy" system 
> property just before enabling a security manager, and it seems to work 
> fine.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8140470
> Webrev: http://cr.openjdk.java.net/~asmotrak/8140470/webrev.00/
>
> Artem


From sean.coffey at oracle.com  Thu Dec  3 18:38:55 2015
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 3 Dec 2015 18:38:55 +0000
Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with
	small size requests
In-Reply-To: <565E30F7.5060307@oracle.com>
References: <565E30F7.5060307@oracle.com>
Message-ID: <56608C3F.20600@oracle.com>

Hey Tony,

looks like a fix that could come back to jdk8u-dev at some stage. Thanks 
for taking this one on.

Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. 
Would you agree that JDK-8058455 could be closed out as a duplicate ?

Regards,
Sean.

On 01/12/2015 23:44, Anthony Scarpino wrote:
> Hi all,
>
> I'd like a review of this change.  It improves nextBytes() performance 
> by allowing the random buffer to grow and shrink as random data is 
> needed and remove the high level synchronization. Also disable 
> SecureRandom for Solaris PKCS11 as it's not as fast as native.
>
> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/
>
> Thanks
>
> Tony


From anthony.scarpino at oracle.com  Thu Dec  3 19:04:37 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 3 Dec 2015 11:04:37 -0800
Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with
	small size requests
In-Reply-To: <56608C3F.20600@oracle.com>
References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com>
Message-ID: <972A41CE-5541-4980-AC7F-25A126AD53D1@oracle.com>

Hi Sean,

Yes on both counts. There should be no problem backporting and 8058455 can be a duplicate. 

Tony

> On Dec 3, 2015, at 10:38 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Hey Tony,
> 
> looks like a fix that could come back to jdk8u-dev at some stage. Thanks for taking this one on.
> 
> Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. Would you agree that JDK-8058455 could be closed out as a duplicate ?
> 
> Regards,
> Sean.
> 
>> On 01/12/2015 23:44, Anthony Scarpino wrote:
>> Hi all,
>> 
>> I'd like a review of this change.  It improves nextBytes() performance by allowing the random buffer to grow and shrink as random data is needed and remove the high level synchronization. Also disable SecureRandom for Solaris PKCS11 as it's not as fast as native.
>> 
>> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/
>> 
>> Thanks
>> 
>> Tony
> 

From mstjohns at comcast.net  Thu Dec  3 19:10:50 2015
From: mstjohns at comcast.net (Mike StJohns)
Date: Thu, 3 Dec 2015 14:10:50 -0500
Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with
	small size requests
In-Reply-To: <56608C3F.20600@oracle.com>
References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com>
Message-ID: <566093BA.5020802@comcast.net>

The more I look at this the less I'm comfortable with the change to 
non-synchronized.

In general, there shouldn't be a need for a large amount of random data, 
especially not between multiple threads, so I'm not too sure the 
performance argument holds.

What I do worry about is a provider that's not particularly smart about 
how it does things offering up data and not updating internal pointers 
in a synchronized manner resulting in the possibility of the same 
"random" data being served to multiple requestors.   I think placing the 
synchronization at the glue class may be a better choice than depending 
on each and every provider doing the right thing.

Just a thought - Mike



On 12/3/2015 1:38 PM, Se?n Coffey wrote:
> Hey Tony,
>
> looks like a fix that could come back to jdk8u-dev at some stage. 
> Thanks for taking this one on.
>
> Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. 
> Would you agree that JDK-8058455 could be closed out as a duplicate ?
>
> Regards,
> Sean.
>
> On 01/12/2015 23:44, Anthony Scarpino wrote:
>> Hi all,
>>
>> I'd like a review of this change.  It improves nextBytes() 
>> performance by allowing the random buffer to grow and shrink as 
>> random data is needed and remove the high level synchronization. Also 
>> disable SecureRandom for Solaris PKCS11 as it's not as fast as native.
>>
>> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/
>>
>> Thanks
>>
>> Tony
>
>


From ecki at zusammenkunft.net  Thu Dec  3 22:40:17 2015
From: ecki at zusammenkunft.net (ecki at zusammenkunft.net)
Date: Thu, 3 Dec 2015 23:40:17 +0100
Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with
	small size requests
In-Reply-To: <566093BA.5020802@comcast.net>
References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com>
	<566093BA.5020802@comcast.net>
Message-ID: <86984dc4-d32e-4f02-8878-66086cb4bf88.maildroid@localhost>

Hello,

That buffer sizing/expiring is a bit strange (the dynmic version stranger than the old one), I do not understand the need for it. The requests should not varry so much in size. Just reading something like 64bytes at a time (possibly nonblocking) should be fine. No need to look at the age of that buffer...

A cool implementation would be an actual single periodic refresher thread which does not block reading (until buffer is empty)... but that might change the semantic a bit (and could be better used with the new DRNG api for block-free reseeding).

Bernd

-- 
http://bernd.eckenfels.net

-----Original Message-----
From: Mike StJohns <mstjohns at comcast.net>
To: security-dev at openjdk.java.net
Sent: Do., 03 Dez. 2015 21:22
Subject: Re: RFR: 8098581 SecureRandom.nextBytes() hurts performance with small size requests

The more I look at this the less I'm comfortable with the change to 
non-synchronized.

In general, there shouldn't be a need for a large amount of random data, 
especially not between multiple threads, so I'm not too sure the 
performance argument holds.

What I do worry about is a provider that's not particularly smart about 
how it does things offering up data and not updating internal pointers 
in a synchronized manner resulting in the possibility of the same 
"random" data being served to multiple requestors.   I think placing the 
synchronization at the glue class may be a better choice than depending 
on each and every provider doing the right thing.

Just a thought - Mike



On 12/3/2015 1:38 PM, Se?n Coffey wrote:
> Hey Tony,
>
> looks like a fix that could come back to jdk8u-dev at some stage. 
> Thanks for taking this one on.
>
> Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move. 
> Would you agree that JDK-8058455 could be closed out as a duplicate ?
>
> Regards,
> Sean.
>
> On 01/12/2015 23:44, Anthony Scarpino wrote:
>> Hi all,
>>
>> I'd like a review of this change.  It improves nextBytes() 
>> performance by allowing the random buffer to grow and shrink as 
>> random data is needed and remove the high level synchronization. Also 
>> disable SecureRandom for Solaris PKCS11 as it's not as fast as native.
>>
>> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/
>>
>> Thanks
>>
>> Tony
>
>


From weijun.wang at oracle.com  Fri Dec  4 02:07:41 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 4 Dec 2015 10:07:41 +0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <CACRbFyh3VgrEVXK1-UREp_tjzs2Y1qnWXhkL5TxJDa8QUyyi9w@mail.gmail.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
	<428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
	<CACRbFyh3VgrEVXK1-UREp_tjzs2Y1qnWXhkL5TxJDa8QUyyi9w@mail.gmail.com>
Message-ID: <0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com>

Or if this is too much, we can at least do the X509Extension part. If CertificateRequest is needed one day, we can create a new method Builder.certificateRequest() that returns it and deprecate the current request() method.

Or use certificateRequest() to return byte[] and save request() for the future. :-)

--Max

> On Dec 3, 2015, at 8:21 PM, larry mccay <larry.mccay at gmail.com> wrote:
> 
> +1 :)
> 
> On Thu, Dec 3, 2015 at 3:31 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> I tried.
> 
> It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better.

...

> 
> All these sound straightforward, worth doing?
> 
> Thanks
> Max
> 
> 
> 


From xuelei.fan at oracle.com  Fri Dec  4 14:41:53 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 4 Dec 2015 22:41:53 +0800
Subject: Code Review Request 8141703, Test B6216082.java failed with operation
	timed out exception
Message-ID: <5661A631.4000300@oracle.com>

Hi,

Please review the test update for JDK-8141703:
   http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/

The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java,
need to start a server and proxy, and then make https connection over
them.  It is noticed that the test fails intermittent.

The cause may be that in rush platform, the target proxy and server may
be not ready before the client call.  Maybe not worthy a fix, as the
update need to re-org a lot of code and related classes.

I plan to add the intermittent keyword to the test case, as the code in
the webrev.

Thanks,
Xuelei

From anthony.scarpino at oracle.com  Fri Dec  4 19:14:53 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 4 Dec 2015 11:14:53 -0800
Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with
	small size requests
In-Reply-To: <566093BA.5020802@comcast.net>
References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com>
	<566093BA.5020802@comcast.net>
Message-ID: <5661E62D.2070303@oracle.com>

On 12/03/2015 11:10 AM, Mike StJohns wrote:
> The more I look at this the less I'm comfortable with the change to
> non-synchronized.
>
> In general, there shouldn't be a need for a large amount of random data,
> especially not between multiple threads, so I'm not too sure the
> performance argument holds.

End to End testing on Solaris using WebLogic showed up ~20% faster page 
response times with this fix.  Profiling using JFR showed nextBytes() is 
a hot lock as the threads queued up wait to get random data.  A 
microbenchmark showed 3x better performance after the change.

It makes sense to have locking in the provider to protect against 
duplicate random data.  Synchronizing at the public API level of 
nextBytes(), is like having a synchronized Cipher.init(), it is way to 
high and impractical.

> What I do worry about is a provider that's not particularly smart about
> how it does things offering up data and not updating internal pointers
 > in a synchronized manner resulting in the possibility of the same
 > "random" data being served to multiple requestors.

I had that about that concern too.

There is no mention of a threaded guarantee by nextBytes() or 
SecureRandom in the documentation and I don't believe 'synchronized' is 
part of the public API that we are held to.

If we don't do this change because of the possibility someone's poor 
design, the only remedy I see is deprecating nextBytes() and replacing 
it with a new method.  To me, while that may be the safest move, that 
seems like a drastic step for the possibility of a poorly design.

> I think placing the
> synchronization at the glue class may be a better choice than depending
> on each and every provider doing the right thing.

I don't see how inserting a new class into this resolves the problem? 
The lock encompasses the whole getting of random numbers.

Tony

>
> Just a thought - Mike
>
>
>
> On 12/3/2015 1:38 PM, Se?n Coffey wrote:
>> Hey Tony,
>>
>> looks like a fix that could come back to jdk8u-dev at some stage.
>> Thanks for taking this one on.
>>
>> Adding SecureRandom to the sunpkcs11-solaris.cfg file is a nice move.
>> Would you agree that JDK-8058455 could be closed out as a duplicate ?
>>
>> Regards,
>> Sean.
>>
>> On 01/12/2015 23:44, Anthony Scarpino wrote:
>>> Hi all,
>>>
>>> I'd like a review of this change.  It improves nextBytes()
>>> performance by allowing the random buffer to grow and shrink as
>>> random data is needed and remove the high level synchronization. Also
>>> disable SecureRandom for Solaris PKCS11 as it's not as fast as native.
>>>
>>> http://cr.openjdk.java.net/~ascarpino/8098581/webrev/
>>>
>>> Thanks
>>>
>>> Tony
>>
>>
>


From anthony.scarpino at oracle.com  Fri Dec  4 20:12:31 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 4 Dec 2015 12:12:31 -0800
Subject: RFR: 8098581 SecureRandom.nextBytes() hurts performance with
	small size requests
In-Reply-To: <86984dc4-d32e-4f02-8878-66086cb4bf88.maildroid@localhost>
References: <565E30F7.5060307@oracle.com> <56608C3F.20600@oracle.com>
	<566093BA.5020802@comcast.net>
	<86984dc4-d32e-4f02-8878-66086cb4bf88.maildroid@localhost>
Message-ID: <5661F3AF.5040809@oracle.com>

On 12/03/2015 02:40 PM, ecki at zusammenkunft.net wrote:
> Hello,
>
> That buffer sizing/expiring is a bit strange (the dynmic version
> stranger than the old one), I do not understand the need for it. The
> requests should not varry so much in size. Just reading something
> like 64bytes at a time (possibly nonblocking) should be fine. No need
> to look at the age of that buffer...

Admittedly I'm keeping the buffer expiring only for the possibility 
someone could watch the array to predict what an application could 
receive in random data.  I have no proof this can happen, but I have to 
assume that was a concern given it was its original designed.  If I 
could be sure that was not a concern, I'd eliminate it.

In cases where a large amount of random data was needed from many 
threads, like the end to end TLS perf testing, the larger buffer size 
eliminated the overheads of reading the device.

The dynamic nature of the buffer size was that I didn't feel it was best 
for java to consume so many random bytes, like 64K worth, if the 
application only consumed a few at intervals that were just beyond the 
expiration time.  Therefore I ended up with this, a dynamic buffer that 
could grow and shrink as needed.
>
> A cool implementation would be an actual single periodic refresher
> thread which does not block reading (until buffer is empty)... but
> that might change the semantic a bit (and could be better used with
> the new DRNG api for block-free reseeding).

The locking was a big thing here.  For example, in 
NativePRNG.implNextBytes() the cost of copying the array and doing the 
xor outside the the synchronized block was quicker for multithreaded 
performance than not doing the copy and xor'ing inside the synchronized 
block.  I had thought about a refresher thread, but I felt the more 
threads competing for the buffer would make it worse.

>
> Bernd
>


From mstjohns at comcast.net  Sat Dec  5 20:43:23 2015
From: mstjohns at comcast.net (Mike StJohns)
Date: Sat, 5 Dec 2015 15:43:23 -0500
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
	<428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
Message-ID: <56634C6B.4000106@comcast.net>

Hi Max -

This comes under the heading of meta issues.  There are at least two 
forms of certificate request - PKCS10 (RFC2986) and CRMF (RFC4211).  
There may be others (not sure that SCEP is a request per se vs a protocol).

Both generate requests for X509 certificates so you can't differentiate 
on that basis.  So how do you wire this together to allow either/both to 
be provided by providers?

For the "getSigXXX" methods - maybe define a "PKISignature" class with 
those methods instead?  Have it package:  signature value, signature 
algorithm, params and ideally "keyid" (to identify the public key 
necessary to verify this signature).

Lastly, there are a number of certificates that use only the 
SubjectAltName extension as their name.  You can end up with an empty 
X500Principal in the request in that case.  And you probably want a way 
of getting any request attributes: Collection<Attribute>  
getRequestAttributes();

Mike


On 12/3/2015 3:31 AM, Wang Weijun wrote:
> I tried.
>
> It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better.
>
> Extension
> ---------
>
> Turns out java.security.cert.Extension is already defined for X.509, and there exists an X509Extension class in the same package (which should have been named SomethingHasX509Extensions). In case one day we want to define an extension for non-X.509 certs, I would still like to add static methods into X509Extension that returns an Extension:
>
>    static Extension newExtension(String oid, byte[] content, boolean isCritical);
>    static Extension newExtension(String oid, String value, boolean isCritical);
>
> The string-value version will also use oid as name since OID is the only language used in methods of Extension and X509Extension. Constants will be defined in X509Extension for known OIDs, say,
>
>    static final String KEYUSAGE = "2.5.29.16".
>
> The "for example" comment of getExtensionValue() will be gone.
>
> CertificateRequest
> ------------------
>
> A new CertificateRequest will be added which looks a lot like Certificate, it will have
>
>    String getType();
>    byte[] getEncoded();
>    PublicKey getPublicKey();
>
> and serialization but no verify(). It is always self-signed so the constructor can verify.
>
> It will have a child X509CertificateRequest which looks a lot like X509Certificate which even implements X509Extension. It will have
>
>    byte[] getCertificationRequestInfo;
>    X500Principal getSubjectX500Principal();
>    byte[] getSignature();
>    String getSigAlgName();
>    String getSigAlgOID();
>    byte[] getSigAlgParams();
>    int getVersion();
>
> (Or maybe not all getSigXXX() methods?)
>
> CertificateFactory should have a new method
>
>    CertificateRequest generateCertificateRequest(InputStream)
>
> and CertificateFactorySpi needs a corresponding engine method throwing UOE.
>
> The X509Factory implementation will read it.
>
>
> All these sound straightforward, worth doing?
>
> Thanks
> Max
>
>
>


From xuelei.fan at oracle.com  Sun Dec  6 00:03:50 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sun, 6 Dec 2015 08:03:50 +0800
Subject: Code Review Request, 8141651 Deadlock in
	sun.security.ssl.SSLSocketImpl
Message-ID: <56637B66.10705@oracle.com>

Hi,

Please review the fix for JDK-8141651:

    http://cr.openjdk.java.net/~xuelei/8141651/webrev.00/

In JDK 9, there is a deadlock introduced.  One thread can lock
SSLSocketImpl instance, and try to lock SSLSocketImpl.writeLock; Another
thread may lock SSLSocketImpl.writeLock, and then try to lock
SSLSocketImpl instance.  A deadlock happens.

This fix is trying to remove the latter lock sequence.

No new regression test as it is hard to re-produce the issue.

Thanks,
Xuelei

From xuelei.fan at oracle.com  Sun Dec  6 12:32:19 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sun, 6 Dec 2015 20:32:19 +0800
Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI
	extension
Message-ID: <56642AD3.6010904@oracle.com>

Hi,

Please review the update for JDK-8144566:

   http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/

For HttpsURLConnection, the server name may be set after the TLS
connection and handshake has been initialized.  As may result in that
the server name does not present at TLS ClientHello messages.

This fix resets the server name for the initialized handshake for above
cases.

Thanks,
Xuelei

From xuelei.fan at oracle.com  Mon Dec  7 02:52:50 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 7 Dec 2015 10:52:50 +0800
Subject: Code Review Request 8141593 Test RetryHttps timed out intermittently
Message-ID: <5664F482.7010600@oracle.com>

Hi Weijun,

Are you available review this patch for JDK-8141593?

    http://cr.openjdk.java.net/~xuelei/8141593/webrev.00/

Test RetryHttps.java timed out intermittently, and the exception looks
weird to me:

   javax.net.ssl.SSLException: Unsupported or unrecognized SSL message

Looks like there is something wrong of the underlying SSL/TLS
handshaking.  But I'm not sure of the root cause yet.  As this issue
happens intermittently, I cannot reproduce it and make further evaluation.

This is not a fix actually. I just enable the JSSE debug in the test.
Hope next failure, the debug log can be helpful.

Thanks,
Xuelei

From weijun.wang at oracle.com  Mon Dec  7 03:31:24 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 7 Dec 2015 11:31:24 +0800
Subject: Code Review Request 8141593 Test RetryHttps timed out
	intermittently
In-Reply-To: <5664F482.7010600@oracle.com>
References: <5664F482.7010600@oracle.com>
Message-ID: <A218C048-5E48-4BFA-81FF-6372D4455109@oracle.com>

Change looks fine. Best luck.

Thanks
Max

> On Dec 7, 2015, at 10:52 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Hi Weijun,
> 
> Are you available review this patch for JDK-8141593?
> 
>    http://cr.openjdk.java.net/~xuelei/8141593/webrev.00/
> 
> Test RetryHttps.java timed out intermittently, and the exception looks
> weird to me:
> 
>   javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
> 
> Looks like there is something wrong of the underlying SSL/TLS
> handshaking.  But I'm not sure of the root cause yet.  As this issue
> happens intermittently, I cannot reproduce it and make further evaluation.
> 
> This is not a fix actually. I just enable the JSSE debug in the test.
> Hope next failure, the debug log can be helpful.
> 
> Thanks,
> Xuelei


From weijun.wang at oracle.com  Mon Dec  7 03:51:21 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 7 Dec 2015 11:51:21 +0800
Subject: RFR 8138638: Security tests using
	jdk/test/sun/security/krb5/auto/KDC.java fail intermittently
	with OutOfMemoryError
Message-ID: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com>

Please review the fix at

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

It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request.

Thanks
Max


From weijun.wang at oracle.com  Mon Dec  7 03:56:48 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 7 Dec 2015 11:56:48 +0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <56634C6B.4000106@comcast.net>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
	<428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
	<56634C6B.4000106@comcast.net>
Message-ID: <FA4DA9A9-353E-4302-8936-A4BB1D022087@oracle.com>


> On Dec 6, 2015, at 4:43 AM, Mike StJohns <mstjohns at comcast.net> wrote:
> 
> Hi Max -
> 
> This comes under the heading of meta issues.  There are at least two forms of certificate request - PKCS10 (RFC2986) and CRMF (RFC4211).  There may be others (not sure that SCEP is a request per se vs a protocol).

I can change to request(type). Or we can keep the one without an argument which means always-pkcs10.

> 
> Both generate requests for X509 certificates so you can't differentiate on that basis.  So how do you wire this together to allow either/both to be provided by providers?

This Builder class is not a JCA engine, i.e. no Builder.getInstance().

> 
> For the "getSigXXX" methods - maybe define a "PKISignature" class with those methods instead?  Have it package:  signature value, signature algorithm, params and ideally "keyid" (to identify the public key necessary to verify this signature).

Can we add these methods later?

> 
> Lastly, there are a number of certificates that use only the SubjectAltName extension as their name.  You can end up with an empty X500Principal in the request in that case.  And you probably want a way of getting any request attributes: Collection<Attribute>  getRequestAttributes();

The sign() method blindly signs the request (should the method also include a requestType parameter or can it detect the type? maybe do not worry about it at the moment. we can add an overloaded method later) without looking at the content. If a real CA decides to use the API, it will need to call some other 3rd party tools to inspect the content.

Thanks
Max


> 
> Mike
> 
> 
> On 12/3/2015 3:31 AM, Wang Weijun wrote:
>> I tried.
>> 
>> It's quite easy to move the new X509CertificateBuilder class into java.security.cert.X509Certificate as an inner class, but I still want to make Extension and CertificateRequest better.
>> 
>> Extension
>> ---------
>> 
>> Turns out java.security.cert.Extension is already defined for X.509, and there exists an X509Extension class in the same package (which should have been named SomethingHasX509Extensions). In case one day we want to define an extension for non-X.509 certs, I would still like to add static methods into X509Extension that returns an Extension:
>> 
>>   static Extension newExtension(String oid, byte[] content, boolean isCritical);
>>   static Extension newExtension(String oid, String value, boolean isCritical);
>> 
>> The string-value version will also use oid as name since OID is the only language used in methods of Extension and X509Extension. Constants will be defined in X509Extension for known OIDs, say,
>> 
>>   static final String KEYUSAGE = "2.5.29.16".
>> 
>> The "for example" comment of getExtensionValue() will be gone.
>> 
>> CertificateRequest
>> ------------------
>> 
>> A new CertificateRequest will be added which looks a lot like Certificate, it will have
>> 
>>   String getType();
>>   byte[] getEncoded();
>>   PublicKey getPublicKey();
>> 
>> and serialization but no verify(). It is always self-signed so the constructor can verify.
>> 
>> It will have a child X509CertificateRequest which looks a lot like X509Certificate which even implements X509Extension. It will have
>> 
>>   byte[] getCertificationRequestInfo;
>>   X500Principal getSubjectX500Principal();
>>   byte[] getSignature();
>>   String getSigAlgName();
>>   String getSigAlgOID();
>>   byte[] getSigAlgParams();
>>   int getVersion();
>> 
>> (Or maybe not all getSigXXX() methods?)
>> 
>> CertificateFactory should have a new method
>> 
>>   CertificateRequest generateCertificateRequest(InputStream)
>> 
>> and CertificateFactorySpi needs a corresponding engine method throwing UOE.
>> 
>> The X509Factory implementation will read it.
>> 
>> 
>> All these sound straightforward, worth doing?
>> 
>> Thanks
>> Max
>> 
>> 
>> 
> 


From xuelei.fan at oracle.com  Mon Dec  7 04:02:29 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 7 Dec 2015 12:02:29 +0800
Subject: RFR 8138638: Security tests using
	jdk/test/sun/security/krb5/auto/KDC.java fail intermittently with
	OutOfMemoryError
In-Reply-To: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com>
References: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com>
Message-ID: <566504D5.4090508@oracle.com>

On 12/7/2015 11:51 AM, Wang Weijun wrote:
> Please review the fix at
> 
>   http://cr.openjdk.java.net/~weijun/8138638/webrev.00/
> 
> It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request.
> 
Ignore by throwing exception?  If I did not miss something, the test may
still fail with the new added exception if there is a huge request.

Xuelei


From weijun.wang at oracle.com  Mon Dec  7 04:35:44 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 7 Dec 2015 12:35:44 +0800
Subject: RFR 8138638: Security tests using
	jdk/test/sun/security/krb5/auto/KDC.java fail intermittently
	with OutOfMemoryError
In-Reply-To: <566504D5.4090508@oracle.com>
References: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com>
	<566504D5.4090508@oracle.com>
Message-ID: <04073B68-D892-4C18-9641-F376D2219843@oracle.com>

Its caught 5 lines below and then ignored.

--Max

> ? 2015?12?7??12:02?Xuelei Fan <xuelei.fan at oracle.com> ???
> 
>> On 12/7/2015 11:51 AM, Wang Weijun wrote:
>> Please review the fix at
>> 
>>  http://cr.openjdk.java.net/~weijun/8138638/webrev.00/
>> 
>> It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request.
> Ignore by throwing exception?  If I did not miss something, the test may
> still fail with the new added exception if there is a huge request.
> 
> Xuelei
> 

From xuelei.fan at oracle.com  Mon Dec  7 04:50:39 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 7 Dec 2015 12:50:39 +0800
Subject: RFR 8138638: Security tests using
	jdk/test/sun/security/krb5/auto/KDC.java fail intermittently with
	OutOfMemoryError
In-Reply-To: <04073B68-D892-4C18-9641-F376D2219843@oracle.com>
References: <26ADF744-577D-41EA-8BB3-C45765847ECC@oracle.com>
	<566504D5.4090508@oracle.com>
	<04073B68-D892-4C18-9641-F376D2219843@oracle.com>
Message-ID: <5665101F.4090208@oracle.com>

OK.  Looks fine now.

Xuelei

On 12/7/2015 12:35 PM, Wang Weijun wrote:
> Its caught 5 lines below and then ignored.
> 
> --Max
> 
>> ? 2015?12?7??12:02?Xuelei Fan <xuelei.fan at oracle.com> ???
>>
>>> On 12/7/2015 11:51 AM, Wang Weijun wrote:
>>> Please review the fix at
>>>
>>>  http://cr.openjdk.java.net/~weijun/8138638/webrev.00/
>>>
>>> It looks like the TCP server should be accessed in the failed tests. Maybe a random process happens to connect to the server? This code change will ignore the unknown request.
>> Ignore by throwing exception?  If I did not miss something, the test may
>> still fail with the new added exception if there is a huge request.
>>
>> Xuelei
>>


From xuelei.fan at oracle.com  Mon Dec  7 11:08:02 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 7 Dec 2015 19:08:02 +0800
Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing
	padding correctly
Message-ID: <56656892.3060904@oracle.com>

Hi Brad,

Please review this fix for JDK-8136410:

   http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/

AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is
used as a String split separator.  "NoPadding" was incorrectly split as
"NoPadd" and "g".

This update update the slit String split pattern, and "Padding" get
specially handled.

Thanks,
Xuelei

From amy.lu at oracle.com  Mon Dec  7 12:23:53 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 7 Dec 2015 20:23:53 +0800
Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing
	padding correctly
In-Reply-To: <56656892.3060904@oracle.com>
References: <56656892.3060904@oracle.com>
Message-ID: <56657A59.8000906@oracle.com>

Hi, Xuelei

test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java

   line36     private final static String PATH = 
System.getProperty("test.src", ".");

It seems that this line could be removed.

Thanks,
Amy

On 12/7/15 7:08 PM, Xuelei Fan wrote:
> Hi Brad,
>
> Please review this fix for JDK-8136410:
>
>     http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/
>
> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is
> used as a String split separator.  "NoPadding" was incorrectly split as
> "NoPadd" and "g".
>
> This update update the slit String split pattern, and "Padding" get
> specially handled.
>
> Thanks,
> Xuelei


From xuelei.fan at oracle.com  Mon Dec  7 12:35:13 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 7 Dec 2015 20:35:13 +0800
Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing
	padding correctly
In-Reply-To: <56657A59.8000906@oracle.com>
References: <56656892.3060904@oracle.com> <56657A59.8000906@oracle.com>
Message-ID: <56657D01.7030505@oracle.com>

On 12/7/2015 8:23 PM, Amy Lu wrote:
> Hi, Xuelei
> 
> test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java
> 
>   line36     private final static String PATH =
> System.getProperty("test.src", ".");
> 
> It seems that this line could be removed.
> 
Oops, bad copy and past.  Updated.

Thanks,
Xuelei

> Thanks,
> Amy
> 
> On 12/7/15 7:08 PM, Xuelei Fan wrote:
>> Hi Brad,
>>
>> Please review this fix for JDK-8136410:
>>
>>     http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/
>>
>> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is
>> used as a String split separator.  "NoPadding" was incorrectly split as
>> "NoPadd" and "g".
>>
>> This update update the slit String split pattern, and "Padding" get
>> specially handled.
>>
>> Thanks,
>> Xuelei
> 


From amy.lu at oracle.com  Mon Dec  7 12:53:18 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 7 Dec 2015 20:53:18 +0800
Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing
	padding correctly
In-Reply-To: <56657D01.7030505@oracle.com>
References: <56656892.3060904@oracle.com> <56657A59.8000906@oracle.com>
	<56657D01.7030505@oracle.com>
Message-ID: <5665813E.9040707@oracle.com>

On 12/7/15 8:35 PM, Xuelei Fan wrote:
> On 12/7/2015 8:23 PM, Amy Lu wrote:
>> Hi, Xuelei
>>
>> test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java
>>
>>    line36     private final static String PATH =
>> System.getProperty("test.src", ".");
>>
>> It seems that this line could be removed.
>>
> Oops, bad copy and past.  Updated.
Thank you for the quick update. I'm not openjdk reviewer and will leave 
the review to official reviewers.

Thanks,
Amy
>
> Thanks,
> Xuelei
>
>> Thanks,
>> Amy
>>
>> On 12/7/15 7:08 PM, Xuelei Fan wrote:
>>> Hi Brad,
>>>
>>> Please review this fix for JDK-8136410:
>>>
>>>      http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/
>>>
>>> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is
>>> used as a String split separator.  "NoPadding" was incorrectly split as
>>> "NoPadd" and "g".
>>>
>>> This update update the slit String split pattern, and "Padding" get
>>> specially handled.
>>>
>>> Thanks,
>>> Xuelei


From sean.mullan at oracle.com  Mon Dec  7 20:15:00 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 7 Dec 2015 15:15:00 -0500
Subject: Code Review Request 8141703, Test B6216082.java failed with
	operation timed out exception
In-Reply-To: <5661A631.4000300@oracle.com>
References: <5661A631.4000300@oracle.com>
Message-ID: <5665E8C4.7070502@oracle.com>

On 12/04/2015 09:41 AM, Xuelei Fan wrote:
> Hi,
>
> Please review the test update for JDK-8141703:
>     http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/
>
> The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java,
> need to start a server and proxy, and then make https connection over
> them.  It is noticed that the test fails intermittent.
>
> The cause may be that in rush platform, the target proxy and server may
> be not ready before the client call.  Maybe not worthy a fix, as the
> update need to re-org a lot of code and related classes.
>
> I plan to add the intermittent keyword to the test case, as the code in
> the webrev.

That seems fine to me, but that doesn't actually fix the failure, it 
just allows the test to be marked and grouped as one that fails 
intermittently. So, I think JDK-8141703 should remain open and you 
should file a different bug to add the intermittent keyword.

--Sean


From sean.mullan at oracle.com  Mon Dec  7 21:29:34 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 7 Dec 2015 16:29:34 -0500
Subject: [9] RFR: 8140470:
	javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java failed
	with java.security.AccessControlException
In-Reply-To: <56604F2C.6000401@oracle.com>
References: <56604D66.5050603@oracle.com> <56604F2C.6000401@oracle.com>
Message-ID: <5665FA3E.2090407@oracle.com>

Looks fine to me.

--Sean

On 12/03/2015 09:18 AM, Artem Smotrakov wrote:
> I sent a wrong version of webrev, please use the following one
>
> http://cr.openjdk.java.net/~asmotrak/8140470/webrev.01/
>
> Artem
>
> On 12/03/2015 05:10 PM, Artem Smotrakov wrote:
>> Hello,
>>
>> Please review this small fix which updates XMLDSigWithSecMgr.java test
>> to extend the default security policy instead of override. Please see
>> details here:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8140470?focusedCommentId=13873347&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13873347
>>
>>
>> The test could use "@run main/othervm/java.security.policy" action,
>> but sometimes it may be better to enable a security manager during
>> test execution to avoid granting many additional permissions if a test
>> requires some setup. I tried to set "java.security.policy" system
>> property just before enabling a security manager, and it seems to work
>> fine.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140470
>> Webrev: http://cr.openjdk.java.net/~asmotrak/8140470/webrev.00/
>>
>> Artem
>

From valerie.peng at oracle.com  Mon Dec  7 23:15:33 2015
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 07 Dec 2015 15:15:33 -0800
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
Message-ID: <56661315.2070701@oracle.com>

Siba,

I have just started to review this webrev and not done yet.
As for your question, the java.security file in OpenJDK9 still uses the 
provider class names instead of provider names. Are you talking about 
the java.security file in Jigsaw? Which build (OpenJDK or Jigsaw) have 
you tested against. I am pretty sure that I tested the 3rd party 
provider on classpath setting when I worked on the 7191662 changes.

Supposedly, if the jar files are available on class path, then you 
should specify its full *class name* in the java.security file for it to 
be instantiated. Otherwise, how would it find the class? Only the 
classes discovered by ServiceLoader can be identified using the provider 
name (which is different from the class name referred above). So, in 
your scenario, that would be "provider.TestJCEProvider" instead of "TEST".

If you still run into problems, try enable the java security debug flag 
and u should get a good  idea why it isn't loaded. Let me know if you 
still have questions.

Thanks,
Valerie

On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
> I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back?
>
> Thanks,
> Siba
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Monday, November 30, 2015 4:54 PM
> To: Sibabrata Sahoo; security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net
> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs
>
> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>
>> I have one question:
>> What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*"&  working with<= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider?
>>
>> Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH.
>>
> The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider.<N>  properties in the java.security file. I'm sure Valerie can say more about this.
>
> -Alan

From xuelei.fan at oracle.com  Tue Dec  8 00:11:06 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 8 Dec 2015 08:11:06 +0800
Subject: Code Review Request 8141703, Test B6216082.java failed with
	operation timed out exception
In-Reply-To: <5665E8C4.7070502@oracle.com>
References: <5661A631.4000300@oracle.com> <5665E8C4.7070502@oracle.com>
Message-ID: <5666201A.8090106@oracle.com>

On 12/8/2015 4:15 AM, Sean Mullan wrote:
> On 12/04/2015 09:41 AM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the test update for JDK-8141703:
>>     http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/
>>
>> The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java,
>> need to start a server and proxy, and then make https connection over
>> them.  It is noticed that the test fails intermittent.
>>
>> The cause may be that in rush platform, the target proxy and server may
>> be not ready before the client call.  Maybe not worthy a fix, as the
>> update need to re-org a lot of code and related classes.
>>
>> I plan to add the intermittent keyword to the test case, as the code in
>> the webrev.
> 
> That seems fine to me, but that doesn't actually fix the failure, it
> just allows the test to be marked and grouped as one that fails
> intermittently. So, I think JDK-8141703 should remain open and you
> should file a different bug to add the intermittent keyword.
> 
Yes.  I will keep this open and file a new bug.

Xuelei


From xuelei.fan at oracle.com  Tue Dec  8 00:15:28 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 7 Dec 2015 16:15:28 -0800 (PST)
Subject: Code Review Request 8141703, Test B6216082.java failed with
	operation timed out exception
In-Reply-To: <5666201A.8090106@oracle.com>
References: <5661A631.4000300@oracle.com> <5665E8C4.7070502@oracle.com>
	<5666201A.8090106@oracle.com>
Message-ID: <56662120.4050405@oracle.com>

On 12/8/2015 8:11 AM, Xuelei Fan wrote:
> On 12/8/2015 4:15 AM, Sean Mullan wrote:
>> On 12/04/2015 09:41 AM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Please review the test update for JDK-8141703:
>>>     http://cr.openjdk.java.net/~xuelei/8141703/webrev.00/
>>>
>>> The test, sun/net/www/protocol/https/HttpsURLConnection/B6216082.java,
>>> need to start a server and proxy, and then make https connection over
>>> them.  It is noticed that the test fails intermittent.
>>>
>>> The cause may be that in rush platform, the target proxy and server may
>>> be not ready before the client call.  Maybe not worthy a fix, as the
>>> update need to re-org a lot of code and related classes.
>>>
>>> I plan to add the intermittent keyword to the test case, as the code in
>>> the webrev.
>>
>> That seems fine to me, but that doesn't actually fix the failure, it
>> just allows the test to be marked and grouped as one that fails
>> intermittently. So, I think JDK-8141703 should remain open and you
>> should file a different bug to add the intermittent keyword.
>>
> Yes.  I will keep this open and file a new bug.
> 
New bug:

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

Xuelei

From bradford.wetmore at oracle.com  Tue Dec  8 00:21:09 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 7 Dec 2015 16:21:09 -0800
Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI
	extension
In-Reply-To: <56642AD3.6010904@oracle.com>
References: <56642AD3.6010904@oracle.com>
Message-ID: <56662275.5000007@oracle.com>


Please see my comment in the bug.  I haven't verified this, but it seems 
the problem might be generic to the codepath through SSLSocket, not just 
Https.

Brad





On 12/6/2015 4:32 AM, Xuelei Fan wrote:
> Hi,
>
> Please review the update for JDK-8144566:
>
>     http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/
>
> For HttpsURLConnection, the server name may be set after the TLS
> connection and handshake has been initialized.  As may result in that
> the server name does not present at TLS ClientHello messages.
>
> This fix resets the server name for the initialized handshake for above
> cases.
>
> Thanks,
> Xuelei
>

From ecki at zusammenkunft.net  Tue Dec  8 03:27:13 2015
From: ecki at zusammenkunft.net (ecki at zusammenkunft.net)
Date: Tue, 8 Dec 2015 04:27:13 +0100
Subject: Code Review Request 8144566, Custom HostnameVerifier disables
	SNI extension
In-Reply-To: <56662275.5000007@oracle.com>
References: <56642AD3.6010904@oracle.com> <56662275.5000007@oracle.com>
Message-ID: <830ac455-ed81-4427-84f8-5da3601f2f43.maildroid@localhost>

Isnt this codepath used as a workaround for dynamically disabling SNI? Using connect(host..) instead of SSLSocket(host) was at least a common, well known workaround.

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

-----Original Message-----
From: Bradford Wetmore <bradford.wetmore at oracle.com>
To: Xuelei Fan <xuelei.fan at oracle.com>, OpenJDK <security-dev at openjdk.java.net>
Sent: Di., 08 Dez. 2015 2:51
Subject: Re: Code Review Request 8144566, Custom HostnameVerifier disables SNI extension


Please see my comment in the bug.  I haven't verified this, but it seems 
the problem might be generic to the codepath through SSLSocket, not just 
Https.

Brad





On 12/6/2015 4:32 AM, Xuelei Fan wrote:
> Hi,
>
> Please review the update for JDK-8144566:
>
>     http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/
>
> For HttpsURLConnection, the server name may be set after the TLS
> connection and handshake has been initialized.  As may result in that
> the server name does not present at TLS ClientHello messages.
>
> This fix resets the server name for the initialized handshake for above
> cases.
>
> Thanks,
> Xuelei
>

From xuelei.fan at oracle.com  Tue Dec  8 12:12:46 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 8 Dec 2015 20:12:46 +0800
Subject: Code Review Request 8144566, Custom HostnameVerifier disables SNI
	extension
In-Reply-To: <56662275.5000007@oracle.com>
References: <56642AD3.6010904@oracle.com> <56662275.5000007@oracle.com>
Message-ID: <5666C93E.6010306@oracle.com>

Good catch!

I copied the comment here:

  ----------
    SocketFactory sslsf = SSLSocketFactory.getDefault();
    SSLSocket ssls = (SSLSocket) sslsf.createSocket();
    ssls.connect(new InetSocketAddress(
            "bugs.openjdk.java.net", 443), 0);
    ssls.startHandshake();

    No SNI is sent in this case.
  ----------

Although this is not a regression, but this is a very good catch.

However, I don't think the code path is a best practice, as the actual
behavior depends on providers behaviors and platform behaviors too much.
 I would recommend to use SSLParameters.setServerNames() to specify the
server names explicitly.

But, best effort should be made for the default server names for such
code paths.  Here is the webrev that also fixes this code path issue:

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

The fix gets a little bit complicated because of the need to consider
the SSLParameters.setServerNames() impact in the code path:

   SSLSocket ssls = (SSLSocket) sslsf.createSocket();

   // before the connection, need to consider the impact:
   // Get the SSLParameters from the socket, or create on the fly?
   // Call ssls.setSSLParameters(params) or not?
   ssls.connect(socketAddress);

   // after the connection, need to consider the impact:
   // Call ssls.setSSLParameters(params) or not?

Basically, the implementation honors the server name set by
SSLParameters.setServerNames().

Bernd's comment:
> Isnt this codepath used as a workaround for dynamically disabling
> SNI? Using connect(host..) instead of SSLSocket(host) was at
> least a common, well known workaround.
If the code path is really used in practice, the
SSLParameters.setServerNames() would better be called actually to
disable SNI explicitly.

    SocketFactory sslsf = SSLSocketFactory.getDefault();
    SSLSocket ssls = (SSLSocket) sslsf.createSocket();
    ssls.connect(new InetSocketAddress(
        "bugs.openjdk.java.net", 443), 0);
    sslParameters.setServerNames(emptyList);
    ssls.setSSLParameters(sslParameters);
    ssls.startHandshake();

Thank you, Bernd and Brad, for the feedback.

Thanks,
Xuelei

On 12/8/2015 8:21 AM, Bradford Wetmore wrote:
> 
> Please see my comment in the bug.  I haven't verified this, but it seems
> the problem might be generic to the codepath through SSLSocket, not just
> Https.
> 
> Brad
> 
> 
> 
> 
> 
> On 12/6/2015 4:32 AM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the update for JDK-8144566:
>>
>>     http://cr.openjdk.java.net/~xuelei/8144566/webrev.00/
>>
>> For HttpsURLConnection, the server name may be set after the TLS
>> connection and handshake has been initialized.  As may result in that
>> the server name does not present at TLS ClientHello messages.
>>
>> This fix resets the server name for the initialized handshake for above
>> cases.
>>
>> Thanks,
>> Xuelei
>>


From xuelei.fan at oracle.com  Tue Dec  8 12:28:39 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 8 Dec 2015 20:28:39 +0800
Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable
In-Reply-To: <565D9774.9000304@oracle.com>
References: <565D9774.9000304@oracle.com>
Message-ID: <5666CCF7.8080405@oracle.com>

Ping ...

On 12/1/2015 8:49 PM, Xuelei Fan wrote:
> Hi,
> 
> Please review the fix for JDK-8133070:
> 
>    http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/
> 
> In (Open)JDK 6, EC cipher suites get supported by Java.  However, there
> is no default EC provider in JDK 6 at that time.  In order to support
> third part's EC algorithm JCE provider dynamically, it is hard-coded to
> check the cipher suite availability dynamically for EC algorithms in
> SunJSSE provider.
> 
> Here is an example update in CipherSuite.java for the checking:
> 
>   -   static final boolean DYNAMIC_AVAILABILITY = false;
>   +   static final boolean DYNAMIC_AVAILABILITY = true;
> 
> The dynamically checking impacts the performance significantly as:
> 1. the check of the availability is expensive as it involves crypto
> operations.
> 2. a cache is used to maintain the availability of bulk ciphers in order
> to mitigate the #1 performance impact.  However, access and update to
> the cache need to be synchronized.
> 3. in order to support dynamically checking, the cache may be cleared if
> a particular cipher is not found or a new SSLContext is generated. As
> bring the performance impact of #1 back again.
> 
> Later, AEAD algorithm is defined by Java.  The same mechanism is used to
> support AEAD ciphers.
> 
> Now, EC and GCM algorithms are supported in JDK crypto providers. The
> hard-coded checking can get improved.  This fix updates:
> 1. remove the dynamically checking of cipher suite availability.
> 2. remove the cipher suite availability cache accordingly (need no
> synchronization accordingly)
> 3. other updates that impact by the availability checking.
> 
> The performance improvement is tested with the following simple case.
> Run the following code 1000, 2000, 3000 times in single thread mode and
> measure the millisecond for each:
> 
> ---------
> String[] cipherSuites =
>         {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"};
> for (int i = 0; i < loops; i++) {  // loops: 1000, 2000, 3000
>     SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>     engine.getEnabledCipherSuites();
>     engine.getSupportedCipherSuites();
> }
> ---------
> 
> The milliseconds for each test case (less is better) look like:
> 
>     loops   |  old    |  fixed
>    ---------+---------+----------
>    1000     |  2736   |  735
>    ---------+---------+----------
>    2000     |  3718   |  746
>    ---------+---------+----------
>    3000     |  4750   |  765
>    ---------+---------+----------
> 
> This fix improves the performance.
> 
> The existing regression testing get passed.  No new regression test is
> planned as this is a performance enhancement fix.
> 
> Thanks,
> Xuelei
> 


From sibabrata.sahoo at oracle.com  Tue Dec  8 14:09:01 2015
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 8 Dec 2015 06:09:01 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <56661315.2070701@oracle.com>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
Message-ID: <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>

Hi Valerie,

Here is the updated webrev: http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/

Now the modular behavior for the test works as per expectation through JAKE build with the following condition. 
If the provider jar is available under ModulePath then the "java.security" file should have the provider configuration entry as ProviderName while in case of ClassPath the entry should hold the full class name.

Thanks,
Siba

-----Original Message-----
From: Valerie Peng 
Sent: Tuesday, December 08, 2015 4:46 AM
To: Sibabrata Sahoo
Cc: Alan Bateman; security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Siba,

I have just started to review this webrev and not done yet.
As for your question, the java.security file in OpenJDK9 still uses the provider class names instead of provider names. Are you talking about the java.security file in Jigsaw? Which build (OpenJDK or Jigsaw) have you tested against. I am pretty sure that I tested the 3rd party provider on classpath setting when I worked on the 7191662 changes.

Supposedly, if the jar files are available on class path, then you should specify its full *class name* in the java.security file for it to be instantiated. Otherwise, how would it find the class? Only the classes discovered by ServiceLoader can be identified using the provider name (which is different from the class name referred above). So, in your scenario, that would be "provider.TestJCEProvider" instead of "TEST".

If you still run into problems, try enable the java security debug flag and u should get a good  idea why it isn't loaded. Let me know if you still have questions.

Thanks,
Valerie

On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
> I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back?
>
> Thanks,
> Siba
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Monday, November 30, 2015 4:54 PM
> To: Sibabrata Sahoo; security-dev at openjdk.java.net; 
> jigsaw-dev at openjdk.java.net
> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
> providers if they are in signed/unsigned modular JARs
>
> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>
>> I have one question:
>> What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*"&  working with<= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider?
>>
>> Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH.
>>
> The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider.<N>  properties in the java.security file. I'm sure Valerie can say more about this.
>
> -Alan

From valerie.peng at oracle.com  Tue Dec  8 22:04:45 2015
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 08 Dec 2015 14:04:45 -0800
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
Message-ID: <566753FD.5020106@oracle.com>

Right, that'd be my expectation as well. Sounds like everything works.
I will change to look at your latest webrev.
Valerie

On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
> Hi Valerie,
>
> Here is the updated webrev: http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>
> Now the modular behavior for the test works as per expectation through JAKE build with the following condition.
> If the provider jar is available under ModulePath then the "java.security" file should have the provider configuration entry as ProviderName while in case of ClassPath the entry should hold the full class name.
>
> Thanks,
> Siba
>
> -----Original Message-----
> From: Valerie Peng
> Sent: Tuesday, December 08, 2015 4:46 AM
> To: Sibabrata Sahoo
> Cc: Alan Bateman; security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net
> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs
>
> Siba,
>
> I have just started to review this webrev and not done yet.
> As for your question, the java.security file in OpenJDK9 still uses the provider class names instead of provider names. Are you talking about the java.security file in Jigsaw? Which build (OpenJDK or Jigsaw) have you tested against. I am pretty sure that I tested the 3rd party provider on classpath setting when I worked on the 7191662 changes.
>
> Supposedly, if the jar files are available on class path, then you should specify its full *class name* in the java.security file for it to be instantiated. Otherwise, how would it find the class? Only the classes discovered by ServiceLoader can be identified using the provider name (which is different from the class name referred above). So, in your scenario, that would be "provider.TestJCEProvider" instead of "TEST".
>
> If you still run into problems, try enable the java security debug flag and u should get a good  idea why it isn't loaded. Let me know if you still have questions.
>
> Thanks,
> Valerie
>
> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>> I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back?
>>
>> Thanks,
>> Siba
>>
>> -----Original Message-----
>> From: Alan Bateman
>> Sent: Monday, November 30, 2015 4:54 PM
>> To: Sibabrata Sahoo; security-dev at openjdk.java.net;
>> jigsaw-dev at openjdk.java.net
>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security
>> providers if they are in signed/unsigned modular JARs
>>
>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>> Here is the updated webrev:
>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>
>>> I have one question:
>>> What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*"&   working with<= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider?
>>>
>>> Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH.
>>>
>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider.<N>   properties in the java.security file. I'm sure Valerie can say more about this.
>>
>> -Alan

From valerie.peng at oracle.com  Wed Dec  9 00:06:39 2015
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 08 Dec 2015 16:06:39 -0800
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <566753FD.5020106@oracle.com>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
	<566753FD.5020106@oracle.com>
Message-ID: <5667708F.9000706@oracle.com>

Hi Siba,

Here are some nits:

I think it's somewhat misleading to use the term JCE here as what you 
are testing here is just security provider loading. JCE is more about 
security providers supporting export-controlled services/algorithms.
Since your provider is just an empty one, I don't think u need to sign 
it (again, it's only for JCE providers).
You can remove a lot of code as a result.
Also, your directory seems a bit deep, e.g. 
modules/src/jceprovidermodule/provider/TestJCEProvider.java vs 
modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of 
these files be under the same directory instead of spreading over 
several level of subdirectories? The file names are different enough to 
tell which is which. Other regression tests for provider loading 
functionality are under test/java/security/Provider. Easier to find this 
way.

Can you please make the appropriate changes, e.g. don't use the term 
JCE, get rid of the signing, and simplify the directory structure if 
possible?

Thanks,
Valerie

On 12/8/2015 2:04 PM, Valerie Peng wrote:
> Right, that'd be my expectation as well. Sounds like everything works.
> I will change to look at your latest webrev.
> Valerie
>
> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
>> Hi Valerie,
>>
>> Here is the updated webrev: 
>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>>
>> Now the modular behavior for the test works as per expectation 
>> through JAKE build with the following condition.
>> If the provider jar is available under ModulePath then the 
>> "java.security" file should have the provider configuration entry as 
>> ProviderName while in case of ClassPath the entry should hold the 
>> full class name.
>>
>> Thanks,
>> Siba
>>
>> -----Original Message-----
>> From: Valerie Peng
>> Sent: Tuesday, December 08, 2015 4:46 AM
>> To: Sibabrata Sahoo
>> Cc: Alan Bateman; security-dev at openjdk.java.net; 
>> jigsaw-dev at openjdk.java.net
>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>> providers if they are in signed/unsigned modular JARs
>>
>> Siba,
>>
>> I have just started to review this webrev and not done yet.
>> As for your question, the java.security file in OpenJDK9 still uses 
>> the provider class names instead of provider names. Are you talking 
>> about the java.security file in Jigsaw? Which build (OpenJDK or 
>> Jigsaw) have you tested against. I am pretty sure that I tested the 
>> 3rd party provider on classpath setting when I worked on the 7191662 
>> changes.
>>
>> Supposedly, if the jar files are available on class path, then you 
>> should specify its full *class name* in the java.security file for it 
>> to be instantiated. Otherwise, how would it find the class? Only the 
>> classes discovered by ServiceLoader can be identified using the 
>> provider name (which is different from the class name referred 
>> above). So, in your scenario, that would be 
>> "provider.TestJCEProvider" instead of "TEST".
>>
>> If you still run into problems, try enable the java security debug 
>> flag and u should get a good  idea why it isn't loaded. Let me know 
>> if you still have questions.
>>
>> Thanks,
>> Valerie
>>
>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>>> I would like to know more about this. As far, I can see the 
>>> "java.security" provider configuration available with JDK9, it holds 
>>> provider names instead of provider class names. In that case how it 
>>> resolve the fall back?
>>>
>>> Thanks,
>>> Siba
>>>
>>> -----Original Message-----
>>> From: Alan Bateman
>>> Sent: Monday, November 30, 2015 4:54 PM
>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net;
>>> jigsaw-dev at openjdk.java.net
>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security
>>> providers if they are in signed/unsigned modular JARs
>>>
>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>>> Here is the updated webrev:
>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>>
>>>> I have one question:
>>>> What should be the behavior when the older version of 3rd party JCE 
>>>> provider jar file(without service descriptor 
>>>> "META-INF/services/*"&   working with<= JDK8) configured by 
>>>> "java.security" file, will be place in CLASS_PATH, running through 
>>>> JDK9 and the client is using Security.getProvider() to look for the 
>>>> provider?
>>>>
>>>> Currently the scenario fails to find the JCE provider. Is this 
>>>> right behavior? If it is, then jdk9 is not backward compatible to 
>>>> find the security provider provided through older jar files from 
>>>> CLASS_PATH.
>>>>
>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this 
>>> point by falling back and attempting to load the class name 
>>> specified via the security.provider.<N>   properties in the 
>>> java.security file. I'm sure Valerie can say more about this.
>>>
>>> -Alan

From sibabrata.sahoo at oracle.com  Wed Dec  9 18:02:31 2015
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Wed, 9 Dec 2015 10:02:31 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <5667708F.9000706@oracle.com>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
	<566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com>
Message-ID: <62346504-1078-4ccd-9188-29dcd288f269@default>

Hi Valerie,

Here is the updated webrev: http://cr.openjdk.java.net/~ntv/siba/webrev.00/

Changes applied as per previous comments.
- File names are modified and do not include the term JCE.
- Source folder structure is flat now and all belongs to "java/security/Provider" folder.
- Sign jar functionality removed.

Thanks,
Siba

-----Original Message-----
From: Valerie Peng 
Sent: Wednesday, December 09, 2015 5:37 AM
To: Sibabrata Sahoo
Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan Bateman
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Hi Siba,

Here are some nits:

I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms.
Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers).
You can remove a lot of code as a result.
Also, your directory seems a bit deep, e.g. 
modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way.

Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible?

Thanks,
Valerie

On 12/8/2015 2:04 PM, Valerie Peng wrote:
> Right, that'd be my expectation as well. Sounds like everything works.
> I will change to look at your latest webrev.
> Valerie
>
> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
>> Hi Valerie,
>>
>> Here is the updated webrev: 
>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>>
>> Now the modular behavior for the test works as per expectation 
>> through JAKE build with the following condition.
>> If the provider jar is available under ModulePath then the 
>> "java.security" file should have the provider configuration entry as 
>> ProviderName while in case of ClassPath the entry should hold the 
>> full class name.
>>
>> Thanks,
>> Siba
>>
>> -----Original Message-----
>> From: Valerie Peng
>> Sent: Tuesday, December 08, 2015 4:46 AM
>> To: Sibabrata Sahoo
>> Cc: Alan Bateman; security-dev at openjdk.java.net; 
>> jigsaw-dev at openjdk.java.net
>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>> providers if they are in signed/unsigned modular JARs
>>
>> Siba,
>>
>> I have just started to review this webrev and not done yet.
>> As for your question, the java.security file in OpenJDK9 still uses 
>> the provider class names instead of provider names. Are you talking 
>> about the java.security file in Jigsaw? Which build (OpenJDK or
>> Jigsaw) have you tested against. I am pretty sure that I tested the 
>> 3rd party provider on classpath setting when I worked on the 7191662 
>> changes.
>>
>> Supposedly, if the jar files are available on class path, then you 
>> should specify its full *class name* in the java.security file for it 
>> to be instantiated. Otherwise, how would it find the class? Only the 
>> classes discovered by ServiceLoader can be identified using the 
>> provider name (which is different from the class name referred 
>> above). So, in your scenario, that would be 
>> "provider.TestJCEProvider" instead of "TEST".
>>
>> If you still run into problems, try enable the java security debug 
>> flag and u should get a good  idea why it isn't loaded. Let me know 
>> if you still have questions.
>>
>> Thanks,
>> Valerie
>>
>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>>> I would like to know more about this. As far, I can see the 
>>> "java.security" provider configuration available with JDK9, it holds 
>>> provider names instead of provider class names. In that case how it 
>>> resolve the fall back?
>>>
>>> Thanks,
>>> Siba
>>>
>>> -----Original Message-----
>>> From: Alan Bateman
>>> Sent: Monday, November 30, 2015 4:54 PM
>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; 
>>> jigsaw-dev at openjdk.java.net
>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>>> providers if they are in signed/unsigned modular JARs
>>>
>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>>> Here is the updated webrev:
>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>>
>>>> I have one question:
>>>> What should be the behavior when the older version of 3rd party JCE 
>>>> provider jar file(without service descriptor
>>>> "META-INF/services/*"&   working with<= JDK8) configured by 
>>>> "java.security" file, will be place in CLASS_PATH, running through
>>>> JDK9 and the client is using Security.getProvider() to look for the 
>>>> provider?
>>>>
>>>> Currently the scenario fails to find the JCE provider. Is this 
>>>> right behavior? If it is, then jdk9 is not backward compatible to 
>>>> find the security provider provided through older jar files from 
>>>> CLASS_PATH.
>>>>
>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this 
>>> point by falling back and attempting to load the class name
>>> specified via the security.provider.<N>   properties in the 
>>> java.security file. I'm sure Valerie can say more about this.
>>>
>>> -Alan

From mandy.chung at oracle.com  Wed Dec  9 18:25:03 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 9 Dec 2015 10:25:03 -0800
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <62346504-1078-4ccd-9188-29dcd288f269@default>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
	<566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com>
	<62346504-1078-4ccd-9188-29dcd288f269@default>
Message-ID: <A5CD3850-3E07-4647-B7E0-855AA6CFEEC5@oracle.com>

Some high-level comment:
1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java.  The Jigsaw prefix is not needed.
2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider.  [1] is a simple test for you to get started.

Some comments on JigsawSecurityUtils.java:
71         Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o));

this can be replaced with 
    Arrays.stream(options).collect(Collectors.joining(SPACE));

111         System.out.println(String.format(

You can do:  System.out.format(?.) instead;

Mandy
[1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java

> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> Hi Valerie,
> 
> Here is the updated webrev: http://cr.openjdk.java.net/~ntv/siba/webrev.00/
> 
> Changes applied as per previous comments.
> - File names are modified and do not include the term JCE.
> - Source folder structure is flat now and all belongs to "java/security/Provider" folder.
> - Sign jar functionality removed.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Valerie Peng 
> Sent: Wednesday, December 09, 2015 5:37 AM
> To: Sibabrata Sahoo
> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan Bateman
> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs
> 
> Hi Siba,
> 
> Here are some nits:
> 
> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms.
> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers).
> You can remove a lot of code as a result.
> Also, your directory seems a bit deep, e.g. 
> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way.
> 
> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible?
> 
> Thanks,
> Valerie
> 
> On 12/8/2015 2:04 PM, Valerie Peng wrote:
>> Right, that'd be my expectation as well. Sounds like everything works.
>> I will change to look at your latest webrev.
>> Valerie
>> 
>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
>>> Hi Valerie,
>>> 
>>> Here is the updated webrev: 
>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>>> 
>>> Now the modular behavior for the test works as per expectation 
>>> through JAKE build with the following condition.
>>> If the provider jar is available under ModulePath then the 
>>> "java.security" file should have the provider configuration entry as 
>>> ProviderName while in case of ClassPath the entry should hold the 
>>> full class name.
>>> 
>>> Thanks,
>>> Siba
>>> 
>>> -----Original Message-----
>>> From: Valerie Peng
>>> Sent: Tuesday, December 08, 2015 4:46 AM
>>> To: Sibabrata Sahoo
>>> Cc: Alan Bateman; security-dev at openjdk.java.net; 
>>> jigsaw-dev at openjdk.java.net
>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>>> providers if they are in signed/unsigned modular JARs
>>> 
>>> Siba,
>>> 
>>> I have just started to review this webrev and not done yet.
>>> As for your question, the java.security file in OpenJDK9 still uses 
>>> the provider class names instead of provider names. Are you talking 
>>> about the java.security file in Jigsaw? Which build (OpenJDK or
>>> Jigsaw) have you tested against. I am pretty sure that I tested the 
>>> 3rd party provider on classpath setting when I worked on the 7191662 
>>> changes.
>>> 
>>> Supposedly, if the jar files are available on class path, then you 
>>> should specify its full *class name* in the java.security file for it 
>>> to be instantiated. Otherwise, how would it find the class? Only the 
>>> classes discovered by ServiceLoader can be identified using the 
>>> provider name (which is different from the class name referred 
>>> above). So, in your scenario, that would be 
>>> "provider.TestJCEProvider" instead of "TEST".
>>> 
>>> If you still run into problems, try enable the java security debug 
>>> flag and u should get a good  idea why it isn't loaded. Let me know 
>>> if you still have questions.
>>> 
>>> Thanks,
>>> Valerie
>>> 
>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>>>> I would like to know more about this. As far, I can see the 
>>>> "java.security" provider configuration available with JDK9, it holds 
>>>> provider names instead of provider class names. In that case how it 
>>>> resolve the fall back?
>>>> 
>>>> Thanks,
>>>> Siba
>>>> 
>>>> -----Original Message-----
>>>> From: Alan Bateman
>>>> Sent: Monday, November 30, 2015 4:54 PM
>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; 
>>>> jigsaw-dev at openjdk.java.net
>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>>>> providers if they are in signed/unsigned modular JARs
>>>> 
>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>>>> Here is the updated webrev:
>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>>> 
>>>>> I have one question:
>>>>> What should be the behavior when the older version of 3rd party JCE 
>>>>> provider jar file(without service descriptor
>>>>> "META-INF/services/*"&   working with<= JDK8) configured by 
>>>>> "java.security" file, will be place in CLASS_PATH, running through
>>>>> JDK9 and the client is using Security.getProvider() to look for the 
>>>>> provider?
>>>>> 
>>>>> Currently the scenario fails to find the JCE provider. Is this 
>>>>> right behavior? If it is, then jdk9 is not backward compatible to 
>>>>> find the security provider provided through older jar files from 
>>>>> CLASS_PATH.
>>>>> 
>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this 
>>>> point by falling back and attempting to load the class name
>>>> specified via the security.provider.<N>   properties in the 
>>>> java.security file. I'm sure Valerie can say more about this.
>>>> 
>>>> -Alan


From sean.mullan at oracle.com  Wed Dec  9 19:40:21 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 9 Dec 2015 14:40:21 -0500
Subject: Code Review Request, 8141651 Deadlock in
	sun.security.ssl.SSLSocketImpl
In-Reply-To: <56637B66.10705@oracle.com>
References: <56637B66.10705@oracle.com>
Message-ID: <566883A5.2040805@oracle.com>

Fix looks good, interesting issue, though I wonder if there is a better 
locking scheme, but probably a question for another time.

--Sean

On 12/05/2015 07:03 PM, Xuelei Fan wrote:
> Hi,
>
> Please review the fix for JDK-8141651:
>
>      http://cr.openjdk.java.net/~xuelei/8141651/webrev.00/
>
> In JDK 9, there is a deadlock introduced.  One thread can lock
> SSLSocketImpl instance, and try to lock SSLSocketImpl.writeLock; Another
> thread may lock SSLSocketImpl.writeLock, and then try to lock
> SSLSocketImpl instance.  A deadlock happens.
>
> This fix is trying to remove the latter lock sequence.
>
> No new regression test as it is hard to re-produce the issue.
>
> Thanks,
> Xuelei
>

From sean.mullan at oracle.com  Wed Dec  9 21:43:23 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 9 Dec 2015 16:43:23 -0500
Subject: RFR: Remove @Deprecated annotation from java.security.acl and
	javax.security.cert packages
Message-ID: <5668A07B.2070202@oracle.com>

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

The @Deprecated annotation on a package is a no-op in terms of affecting 
the set of deprecation warnings the compiler produces. This has been 
clarified in the JLS and specification for java.lang.Deprecated in 9.

Thus, we should remove the @Deprecated annotations from the packages 
since they are not providing any value.

No webrev, since the diffs are trivial:

diff --git 
a/src/java.base/share/classes/java/security/acl/package-info.java 
b/src/java.base/share/classes/java/security/acl/package-info.java
--- a/src/java.base/share/classes/java/security/acl/package-info.java
+++ b/src/java.base/share/classes/java/security/acl/package-info.java
@@ -32,4 +32,3 @@
   * @since 1.1
   */
- at Deprecated
  package java.security.acl;
diff --git 
a/src/java.base/share/classes/javax/security/cert/package-info.java 
b/src/java.base/share/classes/javax/security/cert/package-info.java
--- a/src/java.base/share/classes/javax/security/cert/package-info.java
+++ b/src/java.base/share/classes/javax/security/cert/package-info.java
@@ -38,4 +38,3 @@
   * @since 1.4
   */
- at Deprecated
  package javax.security.cert;

Thanks,
Sean

From mandy.chung at oracle.com  Wed Dec  9 21:51:02 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 9 Dec 2015 13:51:02 -0800
Subject: RFR: Remove @Deprecated annotation from java.security.acl and
	javax.security.cert packages
In-Reply-To: <5668A07B.2070202@oracle.com>
References: <5668A07B.2070202@oracle.com>
Message-ID: <4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com>


> On Dec 9, 2015, at 1:43 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8144784
> 
> The @Deprecated annotation on a package is a no-op in terms of affecting the set of deprecation warnings the compiler produces. This has been clarified in the JLS and specification for java.lang.Deprecated in 9.
> 
> Thus, we should remove the @Deprecated annotations from the packages since they are not providing any value.


All classes in these two packages have @Deprecated. Removing @Deprecated from package-info.java is okay.


Mandy


From valerie.peng at oracle.com  Thu Dec 10 02:22:11 2015
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 09 Dec 2015 18:22:11 -0800
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <A5CD3850-3E07-4647-B7E0-855AA6CFEEC5@oracle.com>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
	<566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com>
	<62346504-1078-4ccd-9188-29dcd288f269@default>
	<A5CD3850-3E07-4647-B7E0-855AA6CFEEC5@oracle.com>
Message-ID: <5668E1D3.1070805@oracle.com>


I am leaving for vacation tonight and probably can't review the updates 
for Mandy's comments.
Existing changes are good enough for me, and what Mandy suggested sounds 
fine with me.
As long as the tests run as expected, I have no further comments.
Thanks,
Valerie

On 12/9/2015 10:25 AM, Mandy Chung wrote:
> Some high-level comment:
> 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java.  The Jigsaw prefix is not needed.
> 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider.  [1] is a simple test for you to get started.
>
> Some comments on JigsawSecurityUtils.java:
> 71         Arrays.asList(options).stream().forEach(o ->  command.append(SPACE + o));
>
> this can be replaced with
>      Arrays.stream(options).collect(Collectors.joining(SPACE));
>
> 111         System.out.println(String.format(
>
> You can do:  System.out.format(?.) instead;
>
> Mandy
> [1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java
>
>> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo<sibabrata.sahoo at oracle.com>  wrote:
>>
>> Hi Valerie,
>>
>> Here is the updated webrev: http://cr.openjdk.java.net/~ntv/siba/webrev.00/
>>
>> Changes applied as per previous comments.
>> - File names are modified and do not include the term JCE.
>> - Source folder structure is flat now and all belongs to "java/security/Provider" folder.
>> - Sign jar functionality removed.
>>
>> Thanks,
>> Siba
>>
>> -----Original Message-----
>> From: Valerie Peng
>> Sent: Wednesday, December 09, 2015 5:37 AM
>> To: Sibabrata Sahoo
>> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan Bateman
>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs
>>
>> Hi Siba,
>>
>> Here are some nits:
>>
>> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms.
>> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers).
>> You can remove a lot of code as a result.
>> Also, your directory seems a bit deep, e.g.
>> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way.
>>
>> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible?
>>
>> Thanks,
>> Valerie
>>
>> On 12/8/2015 2:04 PM, Valerie Peng wrote:
>>> Right, that'd be my expectation as well. Sounds like everything works.
>>> I will change to look at your latest webrev.
>>> Valerie
>>>
>>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
>>>> Hi Valerie,
>>>>
>>>> Here is the updated webrev:
>>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>>>>
>>>> Now the modular behavior for the test works as per expectation
>>>> through JAKE build with the following condition.
>>>> If the provider jar is available under ModulePath then the
>>>> "java.security" file should have the provider configuration entry as
>>>> ProviderName while in case of ClassPath the entry should hold the
>>>> full class name.
>>>>
>>>> Thanks,
>>>> Siba
>>>>
>>>> -----Original Message-----
>>>> From: Valerie Peng
>>>> Sent: Tuesday, December 08, 2015 4:46 AM
>>>> To: Sibabrata Sahoo
>>>> Cc: Alan Bateman; security-dev at openjdk.java.net;
>>>> jigsaw-dev at openjdk.java.net
>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security
>>>> providers if they are in signed/unsigned modular JARs
>>>>
>>>> Siba,
>>>>
>>>> I have just started to review this webrev and not done yet.
>>>> As for your question, the java.security file in OpenJDK9 still uses
>>>> the provider class names instead of provider names. Are you talking
>>>> about the java.security file in Jigsaw? Which build (OpenJDK or
>>>> Jigsaw) have you tested against. I am pretty sure that I tested the
>>>> 3rd party provider on classpath setting when I worked on the 7191662
>>>> changes.
>>>>
>>>> Supposedly, if the jar files are available on class path, then you
>>>> should specify its full *class name* in the java.security file for it
>>>> to be instantiated. Otherwise, how would it find the class? Only the
>>>> classes discovered by ServiceLoader can be identified using the
>>>> provider name (which is different from the class name referred
>>>> above). So, in your scenario, that would be
>>>> "provider.TestJCEProvider" instead of "TEST".
>>>>
>>>> If you still run into problems, try enable the java security debug
>>>> flag and u should get a good  idea why it isn't loaded. Let me know
>>>> if you still have questions.
>>>>
>>>> Thanks,
>>>> Valerie
>>>>
>>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>>>>> I would like to know more about this. As far, I can see the
>>>>> "java.security" provider configuration available with JDK9, it holds
>>>>> provider names instead of provider class names. In that case how it
>>>>> resolve the fall back?
>>>>>
>>>>> Thanks,
>>>>> Siba
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alan Bateman
>>>>> Sent: Monday, November 30, 2015 4:54 PM
>>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net;
>>>>> jigsaw-dev at openjdk.java.net
>>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security
>>>>> providers if they are in signed/unsigned modular JARs
>>>>>
>>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>>>>> Here is the updated webrev:
>>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>>>>
>>>>>> I have one question:
>>>>>> What should be the behavior when the older version of 3rd party JCE
>>>>>> provider jar file(without service descriptor
>>>>>> "META-INF/services/*"&    working with<= JDK8) configured by
>>>>>> "java.security" file, will be place in CLASS_PATH, running through
>>>>>> JDK9 and the client is using Security.getProvider() to look for the
>>>>>> provider?
>>>>>>
>>>>>> Currently the scenario fails to find the JCE provider. Is this
>>>>>> right behavior? If it is, then jdk9 is not backward compatible to
>>>>>> find the security provider provided through older jar files from
>>>>>> CLASS_PATH.
>>>>>>
>>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this
>>>>> point by falling back and attempting to load the class name
>>>>> specified via the security.provider.<N>    properties in the
>>>>> java.security file. I'm sure Valerie can say more about this.
>>>>>
>>>>> -Alan

From weijun.wang at oracle.com  Thu Dec 10 05:36:49 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 10 Dec 2015 13:36:49 +0800
Subject: Code Review Request,
	8136410 AlgorithmDecomposer is not parsing padding correctly
In-Reply-To: <56657D01.7030505@oracle.com>
References: <56656892.3060904@oracle.com> <56657A59.8000906@oracle.com>
	<56657D01.7030505@oracle.com>
Message-ID: <BEDF2872-D961-44DA-972C-433D7EB1273E@oracle.com>

The code change looks ok. You might want to rename the test from Decomposealgorithms to DecomposeAlgorithms.

However, I am not sure if this is the ultimate solution. IMHO, it will be nice to provide several patterns, say, <hash>with<kp>in<format> etc and provide a supported list for each category (hash, kp, format).

--Max

> On Dec 7, 2015, at 8:35 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 12/7/2015 8:23 PM, Amy Lu wrote:
>> Hi, Xuelei
>> 
>> test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java
>> 
>>  line36     private final static String PATH =
>> System.getProperty("test.src", ".");
>> 
>> It seems that this line could be removed.
>> 
> Oops, bad copy and past.  Updated.
> 
> Thanks,
> Xuelei
> 
>> Thanks,
>> Amy
>> 
>> On 12/7/15 7:08 PM, Xuelei Fan wrote:
>>> Hi Brad,
>>> 
>>> Please review this fix for JDK-8136410:
>>> 
>>>    http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/
>>> 
>>> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is
>>> used as a String split separator.  "NoPadding" was incorrectly split as
>>> "NoPadd" and "g".
>>> 
>>> This update update the slit String split pattern, and "Padding" get
>>> specially handled.
>>> 
>>> Thanks,
>>> Xuelei
>> 
> 


From xuelei.fan at oracle.com  Thu Dec 10 05:58:56 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 10 Dec 2015 13:58:56 +0800
Subject: Code Review Request, 8136410 AlgorithmDecomposer is not parsing
	padding correctly
In-Reply-To: <BEDF2872-D961-44DA-972C-433D7EB1273E@oracle.com>
References: <56656892.3060904@oracle.com> <56657A59.8000906@oracle.com>
	<56657D01.7030505@oracle.com>
	<BEDF2872-D961-44DA-972C-433D7EB1273E@oracle.com>
Message-ID: <566914A0.8080907@oracle.com>

On 12/10/2015 1:36 PM, Wang Weijun wrote:
> The code change looks ok. You might want to rename the test from Decomposealgorithms to DecomposeAlgorithms.
> 
OK. Will do it.

> However, I am not sure if this is the ultimate solution.
No at present.  The current decomposing only consider certpath and tls
algorithms.  May need improvement if extends the scope in the future.

> IMHO, it will be nice to provide several patterns, say, <hash>with<kp>in<format> etc and provide a supported list for each category (hash, kp, format).
> 
Maybe.  But add extra workload to maintain the supported list.  Will
consider the proposal in the future if need to extends the scope.

Thanks,
Xuelei


> --Max
> 
>> On Dec 7, 2015, at 8:35 PM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> On 12/7/2015 8:23 PM, Amy Lu wrote:
>>> Hi, Xuelei
>>>
>>> test/sun/security/util/AlgorithmConstraints/Decomposealgorithms.java
>>>
>>>  line36     private final static String PATH =
>>> System.getProperty("test.src", ".");
>>>
>>> It seems that this line could be removed.
>>>
>> Oops, bad copy and past.  Updated.
>>
>> Thanks,
>> Xuelei
>>
>>> Thanks,
>>> Amy
>>>
>>> On 12/7/15 7:08 PM, Xuelei Fan wrote:
>>>> Hi Brad,
>>>>
>>>> Please review this fix for JDK-8136410:
>>>>
>>>>    http://cr.openjdk.java.net/~xuelei/8136410/webrev.00/
>>>>
>>>> AlgorithmDecomposer cannot parse "Padding" string properly as 'in' is
>>>> used as a String split separator.  "NoPadding" was incorrectly split as
>>>> "NoPadd" and "g".
>>>>
>>>> This update update the slit String split pattern, and "Padding" get
>>>> specially handled.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>
>>
> 


From sean.mullan at oracle.com  Thu Dec 10 15:53:38 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 10 Dec 2015 10:53:38 -0500
Subject: RFR: Remove @Deprecated annotation from java.security.acl and
	javax.security.cert packages
In-Reply-To: <4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com>
References: <5668A07B.2070202@oracle.com>
	<4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com>
Message-ID: <5669A002.8090209@oracle.com>

On 12/09/2015 04:51 PM, Mandy Chung wrote:
>
>> On Dec 9, 2015, at 1:43 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8144784
>>
>> The @Deprecated annotation on a package is a no-op in terms of affecting the set of deprecation warnings the compiler produces. This has been clarified in the JLS and specification for java.lang.Deprecated in 9.
>>
>> Thus, we should remove the @Deprecated annotations from the packages since they are not providing any value.
>
>
> All classes in these two packages have @Deprecated. Removing @Deprecated from package-info.java is okay.

Max asked me to add the com.sun.jarsigner package to this bug, which 
also has an unnecessary @Deprecated annotation. I also made a few tweaks 
to the deprecation wording here and there, so a webrev is probably 
easier to review than diffs now:

http://cr.openjdk.java.net/~mullan/webrevs/8144784/webrev.00/

--Sean

From chris.hegarty at oracle.com  Thu Dec 10 15:56:33 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 10 Dec 2015 15:56:33 +0000
Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util
Message-ID: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com>

sun.misc.HexDumpEncoder is an internal private API that is used almost
exclusively by the security library code. It should be moved out of sun.misc
and into a package more appropriate to its use, sun.security.util.

HexDumpEncoder extends CharacterEncoder, which is slated for later
removal, so the minimal implementation was copied in-place ( no new
code ).

http://cr.openjdk.java.net/~chegar/8144995/00/webrev/

-Chris.

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

From paul.sandoz at oracle.com  Thu Dec 10 16:03:47 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 10 Dec 2015 17:03:47 +0100
Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util
In-Reply-To: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com>
References: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com>
Message-ID: <6AF2B0FA-3AC4-4B39-9718-405BC0443889@oracle.com>

Looks ok to me,
Paul.

> On 10 Dec 2015, at 16:56, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> sun.misc.HexDumpEncoder is an internal private API that is used almost
> exclusively by the security library code. It should be moved out of sun.misc
> and into a package more appropriate to its use, sun.security.util.
> 
> HexDumpEncoder extends CharacterEncoder, which is slated for later
> removal, so the minimal implementation was copied in-place ( no new
> code ).
> 
> http://cr.openjdk.java.net/~chegar/8144995/00/webrev/
> 
> -Chris.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8144995

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151210/8f14c97f/signature-0001.asc>

From mandy.chung at oracle.com  Thu Dec 10 18:14:18 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 10 Dec 2015 10:14:18 -0800
Subject: RFR: Remove @Deprecated annotation from java.security.acl and
	javax.security.cert packages
In-Reply-To: <5669A002.8090209@oracle.com>
References: <5668A07B.2070202@oracle.com>
	<4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com>
	<5669A002.8090209@oracle.com>
Message-ID: <7DDA7C75-590D-430C-A93F-845A451CC5EB@oracle.com>


> On Dec 10, 2015, at 7:53 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Max asked me to add the com.sun.jarsigner package to this bug, which also has an unnecessary @Deprecated annotation. I also made a few tweaks to the deprecation wording here and there, so a webrev is probably easier to review than diffs now:
> 
> http://cr.openjdk.java.net/~mullan/webrevs/8144784/webrev.00/

Is there any other package-info.java beside these three packages?  It worths to have a quick scan on the source.

To me, it?s fine to keep the existing @deprecated comment in com.sun.jarsigner.* classes since I assume you want to discourage new classes to be added in that package.

Mandy


From bradford.wetmore at oracle.com  Thu Dec 10 21:09:06 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 10 Dec 2015 13:09:06 -0800
Subject: Code Review Request, 8141651 Deadlock in
	sun.security.ssl.SSLSocketImpl
In-Reply-To: <566883A5.2040805@oracle.com>
References: <56637B66.10705@oracle.com> <566883A5.2040805@oracle.com>
Message-ID: <5669E9F2.6030409@oracle.com>

Looks good.

Brad



On 12/9/2015 11:40 AM, Sean Mullan wrote:
> Fix looks good, interesting issue, though I wonder if there is a better
> locking scheme, but probably a question for another time.
>
> --Sean
>
> On 12/05/2015 07:03 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the fix for JDK-8141651:
>>
>>      http://cr.openjdk.java.net/~xuelei/8141651/webrev.00/
>>
>> In JDK 9, there is a deadlock introduced.  One thread can lock
>> SSLSocketImpl instance, and try to lock SSLSocketImpl.writeLock; Another
>> thread may lock SSLSocketImpl.writeLock, and then try to lock
>> SSLSocketImpl instance.  A deadlock happens.
>>
>> This fix is trying to remove the latter lock sequence.
>>
>> No new regression test as it is hard to re-produce the issue.
>>
>> Thanks,
>> Xuelei
>>

From sean.mullan at oracle.com  Thu Dec 10 21:18:36 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 10 Dec 2015 16:18:36 -0500
Subject: RFR: Remove @Deprecated annotation from java.security.acl and
	javax.security.cert packages
In-Reply-To: <7DDA7C75-590D-430C-A93F-845A451CC5EB@oracle.com>
References: <5668A07B.2070202@oracle.com>
	<4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com>
	<5669A002.8090209@oracle.com>
	<7DDA7C75-590D-430C-A93F-845A451CC5EB@oracle.com>
Message-ID: <5669EC2C.40109@oracle.com>

On 12/10/2015 01:14 PM, Mandy Chung wrote:
>
>> On Dec 10, 2015, at 7:53 AM, Sean Mullan <sean.mullan at oracle.com>
>> wrote:
>>
>> Max asked me to add the com.sun.jarsigner package to this bug,
>> which also has an unnecessary @Deprecated annotation. I also made a
>> few tweaks to the deprecation wording here and there, so a webrev
>> is probably easier to review than diffs now:
>>
>> http://cr.openjdk.java.net/~mullan/webrevs/8144784/webrev.00/
>
> Is there any other package-info.java beside these three packages?  It
> worths to have a quick scan on the source.
>
> To me, it?s fine to keep the existing @deprecated comment in
> com.sun.jarsigner.* classes since I assume you want to discourage new
> classes to be added in that package.

Well, we are trying to "deprecate" use of the @Deprecated annotation on 
packages, so I would prefer not to leave this in (also, I heard there 
will eventually be a javac warning for this). Instead I will add a 
sentence or comment that says new classes should not be added to the 
package. Is that ok?

--Sean

From mandy.chung at oracle.com  Thu Dec 10 22:12:52 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 10 Dec 2015 14:12:52 -0800
Subject: RFR: Remove @Deprecated annotation from java.security.acl and
	javax.security.cert packages
In-Reply-To: <5669EC2C.40109@oracle.com>
References: <5668A07B.2070202@oracle.com>
	<4F54EC3A-AB87-4B2E-9C1A-FF0DF44F649B@oracle.com>
	<5669A002.8090209@oracle.com>
	<7DDA7C75-590D-430C-A93F-845A451CC5EB@oracle.com>
	<5669EC2C.40109@oracle.com>
Message-ID: <5669F8E4.4070403@oracle.com>



On 12/10/2015 01:18 PM, Sean Mullan wrote:
> On 12/10/2015 01:14 PM, Mandy Chung wrote:
>>
>>> On Dec 10, 2015, at 7:53 AM, Sean Mullan <sean.mullan at oracle.com>
>>> wrote:
>>>
>>> Max asked me to add the com.sun.jarsigner package to this bug,
>>> which also has an unnecessary @Deprecated annotation. I also made a
>>> few tweaks to the deprecation wording here and there, so a webrev
>>> is probably easier to review than diffs now:
>>>
>>> http://cr.openjdk.java.net/~mullan/webrevs/8144784/webrev.00/
>>
>> Is there any other package-info.java beside these three packages?  It
>> worths to have a quick scan on the source.
>>
>> To me, it?s fine to keep the existing @deprecated comment in
>> com.sun.jarsigner.* classes since I assume you want to discourage new
>> classes to be added in that package.
>
> Well, we are trying to "deprecate" use of the @Deprecated annotation 
> on packages, so I would prefer not to leave this in (also, I heard 
> there will eventually be a javac warning for this). Instead I will add 
> a sentence or comment that says new classes should not be added to the 
> package. Is that ok?

To clarify: I meant the original comment in these two files seems fine 
and cound be reverted:
src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSigner.java
src/jdk.jartool/share/classes/com/sun/jarsigner/ContentSignerParameter.java

Your suggestion to add a sentence in package-info.java is a fine idea.

Mandy


From mandy.chung at oracle.com  Fri Dec 11 07:18:10 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 10 Dec 2015 23:18:10 -0800
Subject: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util
In-Reply-To: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com>
References: <581875CA-066E-457D-8AC0-F204AA104034@oracle.com>
Message-ID: <9F8FBD74-9FC7-4C54-950E-73E663E898FB@oracle.com>


> On Dec 10, 2015, at 7:56 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> sun.misc.HexDumpEncoder is an internal private API that is used almost
> exclusively by the security library code. It should be moved out of sun.misc
> and into a package more appropriate to its use, sun.security.util.
> 
> HexDumpEncoder extends CharacterEncoder, which is slated for later
> removal, so the minimal implementation was copied in-place ( no new
> code ).
> 
> http://cr.openjdk.java.net/~chegar/8144995/00/webrev/

Looks okay.

Mandy


From bhanu.prakash.gopularam at oracle.com  Fri Dec 11 10:50:29 2015
From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam)
Date: Fri, 11 Dec 2015 02:50:29 -0800 (PST)
Subject: RFR: 8129567 - the GCM mode parameter which is used as the
	initialization vector ("IV") is set to all zeros
Message-ID: <e03cca02-fd10-4566-b0e6-c52fc8f1c637@default>

Hi all,

 

Please review a fix for following bug:

 

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

 

Issue - Few tests are using all zero IV for GCM parameter spec which gives CRYPTO_MECHANISM_PARAM_INVALID error

On certain platforms

 

Solution - Use a random IV in GCMParameterSpec in the tests

 

webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129567/webrev.00/

 

Thanks,

Bhanu

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151211/be9e2462/attachment.html>

From sean.mullan at oracle.com  Mon Dec 14 16:05:21 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 14 Dec 2015 11:05:21 -0500
Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom
	Implementations
In-Reply-To: <C2B0A925-32AD-42CF-ACE5-F7F73119F0F9@oracle.com>
References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com>
	<5644AF03.5010704@oracle.com>
	<391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com>
	<56462436.1050602@oracle.com>
	<5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com>
	<564C7DDC.6000902@oracle.com>
	<AD10315B-DF13-41CA-A10D-91F69625BF5F@oracle.com>
	<564E02A8.5060402@oracle.com>
	<5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com>
	<B992E7C9-ECCB-4E60-9006-5FFBD4632A81@oracle.com>
	<F0855F85-6307-4D59-A213-DA7D9B9E4815@oracle.com>
	<C2B0A925-32AD-42CF-ACE5-F7F73119F0F9@oracle.com>
Message-ID: <566EE8C1.90700@oracle.com>

The DrbgParameters class has 7 parameters, most of which are optional. A 
typical use case might involve lots of null parameters:

DrbgParameters params = new DrbgParameters(null, null, 256, false, 
false, nonce, null);

That seems awkward, and you have be overly careful to map the right 
value to each parameter.

I think this is a case where a DrbgParameters.Builder would be very useful.

--Sean

I think this is an ideal use case for the
On 11/30/2015 01:30 AM, Wang Weijun wrote:
> Minor updates:
>
> spec: http://cr.openjdk.java.net/~weijun/8051408/webrev.01/specdiff/java/security/package-summary.html
> impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.01/
>        http://javaweb.us.oracle.com/~weijwan/webrev/8051408/webrev/  <<- test/closed
>
> Mostly spec. reseed() has no default implementation now (aka throws UnsupportedOperationException).
>
> Integration date is now Dec 4. Won't catch it.
>
> --Max
>
>> On Nov 23, 2015, at 3:03 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>
>> spec: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/specdiff/java/security/package-summary.html
>> impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/
>>
>> - No more configure(), it's getInstance(alg, SecureRandomParameters) now.
>>
>> - The *Spec class names are now *Parameters.
>>
>> - Overloaded reseed() and reseed(additionalInput).
>>
>> TBD: Should nextBytes(bytes,additionalInput) throw an UnsupportedOperationException for old implementations?
>>
>> Thanks
>> Max
>>
>

From sean.mullan at oracle.com  Mon Dec 14 20:24:36 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 14 Dec 2015 15:24:36 -0500
Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable
In-Reply-To: <565D9774.9000304@oracle.com>
References: <565D9774.9000304@oracle.com>
Message-ID: <566F2584.5070502@oracle.com>

Hi Xuelei,

For JDK 9, the EC impl is defined to be in its own module 
(jdk.crypto.ec). How does it affect this fix if that module is not 
available/installed?

--Sean

On 12/01/2015 07:49 AM, Xuelei Fan wrote:
> Hi,
>
> Please review the fix for JDK-8133070:
>
>     http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/
>
> In (Open)JDK 6, EC cipher suites get supported by Java.  However, there
> is no default EC provider in JDK 6 at that time.  In order to support
> third part's EC algorithm JCE provider dynamically, it is hard-coded to
> check the cipher suite availability dynamically for EC algorithms in
> SunJSSE provider.
>
> Here is an example update in CipherSuite.java for the checking:
>
>    -   static final boolean DYNAMIC_AVAILABILITY = false;
>    +   static final boolean DYNAMIC_AVAILABILITY = true;
>
> The dynamically checking impacts the performance significantly as:
> 1. the check of the availability is expensive as it involves crypto
> operations.
> 2. a cache is used to maintain the availability of bulk ciphers in order
> to mitigate the #1 performance impact.  However, access and update to
> the cache need to be synchronized.
> 3. in order to support dynamically checking, the cache may be cleared if
> a particular cipher is not found or a new SSLContext is generated. As
> bring the performance impact of #1 back again.
>
> Later, AEAD algorithm is defined by Java.  The same mechanism is used to
> support AEAD ciphers.
>
> Now, EC and GCM algorithms are supported in JDK crypto providers. The
> hard-coded checking can get improved.  This fix updates:
> 1. remove the dynamically checking of cipher suite availability.
> 2. remove the cipher suite availability cache accordingly (need no
> synchronization accordingly)
> 3. other updates that impact by the availability checking.
>
> The performance improvement is tested with the following simple case.
> Run the following code 1000, 2000, 3000 times in single thread mode and
> measure the millisecond for each:
>
> ---------
> String[] cipherSuites =
>          {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"};
> for (int i = 0; i < loops; i++) {  // loops: 1000, 2000, 3000
>      SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>      engine.getEnabledCipherSuites();
>      engine.getSupportedCipherSuites();
> }
> ---------
>
> The milliseconds for each test case (less is better) look like:
>
>      loops   |  old    |  fixed
>     ---------+---------+----------
>     1000     |  2736   |  735
>     ---------+---------+----------
>     2000     |  3718   |  746
>     ---------+---------+----------
>     3000     |  4750   |  765
>     ---------+---------+----------
>
> This fix improves the performance.
>
> The existing regression testing get passed.  No new regression test is
> planned as this is a performance enhancement fix.
>
> Thanks,
> Xuelei
>

From xuelei.fan at oracle.com  Tue Dec 15 03:08:43 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 15 Dec 2015 11:08:43 +0800
Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable
In-Reply-To: <566F2584.5070502@oracle.com>
References: <565D9774.9000304@oracle.com> <566F2584.5070502@oracle.com>
Message-ID: <566F843B.4090605@oracle.com>

On 12/15/2015 4:24 AM, Sean Mullan wrote:
> Hi Xuelei,
> 
> For JDK 9, the EC impl is defined to be in its own module
> (jdk.crypto.ec). How does it affect this fix if that module is not
> available/installed?
> 
The SunJSSE provider would not support dynamically loading of crypto
providers/modules.  At present, there are two providers that supports EC
implementation, SunEC (jdk.crypto.ec) and SunPKCS11 (jdk.crypto.pkcs11).
 If no EC provider, EC cipher suites would not be available to use.
That's to say, EC cipher suites would not be enabled by default, and
cannot be used for handshaking.  In the fix,
JsseJce#EcAvailability.isAvailable is used to check the availability of
EC crypto impl.

Xuelei

> --Sean
> 
> On 12/01/2015 07:49 AM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the fix for JDK-8133070:
>>
>>     http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/
>>
>> In (Open)JDK 6, EC cipher suites get supported by Java.  However, there
>> is no default EC provider in JDK 6 at that time.  In order to support
>> third part's EC algorithm JCE provider dynamically, it is hard-coded to
>> check the cipher suite availability dynamically for EC algorithms in
>> SunJSSE provider.
>>
>> Here is an example update in CipherSuite.java for the checking:
>>
>>    -   static final boolean DYNAMIC_AVAILABILITY = false;
>>    +   static final boolean DYNAMIC_AVAILABILITY = true;
>>
>> The dynamically checking impacts the performance significantly as:
>> 1. the check of the availability is expensive as it involves crypto
>> operations.
>> 2. a cache is used to maintain the availability of bulk ciphers in order
>> to mitigate the #1 performance impact.  However, access and update to
>> the cache need to be synchronized.
>> 3. in order to support dynamically checking, the cache may be cleared if
>> a particular cipher is not found or a new SSLContext is generated. As
>> bring the performance impact of #1 back again.
>>
>> Later, AEAD algorithm is defined by Java.  The same mechanism is used to
>> support AEAD ciphers.
>>
>> Now, EC and GCM algorithms are supported in JDK crypto providers. The
>> hard-coded checking can get improved.  This fix updates:
>> 1. remove the dynamically checking of cipher suite availability.
>> 2. remove the cipher suite availability cache accordingly (need no
>> synchronization accordingly)
>> 3. other updates that impact by the availability checking.
>>
>> The performance improvement is tested with the following simple case.
>> Run the following code 1000, 2000, 3000 times in single thread mode and
>> measure the millisecond for each:
>>
>> ---------
>> String[] cipherSuites =
>>          {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"};
>> for (int i = 0; i < loops; i++) {  // loops: 1000, 2000, 3000
>>      SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>      engine.getEnabledCipherSuites();
>>      engine.getSupportedCipherSuites();
>> }
>> ---------
>>
>> The milliseconds for each test case (less is better) look like:
>>
>>      loops   |  old    |  fixed
>>     ---------+---------+----------
>>     1000     |  2736   |  735
>>     ---------+---------+----------
>>     2000     |  3718   |  746
>>     ---------+---------+----------
>>     3000     |  4750   |  765
>>     ---------+---------+----------
>>
>> This fix improves the performance.
>>
>> The existing regression testing get passed.  No new regression test is
>> planned as this is a performance enhancement fix.
>>
>> Thanks,
>> Xuelei
>>


From xuelei.fan at oracle.com  Tue Dec 15 05:40:24 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 15 Dec 2015 13:40:24 +0800
Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE
Message-ID: <566FA7C8.9050009@oracle.com>

Hi,

Please this enhancement to the JSSE implementation:

   http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/

This change will add support for the SHA224withDSA and SHA256withDSA
algorithms in the TLS "signature_algorithms" extension in the SunJSSE
provider.  Note that this extension does not apply to TLS 1.1 and
previous versions.

Thanks,
Xuelei

From xuelei.fan at oracle.com  Tue Dec 15 05:47:20 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 15 Dec 2015 13:47:20 +0800
Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE
In-Reply-To: <566FA7C8.9050009@oracle.com>
References: <566FA7C8.9050009@oracle.com>
Message-ID: <566FA968.4000609@oracle.com>

On 12/15/2015 1:40 PM, Xuelei Fan wrote:
> Hi,
> 
> Please this enhancement to the JSSE implementation:
> 
Please review this enhancement to the JSSE implementation:

>    http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/
> 
> This change will add support for the SHA224withDSA and SHA256withDSA
> algorithms in the TLS "signature_algorithms" extension in the SunJSSE
> provider.  Note that this extension does not apply to TLS 1.1 and
> previous versions.
> 
> Thanks,
> Xuelei
> 


From weijun.wang at oracle.com  Tue Dec 15 08:09:51 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Tue, 15 Dec 2015 16:09:51 +0800
Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom
	Implementations
In-Reply-To: <566EE8C1.90700@oracle.com>
References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com>
	<5644AF03.5010704@oracle.com>
	<391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com>
	<56462436.1050602@oracle.com>
	<5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com>
	<564C7DDC.6000902@oracle.com>
	<AD10315B-DF13-41CA-A10D-91F69625BF5F@oracle.com>
	<564E02A8.5060402@oracle.com>
	<5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com>
	<B992E7C9-ECCB-4E60-9006-5FFBD4632A81@oracle.com>
	<F0855F85-6307-4D59-A213-DA7D9B9E4815@oracle.com>
	<C2B0A925-32AD-42CF-ACE5-F7F73119F0F9@oracle.com>
	<566EE8C1.90700@oracle.com>
Message-ID: <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com>

Good.

But the builder will not provide default values so you will see

  new DrbgParameters.Builder().build().getAlgorithm() == null

which means the getters still return requested values.

In this case, the algorithm will only be known after it is used for a specific DRBG, for example, SHA-256 for HashDRBG, and AES-256 for CtrDRBG.

--Max

> On Dec 15, 2015, at 12:05 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> The DrbgParameters class has 7 parameters, most of which are optional. A typical use case might involve lots of null parameters:
> 
> DrbgParameters params = new DrbgParameters(null, null, 256, false, false, nonce, null);
> 
> That seems awkward, and you have be overly careful to map the right value to each parameter.
> 
> I think this is a case where a DrbgParameters.Builder would be very useful.
> 
> --Sean


From sean.mullan at oracle.com  Tue Dec 15 15:53:45 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 15 Dec 2015 10:53:45 -0500
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
	<428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
	<CACRbFyh3VgrEVXK1-UREp_tjzs2Y1qnWXhkL5TxJDa8QUyyi9w@mail.gmail.com>
	<0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com>
Message-ID: <56703789.7060908@oracle.com>

On 12/03/2015 09:07 PM, Wang Weijun wrote:
> Or if this is too much, we can at least do the X509Extension part. If
> CertificateRequest is needed one day, we can create a new method
> Builder.certificateRequest() that returns it and deprecate the
> current request() method.
>
> Or use certificateRequest() to return byte[] and save request() for
> the future. :-)

I agree with this approach. I like the idea of moving the creation of 
Extensions to X509Extension so that they could be used independently of 
the X509Certificate.Builder API. Let's defer a CertificateRequest API 
for later.

--Sean

>
> --Max
>
>> On Dec 3, 2015, at 8:21 PM, larry mccay <larry.mccay at gmail.com>
>> wrote:
>>
>> +1 :)
>>
>> On Thu, Dec 3, 2015 at 3:31 AM, Wang Weijun
>> <weijun.wang at oracle.com> wrote: I tried.
>>
>> It's quite easy to move the new X509CertificateBuilder class into
>> java.security.cert.X509Certificate as an inner class, but I still
>> want to make Extension and CertificateRequest better.
>
> ...
>
>>
>> All these sound straightforward, worth doing?
>>
>> Thanks Max
>>
>>
>>
>

From sean.mullan at oracle.com  Tue Dec 15 21:43:14 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 15 Dec 2015 16:43:14 -0500
Subject: RFR: 8129567 - the GCM mode parameter which is used as the
	initialization vector ("IV") is set to all zeros
In-Reply-To: <e03cca02-fd10-4566-b0e6-c52fc8f1c637@default>
References: <e03cca02-fd10-4566-b0e6-c52fc8f1c637@default>
Message-ID: <56708972.6030306@oracle.com>

This fix looks fine to me. Please add a "noreg-self" label to the bug.

--Sean

On 12/11/2015 05:50 AM, Bhanu Gopularam wrote:
> Hi all,
>
> Please review a fix for following bug:
>
> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129567
>
> Issue ? Few tests are using all zero IV for GCM parameter spec which
> gives CRYPTO_MECHANISM_PARAM_INVALID error
>
> On certain platforms
>
> Solution ? Use a random IV in GCMParameterSpec in the tests
>
> webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129567/webrev.00/
>
> Thanks,
>
> Bhanu
>

From sean.mullan at oracle.com  Tue Dec 15 22:19:31 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 15 Dec 2015 17:19:31 -0500
Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom
	Implementations
In-Reply-To: <87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com>
References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com>
	<5644AF03.5010704@oracle.com>
	<391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com>
	<56462436.1050602@oracle.com>
	<5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com>
	<564C7DDC.6000902@oracle.com>
	<AD10315B-DF13-41CA-A10D-91F69625BF5F@oracle.com>
	<564E02A8.5060402@oracle.com>
	<5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com>
	<B992E7C9-ECCB-4E60-9006-5FFBD4632A81@oracle.com>
	<F0855F85-6307-4D59-A213-DA7D9B9E4815@oracle.com>
	<C2B0A925-32AD-42CF-ACE5-F7F73119F0F9@oracle.com>
	<566EE8C1.90700@oracle.com>
	<87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com>
Message-ID: <567091F3.7000200@oracle.com>

On 12/15/2015 03:09 AM, Wang Weijun wrote:
> Good.
>
> But the builder will not provide default values so you will see
>
>    new DrbgParameters.Builder().build().getAlgorithm() == null
>
> which means the getters still return requested values.

That's fine, this is no different than what the current class does.

--Sean

> In this case, the algorithm will only be known after it is used for a specific DRBG, for example, SHA-256 for HashDRBG, and AES-256 for CtrDRBG.
>
> --Max
>
>> On Dec 15, 2015, at 12:05 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> The DrbgParameters class has 7 parameters, most of which are optional. A typical use case might involve lots of null parameters:
>>
>> DrbgParameters params = new DrbgParameters(null, null, 256, false, false, nonce, null);
>>
>> That seems awkward, and you have be overly careful to map the right value to each parameter.
>>
>> I think this is a case where a DrbgParameters.Builder would be very useful.
>>
>> --Sean
>

From weijun.wang at oracle.com  Wed Dec 16 02:26:19 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 16 Dec 2015 10:26:19 +0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <56703789.7060908@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
	<428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
	<CACRbFyh3VgrEVXK1-UREp_tjzs2Y1qnWXhkL5TxJDa8QUyyi9w@mail.gmail.com>
	<0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com>
	<56703789.7060908@oracle.com>
Message-ID: <CA087A1E-5471-416D-BA93-B1EB7F9E0E24@oracle.com>

Hi All

Here is an updated webrev

  http://cr.openjdk.java.net/~weijun/8058778/webrev.05/

Spec change is at

  http://cr.openjdk.java.net/~weijun/8058778/webrev.05/specdiff/java/security/cert/package-summary.html

These changes are made:

1. The Builder is moved into java.security.cert.X509Certificate as an inner class

2. There is no more addExtension(String,String,boolean) that tries to parse input value strings (leave them to keytool). Each supported extension has its own addXXXExtension() method in java.security.cert.X509Extension. The input format is the same as the output format of X509Certificate.getXXX() for each extension type. This relieves the requirement to define interfaces for GeneralNames etc at the moment.

3. keytool directly calls X509Certificate.Builder now.

No CertificateRequest at the moment. Builder still using byte[] which is PKCS #10 encoded.

Many thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more methods later when they are needed.

--Max

> On Dec 15, 2015, at 11:53 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 12/03/2015 09:07 PM, Wang Weijun wrote:
>> Or if this is too much, we can at least do the X509Extension part. If
>> CertificateRequest is needed one day, we can create a new method
>> Builder.certificateRequest() that returns it and deprecate the
>> current request() method.
>> 
>> Or use certificateRequest() to return byte[] and save request() for
>> the future. :-)
> 
> I agree with this approach. I like the idea of moving the creation of Extensions to X509Extension so that they could be used independently of the X509Certificate.Builder API. Let's defer a CertificateRequest API for later.
> 
> --Sean


From weijun.wang at oracle.com  Wed Dec 16 07:20:41 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 16 Dec 2015 15:20:41 +0800
Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom
	Implementations
In-Reply-To: <567091F3.7000200@oracle.com>
References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com>
	<5644AF03.5010704@oracle.com>
	<391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com>
	<56462436.1050602@oracle.com>
	<5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com>
	<564C7DDC.6000902@oracle.com>
	<AD10315B-DF13-41CA-A10D-91F69625BF5F@oracle.com>
	<564E02A8.5060402@oracle.com>
	<5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com>
	<B992E7C9-ECCB-4E60-9006-5FFBD4632A81@oracle.com>
	<F0855F85-6307-4D59-A213-DA7D9B9E4815@oracle.com>
	<C2B0A925-32AD-42CF-ACE5-F7F73119F0F9@oracle.com>
	<566EE8C1.90700@oracle.com>
	<87F2B424-C68D-4166-89F1-1F010E1844AB@oracle.com>
	<567091F3.7000200@oracle.com>
Message-ID: <10E6F8D0-F090-4944-889F-2E6A19771E24@oracle.com>

Webrev updated:

   http://cr.openjdk.java.net/~weijun/8051408/webrev.02/
   http://cr.openjdk.java.net/~weijun/8051408/webrev.02/specdiff/java/security/package-summary.html

Changes:

1. DrbgParameters has a Builder now

2. No more default implementation for reseed()

3. Synchronization is now inside implementation, on engineXXX() methods

4. engineConfigure() now throws InvalidAlgorithmParameterException instead of IllegalArgumentException

5. CtrDRBG uses up all input in engineSetSeed()

Thanks
Max

   
> On Dec 16, 2015, at 6:19 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 12/15/2015 03:09 AM, Wang Weijun wrote:
>> Good.
>> 
>> But the builder will not provide default values so you will see
>> 
>>   new DrbgParameters.Builder().build().getAlgorithm() == null
>> 
>> which means the getters still return requested values.
> 
> That's fine, this is no different than what the current class does.
> 
> --Sean
> 
>> In this case, the algorithm will only be known after it is used for a specific DRBG, for example, SHA-256 for HashDRBG, and AES-256 for CtrDRBG.
>> 
>> --Max
>> 
>>> On Dec 15, 2015, at 12:05 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> The DrbgParameters class has 7 parameters, most of which are optional. A typical use case might involve lots of null parameters:
>>> 
>>> DrbgParameters params = new DrbgParameters(null, null, 256, false, false, nonce, null);
>>> 
>>> That seems awkward, and you have be overly careful to map the right value to each parameter.
>>> 
>>> I think this is a case where a DrbgParameters.Builder would be very useful.
>>> 
>>> --Sean
>> 


From bradford.wetmore at oracle.com  Wed Dec 16 19:14:08 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 16 Dec 2015 11:14:08 -0800
Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE
In-Reply-To: <566FA968.4000609@oracle.com>
References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com>
Message-ID: <5671B800.3080203@oracle.com>

The change itself looks ok, but a question on the previous code.

420:  Why is SHA224 disabled when SunMSCAPI is present?  Or 
alternatively, why is SHA224 enabled when SunMSCAPI not present? 
Shouldn't this be based on whether there is a SHA224 implementation 
available?  And if so, why are we not verifying that an implementation 
exists (getInstance("SHA256") doesn't throw exception) for the other 
algorithms also (SHA1/RSA/etc)?

The synopsis should probably be:

     Support SHA224withDSA/SHA256withDSA in TLSv1.2 \
     signature_algorithms extension

Also, note the case of the "W" in "SHA256WithDSA".

Brad


On 12/14/2015 9:47 PM, Xuelei Fan wrote:
> On 12/15/2015 1:40 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Please this enhancement to the JSSE implementation:
>>
> Please review this enhancement to the JSSE implementation:
>
>>     http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/
>>
>> This change will add support for the SHA224withDSA and SHA256withDSA
>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE
>> provider.  Note that this extension does not apply to TLS 1.1 and
>> previous versions.
>>
>> Thanks,
>> Xuelei
>>
>

From bradford.wetmore at oracle.com  Wed Dec 16 19:19:01 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 16 Dec 2015 11:19:01 -0800
Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE
In-Reply-To: <5671B800.3080203@oracle.com>
References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com>
	<5671B800.3080203@oracle.com>
Message-ID: <5671B925.3030204@oracle.com>



On 12/16/2015 11:14 AM, Bradford Wetmore wrote:
> The synopsis should probably be:
>
>      Support SHA224withDSA/SHA256withDSA in TLSv1.2 \
>      signature_algorithms extension
>
> Also, note the case of the "W" in "SHA256WithDSA".

Ignore these last two points, they've already been updated in the bug.

Brad



> Brad
>
>
> On 12/14/2015 9:47 PM, Xuelei Fan wrote:
>> On 12/15/2015 1:40 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Please this enhancement to the JSSE implementation:
>>>
>> Please review this enhancement to the JSSE implementation:
>>
>>>     http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/
>>>
>>> This change will add support for the SHA224withDSA and SHA256withDSA
>>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE
>>> provider.  Note that this extension does not apply to TLS 1.1 and
>>> previous versions.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>

From xuelei.fan at oracle.com  Wed Dec 16 23:22:00 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 17 Dec 2015 07:22:00 +0800
Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE
In-Reply-To: <5671B800.3080203@oracle.com>
References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com>
	<5671B800.3080203@oracle.com>
Message-ID: <5671F218.6080608@oracle.com>

On 12/17/2015 3:14 AM, Bradford Wetmore wrote:
> The change itself looks ok, but a question on the previous code.
> 
> 420:  Why is SHA224 disabled when SunMSCAPI is present?  Or
> alternatively, why is SHA224 enabled when SunMSCAPI not present?
SunMSCAPI does not support SHA-224 yet.

> Shouldn't this be based on whether there is a SHA224 implementation
> available?
The SHA-224 is always available with JDK providers.  But SHA224withRSA
and SHA224withDSA does not work for SunMSCAPI.  So we need to filter out
SHA-224 for SunMSCAPI.

> And if so, why are we not verifying that an implementation
> exists (getInstance("SHA256") doesn't throw exception) for the other
> algorithms also (SHA1/RSA/etc)?
> 
Need to check the full signature name.  But no checking at present as
these algorithms are supported by JDK providers except the SHA-224 based
ones.  May make improvement later.

Thanks,
Xuelei

> The synopsis should probably be:
> 
>     Support SHA224withDSA/SHA256withDSA in TLSv1.2 \
>     signature_algorithms extension
> 
> Also, note the case of the "W" in "SHA256WithDSA".
> 
> Brad
> 
> 
> On 12/14/2015 9:47 PM, Xuelei Fan wrote:
>> On 12/15/2015 1:40 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Please this enhancement to the JSSE implementation:
>>>
>> Please review this enhancement to the JSSE implementation:
>>
>>>     http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/
>>>
>>> This change will add support for the SHA224withDSA and SHA256withDSA
>>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE
>>> provider.  Note that this extension does not apply to TLS 1.1 and
>>> previous versions.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>


From bradford.wetmore at oracle.com  Wed Dec 16 23:52:39 2015
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 16 Dec 2015 15:52:39 -0800
Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE
In-Reply-To: <5671F218.6080608@oracle.com>
References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com>
	<5671B800.3080203@oracle.com> <5671F218.6080608@oracle.com>
Message-ID: <5671F947.7000500@oracle.com>



On 12/16/2015 3:22 PM, Xuelei Fan wrote:
> On 12/17/2015 3:14 AM, Bradford Wetmore wrote:
>> The change itself looks ok, but a question on the previous code.
>>
>> 420:  Why is SHA224 disabled when SunMSCAPI is present?  Or
>> alternatively, why is SHA224 enabled when SunMSCAPI not present?
> SunMSCAPI does not support SHA-224 yet.

That was my guess, however...

>> Shouldn't this be based on whether there is a SHA224 implementation
>> available?
> The SHA-224 is always available with JDK providers.  But SHA224withRSA
> and SHA224withDSA does not work for SunMSCAPI.  So we need to filter out
> SHA-224 for SunMSCAPI.

         if (Security.getProvider("SunMSCAPI") == null) {
             supports(HashAlgorithm.SHA224,      SignatureAlgorithm.DSA,
                  "SHA224withDSA",        --p);

Those two algs are always being filtered out regardless of whether other 
providers might support it.  For all platforms, the Sun provider is 
available for SHA224withDSA/SHA256withDSA, right?

     map.put("Signature.SHA224withDSA",
         "sun.security.provider.DSA$SHA224withDSA");
     map.put("Signature.SHA256withDSA",
         "sun.security.provider.DSA$SHA256withDSA");

So if SunMSCAPI is registered as an active provider (on a Windows 
platform), SHA224/SHA256 will be disabled.  This doesn't seem right.

>> And if so, why are we not verifying that an implementation
>> exists (getInstance("SHA256") doesn't throw exception) for the other
>> algorithms also (SHA1/RSA/etc)?
>>
> Need to check the full signature name.  But no checking at present as
> these algorithms are supported by JDK providers except the SHA-224 based
> ones.  May make improvement later.

This does require that at least the Sun provider always be available then.

Brad



>
> Thanks,
> Xuelei
>
>> The synopsis should probably be:
>>
>>      Support SHA224withDSA/SHA256withDSA in TLSv1.2 \
>>      signature_algorithms extension
>>
>> Also, note the case of the "W" in "SHA256WithDSA".
>>
>> Brad
>>
>>
>> On 12/14/2015 9:47 PM, Xuelei Fan wrote:
>>> On 12/15/2015 1:40 PM, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Please this enhancement to the JSSE implementation:
>>>>
>>> Please review this enhancement to the JSSE implementation:
>>>
>>>>      http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/
>>>>
>>>> This change will add support for the SHA224withDSA and SHA256withDSA
>>>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE
>>>> provider.  Note that this extension does not apply to TLS 1.1 and
>>>> previous versions.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>>
>

From xuelei.fan at oracle.com  Thu Dec 17 06:51:43 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 17 Dec 2015 14:51:43 +0800
Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE
In-Reply-To: <5671F947.7000500@oracle.com>
References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com>
	<5671B800.3080203@oracle.com> <5671F218.6080608@oracle.com>
	<5671F947.7000500@oracle.com>
Message-ID: <56725B7F.6090806@oracle.com>

On 12/17/2015 7:52 AM, Bradford Wetmore wrote:
> 
> 
> On 12/16/2015 3:22 PM, Xuelei Fan wrote:
>> On 12/17/2015 3:14 AM, Bradford Wetmore wrote:
>>> The change itself looks ok, but a question on the previous code.
>>>
>>> 420:  Why is SHA224 disabled when SunMSCAPI is present?  Or
>>> alternatively, why is SHA224 enabled when SunMSCAPI not present?
>> SunMSCAPI does not support SHA-224 yet.
> 
> That was my guess, however...
> 
>>> Shouldn't this be based on whether there is a SHA224 implementation
>>> available?
>> The SHA-224 is always available with JDK providers.  But SHA224withRSA
>> and SHA224withDSA does not work for SunMSCAPI.  So we need to filter out
>> SHA-224 for SunMSCAPI.
> 
>         if (Security.getProvider("SunMSCAPI") == null) {
>             supports(HashAlgorithm.SHA224,      SignatureAlgorithm.DSA,
>                  "SHA224withDSA",        --p);
> 
> Those two algs are always being filtered out regardless of whether other
> providers might support it.  For all platforms, the Sun provider is
> available for SHA224withDSA/SHA256withDSA, right?
> 
>     map.put("Signature.SHA224withDSA",
>         "sun.security.provider.DSA$SHA224withDSA");
>     map.put("Signature.SHA256withDSA",
>         "sun.security.provider.DSA$SHA256withDSA");
> 
> So if SunMSCAPI is registered as an active provider (on a Windows
> platform), SHA224/SHA256 will be disabled.  This doesn't seem right.
> 
Right.  It is a compromise solution to remove SHA224 completely, even
other providers support it.   If SHA224withRSA is enabled, and SunMSCAPI
is preferred at the same time, there is a problem per current
implementation.  During TLS handshaking process, RSA private will be
used in SunMSCAPI provider at first (for example, for server
authentication cert), and then SHA224withRSA in other providers (Say
SunJCE) will be used for signature.  However, as the RSA private key is
in MSCAPI, no way to use SHA224withRSA in providers other than SunMSCAP.
 Problem happens, see JDK-8064330.

We might want to take SHA224withRSA back later if required.

>>> And if so, why are we not verifying that an implementation
>>> exists (getInstance("SHA256") doesn't throw exception) for the other
>>> algorithms also (SHA1/RSA/etc)?
>>>
>> Need to check the full signature name.  But no checking at present as
>> these algorithms are supported by JDK providers except the SHA-224 based
>> ones.  May make improvement later.
> 
> This does require that at least the Sun provider always be available then.
> 
May be, if SunJCE is used.

Thanks,
Xuelei

> Brad
> 
> 
> 
>>
>> Thanks,
>> Xuelei
>>
>>> The synopsis should probably be:
>>>
>>>      Support SHA224withDSA/SHA256withDSA in TLSv1.2 \
>>>      signature_algorithms extension
>>>
>>> Also, note the case of the "W" in "SHA256WithDSA".
>>>
>>> Brad
>>>
>>>
>>> On 12/14/2015 9:47 PM, Xuelei Fan wrote:
>>>> On 12/15/2015 1:40 PM, Xuelei Fan wrote:
>>>>> Hi,
>>>>>
>>>>> Please this enhancement to the JSSE implementation:
>>>>>
>>>> Please review this enhancement to the JSSE implementation:
>>>>
>>>>>      http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/
>>>>>
>>>>> This change will add support for the SHA224withDSA and SHA256withDSA
>>>>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE
>>>>> provider.  Note that this extension does not apply to TLS 1.1 and
>>>>> previous versions.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>>
>>


From mandy.chung at oracle.com  Thu Dec 17 07:26:08 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 16 Dec 2015 23:26:08 -0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <CA087A1E-5471-416D-BA93-B1EB7F9E0E24@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
	<428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
	<CACRbFyh3VgrEVXK1-UREp_tjzs2Y1qnWXhkL5TxJDa8QUyyi9w@mail.gmail.com>
	<0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com>
	<56703789.7060908@oracle.com>
	<CA087A1E-5471-416D-BA93-B1EB7F9E0E24@oracle.com>
Message-ID: <15164C87-44AC-4422-9427-4B7EB1A7093D@oracle.com>

Hi Max,

Very high level comments:
- Builder::selfSign and Builder::sign are the two methods building the X509Certificate.

Both @throws java.lang.IllegalStateException - if the builder is initialized with one of the asCA methods 

It reads to me that there is no other method to generate a certificate from a builder created from Builder::fromKeyPair factory method.

- is clearExtensions needed only for reusing the Builder?  Would it be reasonable to require it to create a Builder that I suppose it?s not too expensive?  In that case, the clearExtensions is not needed.

Extension::newSubjectAlternativeNameExtension(boolean isCritical, List<?>... names)
Extension::newIssuerAlternativeNameExtension(boolean isCritical, List<?>... names)
Extension::newSubjectInformationAccessExtension(List<?>... accessDescriptions)
Extension::newAuthorityInformationAccessExtension(List<?>... accessDescriptions)
- this takes List<?> with 3 entries, each of which is of a specified type.

There may be other better alternatives to define this API.  A builder may fit well that can take 3 parameters for each name/accessDescription such that it can be statically checked.  Have you considered other options?

Mandy


> On Dec 15, 2015, at 6:26 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> Hi All
> 
> Here is an updated webrev
> 
>  http://cr.openjdk.java.net/~weijun/8058778/webrev.05/
> 
> Spec change is at
> 
>  http://cr.openjdk.java.net/~weijun/8058778/webrev.05/specdiff/java/security/cert/package-summary.html
> 
> These changes are made:
> 
> 1. The Builder is moved into java.security.cert.X509Certificate as an inner class
> 
> 2. There is no more addExtension(String,String,boolean) that tries to parse input value strings (leave them to keytool). Each supported extension has its own addXXXExtension() method in java.security.cert.X509Extension. The input format is the same as the output format of X509Certificate.getXXX() for each extension type. This relieves the requirement to define interfaces for GeneralNames etc at the moment.
> 
> 3. keytool directly calls X509Certificate.Builder now.
> 
> No CertificateRequest at the moment. Builder still using byte[] which is PKCS #10 encoded.
> 
> Many thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more methods later when they are needed.
> 
> --Max
> 


From weijun.wang at oracle.com  Thu Dec 17 07:48:30 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 17 Dec 2015 15:48:30 +0800
Subject: RFR 8058778: New APIs for some keytool functions
In-Reply-To: <15164C87-44AC-4422-9427-4B7EB1A7093D@oracle.com>
References: <CD106C73-8699-415F-91C8-C79164F07914@oracle.com>
	<BFD69E41-C76F-4CCE-8652-AC82D89D213C@oracle.com>
	<A364B5E7-79F4-4FB9-9868-7D80DBA2B58D@oracle.com>
	<CACRbFygShgx03NhU-pbUJxVju2BRX1ajMP5P9hBxNbuXihDZUA@mail.gmail.com>
	<428C6B73-68AD-4168-BE1D-97DC2A06460A@oracle.com>
	<CACRbFyh3VgrEVXK1-UREp_tjzs2Y1qnWXhkL5TxJDa8QUyyi9w@mail.gmail.com>
	<0DBE13DD-6680-4CA3-B8E8-8897966E0860@oracle.com>
	<56703789.7060908@oracle.com>
	<CA087A1E-5471-416D-BA93-B1EB7F9E0E24@oracle.com>
	<15164C87-44AC-4422-9427-4B7EB1A7093D@oracle.com>
Message-ID: <E998B408-631D-4D3D-8150-2D079622FB03@oracle.com>


> On Dec 17, 2015, at 3:26 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hi Max,
> 
> Very high level comments:
> - Builder::selfSign and Builder::sign are the two methods building the X509Certificate.
> 
> Both @throws java.lang.IllegalStateException - if the builder is initialized with one of the asCA methods 
> 
> It reads to me that there is no other method to generate a certificate from a builder created from Builder::fromKeyPair factory method.

Not sure what you are asking about.

selfSign() returns a self-signed certificate. If you want to get a CA-signed one, you run certificateRequest() and send the output byte[] to an asCA Builder and that builder can sign() it.

> 
> - is clearExtensions needed only for reusing the Builder?  

Yes.

> Would it be reasonable to require it to create a Builder that I suppose it?s not too expensive?  In that case, the clearExtensions is not needed.

Sounds correct.

> 
> Extension::newSubjectAlternativeNameExtension(boolean isCritical, List<?>... names)
> Extension::newIssuerAlternativeNameExtension(boolean isCritical, List<?>... names)
> Extension::newSubjectInformationAccessExtension(List<?>... accessDescriptions)
> Extension::newAuthorityInformationAccessExtension(List<?>... accessDescriptions)
> - this takes List<?> with 3 entries, each of which is of a specified type.
> 
> There may be other better alternatives to define this API.  A builder may fit well that can take 3 parameters for each name/accessDescription such that it can be statically checked.  Have you considered other options?

I designed the methods to be consistent with X509Certificate methods, like

   Collection<List<?>> getSubjectAlternativeNames()

and secretly hoped that if people can live with these methods they can also live with my new ones.

I know it's ugly but if enhanced I am not sure how far I should go. Should it be these?

   interface GeneralName {}
   static GeneralName newURIName(URI);
   static GeneralName newDnsName(String host);
   ...
   static newSubjectAlternativeNameExtension(boolean isCritical, GenralName... names);
   class AccessDescription { String oidMethods, GeneralName location);
   static newAuthorityInformationAccessExtension(AccessDescription... accessDescriptions);

I tried it but I don't like inventing too many new classes.

Thanks
Max

> 
> Mandy
> 
> 
>> On Dec 15, 2015, at 6:26 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>> 
>> Hi All
>> 
>> Here is an updated webrev
>> 
>> http://cr.openjdk.java.net/~weijun/8058778/webrev.05/
>> 
>> Spec change is at
>> 
>> http://cr.openjdk.java.net/~weijun/8058778/webrev.05/specdiff/java/security/cert/package-summary.html
>> 
>> These changes are made:
>> 
>> 1. The Builder is moved into java.security.cert.X509Certificate as an inner class
>> 
>> 2. There is no more addExtension(String,String,boolean) that tries to parse input value strings (leave them to keytool). Each supported extension has its own addXXXExtension() method in java.security.cert.X509Extension. The input format is the same as the output format of X509Certificate.getXXX() for each extension type. This relieves the requirement to define interfaces for GeneralNames etc at the moment.
>> 
>> 3. keytool directly calls X509Certificate.Builder now.
>> 
>> No CertificateRequest at the moment. Builder still using byte[] which is PKCS #10 encoded.
>> 
>> Many thanks to Mandy, Larry, and Sean for your comments. Mike, we will add more methods later when they are needed.
>> 
>> --Max
>> 
> 


From bhanu.prakash.gopularam at oracle.com  Fri Dec 18 05:41:11 2015
From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam)
Date: Thu, 17 Dec 2015 21:41:11 -0800 (PST)
Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply
	with FIPS 186-4
In-Reply-To: <e03cca02-fd10-4566-b0e6-c52fc8f1c637@default>
References: <e03cca02-fd10-4566-b0e6-c52fc8f1c637@default>
Message-ID: <0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default>

Hi all,

 

Please review a fix for following bug:

 

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

 

Issue - Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is failing because RSAKeyGenParameterSpec 

public exponent is not accordance with FIPS 186-4 guidance

 

Solution - Used proper value for exponent based on reference from FIPS 186-4, section B-2.

 

webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/ 

 

Thanks,

Bhanu

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151217/3ce920dd/attachment.html>

From sean.mullan at oracle.com  Fri Dec 18 15:35:04 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 18 Dec 2015 10:35:04 -0500
Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable
In-Reply-To: <566F843B.4090605@oracle.com>
References: <565D9774.9000304@oracle.com> <566F2584.5070502@oracle.com>
	<566F843B.4090605@oracle.com>
Message-ID: <567427A8.5000105@oracle.com>

Here are a few other other comments on the code:

SSLContextImpl:
   - I noticed that SSLContext.init does not specify how it handles 
empty arrays, and you have changed the code so that an empty 
TrustManager array is treated like they are null - is this change in 
behavior a compatibility issue at all? Could you file a follow-on issue 
to clarify the behavior of SSLContext.init as to how it should handle 
empty arrays?

   - are there any race conditions that you need to worry about now that 
you have removed the synchronized blocks from 
getSupportedCipherSuiteList and getDefaultCipherSuite?

   - on lines 781 and 789, an empty array is created and discarded if 
there is not an exception thrown. It would be better to only create the 
empty array when an exception is thrown (move it into the catch block).

--Sean


On 12/14/2015 10:08 PM, Xuelei Fan wrote:
> On 12/15/2015 4:24 AM, Sean Mullan wrote:
>> Hi Xuelei,
>>
>> For JDK 9, the EC impl is defined to be in its own module
>> (jdk.crypto.ec). How does it affect this fix if that module is not
>> available/installed?
>>
> The SunJSSE provider would not support dynamically loading of crypto
> providers/modules.  At present, there are two providers that supports EC
> implementation, SunEC (jdk.crypto.ec) and SunPKCS11 (jdk.crypto.pkcs11).
>   If no EC provider, EC cipher suites would not be available to use.
> That's to say, EC cipher suites would not be enabled by default, and
> cannot be used for handshaking.  In the fix,
> JsseJce#EcAvailability.isAvailable is used to check the availability of
> EC crypto impl.
>
> Xuelei
>
>> --Sean
>>
>> On 12/01/2015 07:49 AM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8133070:
>>>
>>>      http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/
>>>
>>> In (Open)JDK 6, EC cipher suites get supported by Java.  However, there
>>> is no default EC provider in JDK 6 at that time.  In order to support
>>> third part's EC algorithm JCE provider dynamically, it is hard-coded to
>>> check the cipher suite availability dynamically for EC algorithms in
>>> SunJSSE provider.
>>>
>>> Here is an example update in CipherSuite.java for the checking:
>>>
>>>     -   static final boolean DYNAMIC_AVAILABILITY = false;
>>>     +   static final boolean DYNAMIC_AVAILABILITY = true;
>>>
>>> The dynamically checking impacts the performance significantly as:
>>> 1. the check of the availability is expensive as it involves crypto
>>> operations.
>>> 2. a cache is used to maintain the availability of bulk ciphers in order
>>> to mitigate the #1 performance impact.  However, access and update to
>>> the cache need to be synchronized.
>>> 3. in order to support dynamically checking, the cache may be cleared if
>>> a particular cipher is not found or a new SSLContext is generated. As
>>> bring the performance impact of #1 back again.
>>>
>>> Later, AEAD algorithm is defined by Java.  The same mechanism is used to
>>> support AEAD ciphers.
>>>
>>> Now, EC and GCM algorithms are supported in JDK crypto providers. The
>>> hard-coded checking can get improved.  This fix updates:
>>> 1. remove the dynamically checking of cipher suite availability.
>>> 2. remove the cipher suite availability cache accordingly (need no
>>> synchronization accordingly)
>>> 3. other updates that impact by the availability checking.
>>>
>>> The performance improvement is tested with the following simple case.
>>> Run the following code 1000, 2000, 3000 times in single thread mode and
>>> measure the millisecond for each:
>>>
>>> ---------
>>> String[] cipherSuites =
>>>           {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"};
>>> for (int i = 0; i < loops; i++) {  // loops: 1000, 2000, 3000
>>>       SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>>       engine.getEnabledCipherSuites();
>>>       engine.getSupportedCipherSuites();
>>> }
>>> ---------
>>>
>>> The milliseconds for each test case (less is better) look like:
>>>
>>>       loops   |  old    |  fixed
>>>      ---------+---------+----------
>>>      1000     |  2736   |  735
>>>      ---------+---------+----------
>>>      2000     |  3718   |  746
>>>      ---------+---------+----------
>>>      3000     |  4750   |  765
>>>      ---------+---------+----------
>>>
>>> This fix improves the performance.
>>>
>>> The existing regression testing get passed.  No new regression test is
>>> planned as this is a performance enhancement fix.
>>>
>>> Thanks,
>>> Xuelei
>>>
>

From sean.mullan at oracle.com  Fri Dec 18 20:20:20 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 18 Dec 2015 15:20:20 -0500
Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to
	comply with FIPS 186-4
In-Reply-To: <0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default>
References: <e03cca02-fd10-4566-b0e6-c52fc8f1c637@default>
	<0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default>
Message-ID: <56746A84.60106@oracle.com>

The fix looks good, although this test is already on the ProblemList due 
to JDK-8074580. Do you know if that bug is caused by the same issue? The 
underlying PKCS11 error is different (maybe due to a different Solaris 
version?), but it looks like an identical stack trace. It would be good 
to also remove it from the ProblemList and close the other bug if it is 
a duplicate issue.

--Sean

On 12/18/2015 12:41 AM, Bhanu Gopularam wrote:
> Hi all,
>
> Please review a fix for following bug:
>
> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129560
>
> Issue ? Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is
> failing because RSAKeyGenParameterSpec
>
> public exponent is not accordance with FIPS 186-4 guidance
>
> Solution ? Used proper value for exponent based on reference from FIPS
> 186-4, section B-2.
>
> webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/
>
> Thanks,
>
> Bhanu
>

From sean.mullan at oracle.com  Fri Dec 18 21:04:16 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 18 Dec 2015 16:04:16 -0500
Subject: Code Review Request 8049321 Support SHA256WithDSA in JSSE
In-Reply-To: <56725B7F.6090806@oracle.com>
References: <566FA7C8.9050009@oracle.com> <566FA968.4000609@oracle.com>
	<5671B800.3080203@oracle.com> <5671F218.6080608@oracle.com>
	<5671F947.7000500@oracle.com> <56725B7F.6090806@oracle.com>
Message-ID: <567474D0.5060207@oracle.com>

This explanation makes sense to me and the fix looks fine.

--Sean

On 12/17/2015 01:51 AM, Xuelei Fan wrote:
> On 12/17/2015 7:52 AM, Bradford Wetmore wrote:
>>
>>
>> On 12/16/2015 3:22 PM, Xuelei Fan wrote:
>>> On 12/17/2015 3:14 AM, Bradford Wetmore wrote:
>>>> The change itself looks ok, but a question on the previous code.
>>>>
>>>> 420:  Why is SHA224 disabled when SunMSCAPI is present?  Or
>>>> alternatively, why is SHA224 enabled when SunMSCAPI not present?
>>> SunMSCAPI does not support SHA-224 yet.
>>
>> That was my guess, however...
>>
>>>> Shouldn't this be based on whether there is a SHA224 implementation
>>>> available?
>>> The SHA-224 is always available with JDK providers.  But SHA224withRSA
>>> and SHA224withDSA does not work for SunMSCAPI.  So we need to filter out
>>> SHA-224 for SunMSCAPI.
>>
>>          if (Security.getProvider("SunMSCAPI") == null) {
>>              supports(HashAlgorithm.SHA224,      SignatureAlgorithm.DSA,
>>                   "SHA224withDSA",        --p);
>>
>> Those two algs are always being filtered out regardless of whether other
>> providers might support it.  For all platforms, the Sun provider is
>> available for SHA224withDSA/SHA256withDSA, right?
>>
>>      map.put("Signature.SHA224withDSA",
>>          "sun.security.provider.DSA$SHA224withDSA");
>>      map.put("Signature.SHA256withDSA",
>>          "sun.security.provider.DSA$SHA256withDSA");
>>
>> So if SunMSCAPI is registered as an active provider (on a Windows
>> platform), SHA224/SHA256 will be disabled.  This doesn't seem right.
>>
> Right.  It is a compromise solution to remove SHA224 completely, even
> other providers support it.   If SHA224withRSA is enabled, and SunMSCAPI
> is preferred at the same time, there is a problem per current
> implementation.  During TLS handshaking process, RSA private will be
> used in SunMSCAPI provider at first (for example, for server
> authentication cert), and then SHA224withRSA in other providers (Say
> SunJCE) will be used for signature.  However, as the RSA private key is
> in MSCAPI, no way to use SHA224withRSA in providers other than SunMSCAP.
>   Problem happens, see JDK-8064330.
>
> We might want to take SHA224withRSA back later if required.
>
>>>> And if so, why are we not verifying that an implementation
>>>> exists (getInstance("SHA256") doesn't throw exception) for the other
>>>> algorithms also (SHA1/RSA/etc)?
>>>>
>>> Need to check the full signature name.  But no checking at present as
>>> these algorithms are supported by JDK providers except the SHA-224 based
>>> ones.  May make improvement later.
>>
>> This does require that at least the Sun provider always be available then.
>>
> May be, if SunJCE is used.
>
> Thanks,
> Xuelei
>
>> Brad
>>
>>
>>
>>>
>>> Thanks,
>>> Xuelei
>>>
>>>> The synopsis should probably be:
>>>>
>>>>       Support SHA224withDSA/SHA256withDSA in TLSv1.2 \
>>>>       signature_algorithms extension
>>>>
>>>> Also, note the case of the "W" in "SHA256WithDSA".
>>>>
>>>> Brad
>>>>
>>>>
>>>> On 12/14/2015 9:47 PM, Xuelei Fan wrote:
>>>>> On 12/15/2015 1:40 PM, Xuelei Fan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please this enhancement to the JSSE implementation:
>>>>>>
>>>>> Please review this enhancement to the JSSE implementation:
>>>>>
>>>>>>       http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/
>>>>>>
>>>>>> This change will add support for the SHA224withDSA and SHA256withDSA
>>>>>> algorithms in the TLS "signature_algorithms" extension in the SunJSSE
>>>>>> provider.  Note that this extension does not apply to TLS 1.1 and
>>>>>> previous versions.
>>>>>>
>>>>>> Thanks,
>>>>>> Xuelei
>>>>>>
>>>>>
>>>
>

From anthony.scarpino at oracle.com  Fri Dec 18 22:03:34 2015
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 18 Dec 2015 14:03:34 -0800
Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to
	comply with FIPS 186-4
In-Reply-To: <56746A84.60106@oracle.com>
References: <e03cca02-fd10-4566-b0e6-c52fc8f1c637@default>
	<0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default>
	<56746A84.60106@oracle.com>
Message-ID: <AC1E1F65-CDC5-466F-9DDE-9633F9F27F43@oracle.com>

The problems are different. The PKCS11 error means everything in this case. 

Tony

> On Dec 18, 2015, at 12:20 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> The fix looks good, although this test is already on the ProblemList due to JDK-8074580. Do you know if that bug is caused by the same issue? The underlying PKCS11 error is different (maybe due to a different Solaris version?), but it looks like an identical stack trace. It would be good to also remove it from the ProblemList and close the other bug if it is a duplicate issue.
> 
> --Sean
> 
>> On 12/18/2015 12:41 AM, Bhanu Gopularam wrote:
>> Hi all,
>> 
>> Please review a fix for following bug:
>> 
>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129560
>> 
>> Issue ? Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is
>> failing because RSAKeyGenParameterSpec
>> 
>> public exponent is not accordance with FIPS 186-4 guidance
>> 
>> Solution ? Used proper value for exponent based on reference from FIPS
>> 186-4, section B-2.
>> 
>> webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/
>> 
>> Thanks,
>> 
>> Bhanu
>> 

From xuelei.fan at oracle.com  Sat Dec 19 16:06:24 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sun, 20 Dec 2015 00:06:24 +0800
Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable
In-Reply-To: <567427A8.5000105@oracle.com>
References: <565D9774.9000304@oracle.com> <566F2584.5070502@oracle.com>
	<566F843B.4090605@oracle.com> <567427A8.5000105@oracle.com>
Message-ID: <56758080.1000703@oracle.com>

new webrev: http://cr.openjdk.java.net/~xuelei/8133070/webrev.01/

Updates to webrev.00:
Re-org the get methods of SSLContextImpl so as to avoid repeated
initialization of instance fields.

On 12/18/2015 11:35 PM, Sean Mullan wrote:
> Here are a few other other comments on the code:
> 
> SSLContextImpl:
>   - I noticed that SSLContext.init does not specify how it handles empty
> arrays, and you have changed the code so that an empty TrustManager
> array is treated like they are null - is this change in behavior a
> compatibility issue at all? Could you file a follow-on issue to clarify
> the behavior of SSLContext.init as to how it should handle empty arrays?
> 
It's a bug of my update. Empty means no trust manager, which is
different from using the default trust manager.

I removed this update.

>   - are there any race conditions that you need to worry about now that
> you have removed the synchronized blocks from
> getSupportedCipherSuiteList and getDefaultCipherSuite?
> 
May be initialized repeatedly.  Should be OK as there is only one
instance for the to-be-assigned value.

The code can be more straightforward and effective.  I moved the impls
into sub-classes.

>   - on lines 781 and 789, an empty array is created and discarded if
> there is not an exception thrown. It would be better to only create the
> empty array when an exception is thrown (move it into the catch block).
> 
Updated.

Thanks,
Xuelei

> --Sean
> 
> 
> On 12/14/2015 10:08 PM, Xuelei Fan wrote:
>> On 12/15/2015 4:24 AM, Sean Mullan wrote:
>>> Hi Xuelei,
>>>
>>> For JDK 9, the EC impl is defined to be in its own module
>>> (jdk.crypto.ec). How does it affect this fix if that module is not
>>> available/installed?
>>>
>> The SunJSSE provider would not support dynamically loading of crypto
>> providers/modules.  At present, there are two providers that supports EC
>> implementation, SunEC (jdk.crypto.ec) and SunPKCS11 (jdk.crypto.pkcs11).
>>   If no EC provider, EC cipher suites would not be available to use.
>> That's to say, EC cipher suites would not be enabled by default, and
>> cannot be used for handshaking.  In the fix,
>> JsseJce#EcAvailability.isAvailable is used to check the availability of
>> EC crypto impl.
>>
>> Xuelei
>>
>>> --Sean
>>>
>>> On 12/01/2015 07:49 AM, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Please review the fix for JDK-8133070:
>>>>
>>>>      http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/
>>>>
>>>> In (Open)JDK 6, EC cipher suites get supported by Java.  However, there
>>>> is no default EC provider in JDK 6 at that time.  In order to support
>>>> third part's EC algorithm JCE provider dynamically, it is hard-coded to
>>>> check the cipher suite availability dynamically for EC algorithms in
>>>> SunJSSE provider.
>>>>
>>>> Here is an example update in CipherSuite.java for the checking:
>>>>
>>>>     -   static final boolean DYNAMIC_AVAILABILITY = false;
>>>>     +   static final boolean DYNAMIC_AVAILABILITY = true;
>>>>
>>>> The dynamically checking impacts the performance significantly as:
>>>> 1. the check of the availability is expensive as it involves crypto
>>>> operations.
>>>> 2. a cache is used to maintain the availability of bulk ciphers in
>>>> order
>>>> to mitigate the #1 performance impact.  However, access and update to
>>>> the cache need to be synchronized.
>>>> 3. in order to support dynamically checking, the cache may be
>>>> cleared if
>>>> a particular cipher is not found or a new SSLContext is generated. As
>>>> bring the performance impact of #1 back again.
>>>>
>>>> Later, AEAD algorithm is defined by Java.  The same mechanism is
>>>> used to
>>>> support AEAD ciphers.
>>>>
>>>> Now, EC and GCM algorithms are supported in JDK crypto providers. The
>>>> hard-coded checking can get improved.  This fix updates:
>>>> 1. remove the dynamically checking of cipher suite availability.
>>>> 2. remove the cipher suite availability cache accordingly (need no
>>>> synchronization accordingly)
>>>> 3. other updates that impact by the availability checking.
>>>>
>>>> The performance improvement is tested with the following simple case.
>>>> Run the following code 1000, 2000, 3000 times in single thread mode and
>>>> measure the millisecond for each:
>>>>
>>>> ---------
>>>> String[] cipherSuites =
>>>>           {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"};
>>>> for (int i = 0; i < loops; i++) {  // loops: 1000, 2000, 3000
>>>>       SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>>>       engine.getEnabledCipherSuites();
>>>>       engine.getSupportedCipherSuites();
>>>> }
>>>> ---------
>>>>
>>>> The milliseconds for each test case (less is better) look like:
>>>>
>>>>       loops   |  old    |  fixed
>>>>      ---------+---------+----------
>>>>      1000     |  2736   |  735
>>>>      ---------+---------+----------
>>>>      2000     |  3718   |  746
>>>>      ---------+---------+----------
>>>>      3000     |  4750   |  765
>>>>      ---------+---------+----------
>>>>
>>>> This fix improves the performance.
>>>>
>>>> The existing regression testing get passed.  No new regression test is
>>>> planned as this is a performance enhancement fix.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>


From sibabrata.sahoo at oracle.com  Sat Dec 19 20:04:26 2015
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Sat, 19 Dec 2015 12:04:26 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <A5CD3850-3E07-4647-B7E0-855AA6CFEEC5@oracle.com>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
	<566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com>
	<62346504-1078-4ccd-9188-29dcd288f269@default>
	<A5CD3850-3E07-4647-B7E0-855AA6CFEEC5@oracle.com>
Message-ID: <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default>

Hi Mandy/Max,

Please review the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/

"3rd party security providers" Test change includes:
- Test are converted to use TestNG framework.
- java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository.
- Common reusable operations moved to "SecurityUtils.java"
- All the following comments associated.


Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes:
- Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed.
- Test converted to use TestNG framework.

Thanks,
Siba

-----Original Message-----
From: Mandy Chung 
Sent: Wednesday, December 09, 2015 11:55 PM
To: Sibabrata Sahoo
Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Some high-level comment:
1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java.  The Jigsaw prefix is not needed.
2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider.  [1] is a simple test for you to get started.

Some comments on JigsawSecurityUtils.java:
71         Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o));

this can be replaced with 
    Arrays.stream(options).collect(Collectors.joining(SPACE));

111         System.out.println(String.format(

You can do:  System.out.format(?.) instead;

Mandy
[1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java

> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> Hi Valerie,
> 
> Here is the updated webrev: 
> http://cr.openjdk.java.net/~ntv/siba/webrev.00/
> 
> Changes applied as per previous comments.
> - File names are modified and do not include the term JCE.
> - Source folder structure is flat now and all belongs to "java/security/Provider" folder.
> - Sign jar functionality removed.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Valerie Peng
> Sent: Wednesday, December 09, 2015 5:37 AM
> To: Sibabrata Sahoo
> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan 
> Bateman
> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
> providers if they are in signed/unsigned modular JARs
> 
> Hi Siba,
> 
> Here are some nits:
> 
> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms.
> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers).
> You can remove a lot of code as a result.
> Also, your directory seems a bit deep, e.g. 
> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way.
> 
> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible?
> 
> Thanks,
> Valerie
> 
> On 12/8/2015 2:04 PM, Valerie Peng wrote:
>> Right, that'd be my expectation as well. Sounds like everything works.
>> I will change to look at your latest webrev.
>> Valerie
>> 
>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
>>> Hi Valerie,
>>> 
>>> Here is the updated webrev: 
>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>>> 
>>> Now the modular behavior for the test works as per expectation 
>>> through JAKE build with the following condition.
>>> If the provider jar is available under ModulePath then the 
>>> "java.security" file should have the provider configuration entry as 
>>> ProviderName while in case of ClassPath the entry should hold the 
>>> full class name.
>>> 
>>> Thanks,
>>> Siba
>>> 
>>> -----Original Message-----
>>> From: Valerie Peng
>>> Sent: Tuesday, December 08, 2015 4:46 AM
>>> To: Sibabrata Sahoo
>>> Cc: Alan Bateman; security-dev at openjdk.java.net; 
>>> jigsaw-dev at openjdk.java.net
>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>>> providers if they are in signed/unsigned modular JARs
>>> 
>>> Siba,
>>> 
>>> I have just started to review this webrev and not done yet.
>>> As for your question, the java.security file in OpenJDK9 still uses 
>>> the provider class names instead of provider names. Are you talking 
>>> about the java.security file in Jigsaw? Which build (OpenJDK or
>>> Jigsaw) have you tested against. I am pretty sure that I tested the 
>>> 3rd party provider on classpath setting when I worked on the 7191662 
>>> changes.
>>> 
>>> Supposedly, if the jar files are available on class path, then you 
>>> should specify its full *class name* in the java.security file for 
>>> it to be instantiated. Otherwise, how would it find the class? Only 
>>> the classes discovered by ServiceLoader can be identified using the 
>>> provider name (which is different from the class name referred 
>>> above). So, in your scenario, that would be 
>>> "provider.TestJCEProvider" instead of "TEST".
>>> 
>>> If you still run into problems, try enable the java security debug 
>>> flag and u should get a good  idea why it isn't loaded. Let me know 
>>> if you still have questions.
>>> 
>>> Thanks,
>>> Valerie
>>> 
>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>>>> I would like to know more about this. As far, I can see the 
>>>> "java.security" provider configuration available with JDK9, it 
>>>> holds provider names instead of provider class names. In that case 
>>>> how it resolve the fall back?
>>>> 
>>>> Thanks,
>>>> Siba
>>>> 
>>>> -----Original Message-----
>>>> From: Alan Bateman
>>>> Sent: Monday, November 30, 2015 4:54 PM
>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; 
>>>> jigsaw-dev at openjdk.java.net
>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party 
>>>> security providers if they are in signed/unsigned modular JARs
>>>> 
>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>>>> Here is the updated webrev:
>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>>> 
>>>>> I have one question:
>>>>> What should be the behavior when the older version of 3rd party 
>>>>> JCE provider jar file(without service descriptor
>>>>> "META-INF/services/*"&   working with<= JDK8) configured by 
>>>>> "java.security" file, will be place in CLASS_PATH, running through
>>>>> JDK9 and the client is using Security.getProvider() to look for 
>>>>> the provider?
>>>>> 
>>>>> Currently the scenario fails to find the JCE provider. Is this 
>>>>> right behavior? If it is, then jdk9 is not backward compatible to 
>>>>> find the security provider provided through older jar files from 
>>>>> CLASS_PATH.
>>>>> 
>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this 
>>>> point by falling back and attempting to load the class name
>>>> specified via the security.provider.<N>   properties in the 
>>>> java.security file. I'm sure Valerie can say more about this.
>>>> 
>>>> -Alan


From sibabrata.sahoo at oracle.com  Sun Dec 20 06:10:51 2015
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Sat, 19 Dec 2015 22:10:51 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
	<566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com>
	<62346504-1078-4ccd-9188-29dcd288f269@default>
	<A5CD3850-3E07-4647-B7E0-855AA6CFEEC5@oracle.com>
	<62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default>
Message-ID: <f84c49d6-da22-40e3-a82d-37c51d98c422@default>

Hi Mandy/Max,

Here is the updated webrev with very minor change over previous: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.04/

Thanks
Siba

-----Original Message-----
From: Sibabrata Sahoo 
Sent: Sunday, December 20, 2015 1:34 AM
To: Mandy Chung; Weijun Wang
Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net
Subject: RE: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Hi Mandy/Max,

Please review the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/

"3rd party security providers" Test change includes:
- Test are converted to use TestNG framework.
- java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository.
- Common reusable operations moved to "SecurityUtils.java"
- All the following comments associated.


Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes:
- Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed.
- Test converted to use TestNG framework.

Thanks,
Siba

-----Original Message-----
From: Mandy Chung
Sent: Wednesday, December 09, 2015 11:55 PM
To: Sibabrata Sahoo
Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Some high-level comment:
1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java.  The Jigsaw prefix is not needed.
2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider.  [1] is a simple test for you to get started.

Some comments on JigsawSecurityUtils.java:
71         Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o));

this can be replaced with 
    Arrays.stream(options).collect(Collectors.joining(SPACE));

111         System.out.println(String.format(

You can do:  System.out.format(?.) instead;

Mandy
[1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java

> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> Hi Valerie,
> 
> Here is the updated webrev: 
> http://cr.openjdk.java.net/~ntv/siba/webrev.00/
> 
> Changes applied as per previous comments.
> - File names are modified and do not include the term JCE.
> - Source folder structure is flat now and all belongs to "java/security/Provider" folder.
> - Sign jar functionality removed.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Valerie Peng
> Sent: Wednesday, December 09, 2015 5:37 AM
> To: Sibabrata Sahoo
> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan 
> Bateman
> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
> providers if they are in signed/unsigned modular JARs
> 
> Hi Siba,
> 
> Here are some nits:
> 
> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms.
> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers).
> You can remove a lot of code as a result.
> Also, your directory seems a bit deep, e.g. 
> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way.
> 
> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible?
> 
> Thanks,
> Valerie
> 
> On 12/8/2015 2:04 PM, Valerie Peng wrote:
>> Right, that'd be my expectation as well. Sounds like everything works.
>> I will change to look at your latest webrev.
>> Valerie
>> 
>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
>>> Hi Valerie,
>>> 
>>> Here is the updated webrev: 
>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>>> 
>>> Now the modular behavior for the test works as per expectation 
>>> through JAKE build with the following condition.
>>> If the provider jar is available under ModulePath then the 
>>> "java.security" file should have the provider configuration entry as 
>>> ProviderName while in case of ClassPath the entry should hold the 
>>> full class name.
>>> 
>>> Thanks,
>>> Siba
>>> 
>>> -----Original Message-----
>>> From: Valerie Peng
>>> Sent: Tuesday, December 08, 2015 4:46 AM
>>> To: Sibabrata Sahoo
>>> Cc: Alan Bateman; security-dev at openjdk.java.net; 
>>> jigsaw-dev at openjdk.java.net
>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>>> providers if they are in signed/unsigned modular JARs
>>> 
>>> Siba,
>>> 
>>> I have just started to review this webrev and not done yet.
>>> As for your question, the java.security file in OpenJDK9 still uses 
>>> the provider class names instead of provider names. Are you talking 
>>> about the java.security file in Jigsaw? Which build (OpenJDK or
>>> Jigsaw) have you tested against. I am pretty sure that I tested the 
>>> 3rd party provider on classpath setting when I worked on the 7191662 
>>> changes.
>>> 
>>> Supposedly, if the jar files are available on class path, then you 
>>> should specify its full *class name* in the java.security file for 
>>> it to be instantiated. Otherwise, how would it find the class? Only 
>>> the classes discovered by ServiceLoader can be identified using the 
>>> provider name (which is different from the class name referred 
>>> above). So, in your scenario, that would be 
>>> "provider.TestJCEProvider" instead of "TEST".
>>> 
>>> If you still run into problems, try enable the java security debug 
>>> flag and u should get a good  idea why it isn't loaded. Let me know 
>>> if you still have questions.
>>> 
>>> Thanks,
>>> Valerie
>>> 
>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>>>> I would like to know more about this. As far, I can see the 
>>>> "java.security" provider configuration available with JDK9, it 
>>>> holds provider names instead of provider class names. In that case 
>>>> how it resolve the fall back?
>>>> 
>>>> Thanks,
>>>> Siba
>>>> 
>>>> -----Original Message-----
>>>> From: Alan Bateman
>>>> Sent: Monday, November 30, 2015 4:54 PM
>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; 
>>>> jigsaw-dev at openjdk.java.net
>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party 
>>>> security providers if they are in signed/unsigned modular JARs
>>>> 
>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>>>> Here is the updated webrev:
>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>>> 
>>>>> I have one question:
>>>>> What should be the behavior when the older version of 3rd party 
>>>>> JCE provider jar file(without service descriptor
>>>>> "META-INF/services/*"&   working with<= JDK8) configured by 
>>>>> "java.security" file, will be place in CLASS_PATH, running through
>>>>> JDK9 and the client is using Security.getProvider() to look for 
>>>>> the provider?
>>>>> 
>>>>> Currently the scenario fails to find the JCE provider. Is this 
>>>>> right behavior? If it is, then jdk9 is not backward compatible to 
>>>>> find the security provider provided through older jar files from 
>>>>> CLASS_PATH.
>>>>> 
>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this 
>>>> point by falling back and attempting to load the class name
>>>> specified via the security.provider.<N>   properties in the 
>>>> java.security file. I'm sure Valerie can say more about this.
>>>> 
>>>> -Alan


From weijun.wang at oracle.com  Mon Dec 21 01:50:07 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 21 Dec 2015 09:50:07 +0800
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <f84c49d6-da22-40e3-a82d-37c51d98c422@default>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
	<566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com>
	<62346504-1078-4ccd-9188-29dcd288f269@default>
	<A5CD3850-3E07-4647-B7E0-855AA6CFEEC5@oracle.com>
	<62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default>
	<f84c49d6-da22-40e3-a82d-37c51d98c422@default>
Message-ID: <35522719-0284-4FFB-89F0-E987CA61657B@oracle.com>

Tests are good. Several comments:

1. Try run something like "hg mv -A" to let Mercurial knows that you are renaming files (SecurityUtils.java and those in login/modules/src) instead of removing some old and creating some new. The current webrev does not show this.

2. It's not a good practice extending a class just to use its static fields/methods. Instead, make the util class final.

   public class JaasModularClientTest extends SecurityUtils
   public class SecurityProviderModularTest extends SecurityUtils

In fact, if you do find similarities between SecurityProviderModularTest and JaasModularClientTest, try abstract them into a ModularTest class.

3. Please add enough comments to SecurityUtils since it will be reused. For example, move the descriptions of EXPLICIT, AUTO and UNNAMED from test @summary to definition of enum MODULE_TYPE.

Thanks
Max


> On Dec 20, 2015, at 2:10 PM, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> Hi Mandy/Max,
> 
> Here is the updated webrev with very minor change over previous: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.04/
> 
> Thanks
> Siba
> 
> -----Original Message-----
> From: Sibabrata Sahoo 
> Sent: Sunday, December 20, 2015 1:34 AM
> To: Mandy Chung; Weijun Wang
> Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net
> Subject: RE: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs
> 
> Hi Mandy/Max,
> 
> Please review the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/
> 
> "3rd party security providers" Test change includes:
> - Test are converted to use TestNG framework.
> - java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository.
> - Common reusable operations moved to "SecurityUtils.java"
> - All the following comments associated.
> 
> 
> Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes:
> - Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed.
> - Test converted to use TestNG framework.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Mandy Chung
> Sent: Wednesday, December 09, 2015 11:55 PM
> To: Sibabrata Sahoo
> Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net
> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs
> 
> Some high-level comment:
> 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java.  The Jigsaw prefix is not needed.
> 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider.  [1] is a simple test for you to get started.
> 
> Some comments on JigsawSecurityUtils.java:
> 71         Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o));
> 
> this can be replaced with 
>    Arrays.stream(options).collect(Collectors.joining(SPACE));
> 
> 111         System.out.println(String.format(
> 
> You can do:  System.out.format(?.) instead;
> 
> Mandy
> [1] http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/jigsaw/reflect/Proxy/ProxyTest.java
> 
>> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
>> 
>> Hi Valerie,
>> 
>> Here is the updated webrev: 
>> http://cr.openjdk.java.net/~ntv/siba/webrev.00/
>> 
>> Changes applied as per previous comments.
>> - File names are modified and do not include the term JCE.
>> - Source folder structure is flat now and all belongs to "java/security/Provider" folder.
>> - Sign jar functionality removed.
>> 
>> Thanks,
>> Siba
>> 
>> -----Original Message-----
>> From: Valerie Peng
>> Sent: Wednesday, December 09, 2015 5:37 AM
>> To: Sibabrata Sahoo
>> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan 
>> Bateman
>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>> providers if they are in signed/unsigned modular JARs
>> 
>> Hi Siba,
>> 
>> Here are some nits:
>> 
>> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms.
>> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers).
>> You can remove a lot of code as a result.
>> Also, your directory seems a bit deep, e.g. 
>> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way.
>> 
>> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible?
>> 
>> Thanks,
>> Valerie
>> 
>> On 12/8/2015 2:04 PM, Valerie Peng wrote:
>>> Right, that'd be my expectation as well. Sounds like everything works.
>>> I will change to look at your latest webrev.
>>> Valerie
>>> 
>>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
>>>> Hi Valerie,
>>>> 
>>>> Here is the updated webrev: 
>>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>>>> 
>>>> Now the modular behavior for the test works as per expectation 
>>>> through JAKE build with the following condition.
>>>> If the provider jar is available under ModulePath then the 
>>>> "java.security" file should have the provider configuration entry as 
>>>> ProviderName while in case of ClassPath the entry should hold the 
>>>> full class name.
>>>> 
>>>> Thanks,
>>>> Siba
>>>> 
>>>> -----Original Message-----
>>>> From: Valerie Peng
>>>> Sent: Tuesday, December 08, 2015 4:46 AM
>>>> To: Sibabrata Sahoo
>>>> Cc: Alan Bateman; security-dev at openjdk.java.net; 
>>>> jigsaw-dev at openjdk.java.net
>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>>>> providers if they are in signed/unsigned modular JARs
>>>> 
>>>> Siba,
>>>> 
>>>> I have just started to review this webrev and not done yet.
>>>> As for your question, the java.security file in OpenJDK9 still uses 
>>>> the provider class names instead of provider names. Are you talking 
>>>> about the java.security file in Jigsaw? Which build (OpenJDK or
>>>> Jigsaw) have you tested against. I am pretty sure that I tested the 
>>>> 3rd party provider on classpath setting when I worked on the 7191662 
>>>> changes.
>>>> 
>>>> Supposedly, if the jar files are available on class path, then you 
>>>> should specify its full *class name* in the java.security file for 
>>>> it to be instantiated. Otherwise, how would it find the class? Only 
>>>> the classes discovered by ServiceLoader can be identified using the 
>>>> provider name (which is different from the class name referred 
>>>> above). So, in your scenario, that would be 
>>>> "provider.TestJCEProvider" instead of "TEST".
>>>> 
>>>> If you still run into problems, try enable the java security debug 
>>>> flag and u should get a good  idea why it isn't loaded. Let me know 
>>>> if you still have questions.
>>>> 
>>>> Thanks,
>>>> Valerie
>>>> 
>>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>>>>> I would like to know more about this. As far, I can see the 
>>>>> "java.security" provider configuration available with JDK9, it 
>>>>> holds provider names instead of provider class names. In that case 
>>>>> how it resolve the fall back?
>>>>> 
>>>>> Thanks,
>>>>> Siba
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Alan Bateman
>>>>> Sent: Monday, November 30, 2015 4:54 PM
>>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; 
>>>>> jigsaw-dev at openjdk.java.net
>>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party 
>>>>> security providers if they are in signed/unsigned modular JARs
>>>>> 
>>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>>>>> Here is the updated webrev:
>>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>>>> 
>>>>>> I have one question:
>>>>>> What should be the behavior when the older version of 3rd party 
>>>>>> JCE provider jar file(without service descriptor
>>>>>> "META-INF/services/*"&   working with<= JDK8) configured by 
>>>>>> "java.security" file, will be place in CLASS_PATH, running through
>>>>>> JDK9 and the client is using Security.getProvider() to look for 
>>>>>> the provider?
>>>>>> 
>>>>>> Currently the scenario fails to find the JCE provider. Is this 
>>>>>> right behavior? If it is, then jdk9 is not backward compatible to 
>>>>>> find the security provider provided through older jar files from 
>>>>>> CLASS_PATH.
>>>>>> 
>>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this 
>>>>> point by falling back and attempting to load the class name
>>>>> specified via the security.provider.<N>   properties in the 
>>>>> java.security file. I'm sure Valerie can say more about this.
>>>>> 
>>>>> -Alan
> 


From bhanu.prakash.gopularam at oracle.com  Mon Dec 21 04:42:26 2015
From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam)
Date: Sun, 20 Dec 2015 20:42:26 -0800 (PST)
Subject: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to
	comply with FIPS 186-4
In-Reply-To: <AC1E1F65-CDC5-466F-9DDE-9633F9F27F43@oracle.com>
References: <e03cca02-fd10-4566-b0e6-c52fc8f1c637@default>
	<0ed013aa-b95a-4db8-9bd3-db3274d3de0f@default>
	<56746A84.60106@oracle.com>
	<AC1E1F65-CDC5-466F-9DDE-9633F9F27F43@oracle.com>
Message-ID: <95db8a25-2e09-4290-9cb5-7212627d53f8@default>

Hi Sean,

The present fix solves the test issue which is happening in newer Solaris version viz., 11.3/12 which has FIPS guidelines as a prerequisite. 
With your permission I shall leave the JDK-8074580 (test stabilization issue) in current state, and would like to continue with fix for public exponent issue as reported in JDK-8129560. 
Please let me know.

Thank you,
Bhanu

-----Original Message-----
From: Anthony Scarpino 
Sent: Saturday, December 19, 2015 3:34 AM
To: Sean Mullan
Cc: Bhanu Gopularam; security-dev at openjdk.java.net
Subject: Re: RFR: 8129560- CKR_ARGUMENTS_BAD - private exponent needs to comply with FIPS 186-4

The problems are different. The PKCS11 error means everything in this case. 

Tony

> On Dec 18, 2015, at 12:20 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> The fix looks good, although this test is already on the ProblemList due to JDK-8074580. Do you know if that bug is caused by the same issue? The underlying PKCS11 error is different (maybe due to a different Solaris version?), but it looks like an identical stack trace. It would be good to also remove it from the ProblemList and close the other bug if it is a duplicate issue.
> 
> --Sean
> 
>> On 12/18/2015 12:41 AM, Bhanu Gopularam wrote:
>> Hi all,
>> 
>> Please review a fix for following bug:
>> 
>> Bug Id - https://bugs.openjdk.java.net/browse/JDK-8129560
>> 
>> Issue ? Test sun/security/pkcs11/rsa/TestKeyPairGenerator.java is 
>> failing because RSAKeyGenParameterSpec
>> 
>> public exponent is not accordance with FIPS 186-4 guidance
>> 
>> Solution ? Used proper value for exponent based on reference from 
>> FIPS 186-4, section B-2.
>> 
>> webrev - http://cr.openjdk.java.net/~ntv/bhanu/8129560/webrev.00/
>> 
>> Thanks,
>> 
>> Bhanu
>> 

From usha.seshadri at lmco.com  Mon Dec 21 16:02:39 2015
From: usha.seshadri at lmco.com (Seshadri, Usha)
Date: Mon, 21 Dec 2015 16:02:39 +0000
Subject: error compiling openJDK9 - commandLineFlagRangeList.cpp
Message-ID: <0F6322F01158F94EBDA664939D5EA15504F44315@HVXDSP25.us.lmco.com>

Hello,

I just downloaded OpenJDK9, and am trying to build it on RHEL 5.11 with g++ 4.2.1, and I am getting this error from commandLineFlagRangeList.cpp:

hotspot/src/share/vm/runtime/commandLineFlagRangeList.cpp:293: error: integer constant is too large for 'long' type

commandLineFlagRangeList.cpp:293 points to:
  emit_range_no(NULL RUNTIME_FLAGS(EMIT_RANGE_DEVELOPER_FLAG,
                                   EMIT_RANGE_PD_DEVELOPER_FLAG,
                                   EMIT_RANGE_PRODUCT_FLAG,
                                   EMIT_RANGE_PD_PRODUCT_FLAG,
                                   EMIT_RANGE_DIAGNOSTIC_FLAG,
                                   EMIT_RANGE_EXPERIMENTAL_FLAG,
                                   EMIT_RANGE_NOTPRODUCT_FLAG,
                                   EMIT_RANGE_MANAGEABLE_FLAG,
                                   EMIT_RANGE_PRODUCT_RW_FLAG,
                                   EMIT_RANGE_LP64_PRODUCT_FLAG,
                                   EMIT_RANGE_CHECK,
                                   IGNORE_CONSTRAINT) );

Has anyone seen this error before? How can I go about fixing this error? Any help is greatly appreciated.

Thanks,

Usha Seshadri
Lockheed Martin, IS&GS
301-240-7496
[LM-logo]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151221/b1a65f2c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3531 bytes
Desc: image002.jpg
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151221/b1a65f2c/image002-0001.jpg>

From sibabrata.sahoo at oracle.com  Tue Dec 22 06:17:06 2015
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Mon, 21 Dec 2015 22:17:06 -0800 (PST)
Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers
	if they are in signed/unsigned modular JARs
In-Reply-To: <35522719-0284-4FFB-89F0-E987CA61657B@oracle.com>
References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default>
	<ddd22ece-13db-4838-a729-38dc1f79066c@default>
	<FFA7DCE2-4607-43B8-BF98-150E9000A96F@oracle.com>
	<bb9d56cd-dbd7-435b-8ea3-5a281e8d1053@default>
	<565C31EA.4050709@oracle.com>
	<0bea66aa-c1ab-486c-88f1-1791719c2c54@default>
	<56661315.2070701@oracle.com>
	<3d12ebbb-f4f0-4cea-b319-a67b1d742896@default>
	<566753FD.5020106@oracle.com> <5667708F.9000706@oracle.com>
	<62346504-1078-4ccd-9188-29dcd288f269@default>
	<A5CD3850-3E07-4647-B7E0-855AA6CFEEC5@oracle.com>
	<62fab1cf-13f9-4e7b-bec1-ad59a2a6ebbc@default>
	<f84c49d6-da22-40e3-a82d-37c51d98c422@default>
	<35522719-0284-4FFB-89F0-E987CA61657B@oracle.com>
Message-ID: <a7db85dc-d748-4016-9c18-27df1048c8d5@default>

Hi Max/Mandy,

Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.05/

I tried to address all the comments bellow. The major change includes abstracting the common behavior to ModularTest.java and extend the rest by each specific test. i.e. SecurityProviderModularTest and JaasModularClientTest.

Thanks,
Siba

-----Original Message-----
From: Wang Weijun 
Sent: Monday, December 21, 2015 7:20 AM
To: Sibabrata Sahoo
Cc: Mandy Chung; Valerie Peng; jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Tests are good. Several comments:

1. Try run something like "hg mv -A" to let Mercurial knows that you are renaming files (SecurityUtils.java and those in login/modules/src) instead of removing some old and creating some new. The current webrev does not show this.

2. It's not a good practice extending a class just to use its static fields/methods. Instead, make the util class final.

   public class JaasModularClientTest extends SecurityUtils
   public class SecurityProviderModularTest extends SecurityUtils

In fact, if you do find similarities between SecurityProviderModularTest and JaasModularClientTest, try abstract them into a ModularTest class.

3. Please add enough comments to SecurityUtils since it will be reused. For example, move the descriptions of EXPLICIT, AUTO and UNNAMED from test @summary to definition of enum MODULE_TYPE.

Thanks
Max


> On Dec 20, 2015, at 2:10 PM, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> Hi Mandy/Max,
> 
> Here is the updated webrev with very minor change over previous: 
> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.04/
> 
> Thanks
> Siba
> 
> -----Original Message-----
> From: Sibabrata Sahoo
> Sent: Sunday, December 20, 2015 1:34 AM
> To: Mandy Chung; Weijun Wang
> Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; 
> security-dev at openjdk.java.net
> Subject: RE: [9] RFR:8130360: Add tests to verify 3rd party security 
> providers if they are in signed/unsigned modular JARs
> 
> Hi Mandy/Max,
> 
> Please review the updated webrev: 
> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.03/
> 
> "3rd party security providers" Test change includes:
> - Test are converted to use TestNG framework.
> - java/security/modules/JigsawSecurityUtils.java, renamed to "SecurityUtils.java". Proper care required while pushing the change because "JigsawSecurityUtils.java" is an existing file in JAKE repository.
> - Common reusable operations moved to "SecurityUtils.java"
> - All the following comments associated.
> 
> 
> Based on the recent comments, I also did some changes to the "JAAS Modular test" because both test are very similar to each other. The change includes:
> - Flat folder structure. It places the Test as well as all its dependency in a single folder. i.e. "javax/security/auth/login/modules". That also means "javax/security/auth/login/modules/src/" and all its subfolders need to be removed.
> - Test converted to use TestNG framework.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Mandy Chung
> Sent: Wednesday, December 09, 2015 11:55 PM
> To: Sibabrata Sahoo
> Cc: Valerie Peng; jigsaw-dev at openjdk.java.net; 
> security-dev at openjdk.java.net
> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
> providers if they are in signed/unsigned modular JARs
> 
> Some high-level comment:
> 1. I suggest to rename JigsawSecurityUtils.java to SecurityUtils.java.  The Jigsaw prefix is not needed.
> 2. SecurityProviderModularTest does the setup and launch the test with a set of different settings. I suggest to convert it to TestNG and you can reference the existing test/jdk/jigsaw tests which are a driver test that does the compilation and setup with @BeforeTest and @Test for each run test together with @DataProvider.  [1] is a simple test for you to get started.
> 
> Some comments on JigsawSecurityUtils.java:
> 71         Arrays.asList(options).stream().forEach(o -> command.append(SPACE + o));
> 
> this can be replaced with 
>    Arrays.stream(options).collect(Collectors.joining(SPACE));
> 
> 111         System.out.println(String.format(
> 
> You can do:  System.out.format(?.) instead;
> 
> Mandy
> [1] 
> http://hg.openjdk.java.net/jigsaw/jake/jdk/file/c1d583efa466/test/jdk/
> jigsaw/reflect/Proxy/ProxyTest.java
> 
>> On Dec 9, 2015, at 10:02 AM, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
>> 
>> Hi Valerie,
>> 
>> Here is the updated webrev: 
>> http://cr.openjdk.java.net/~ntv/siba/webrev.00/
>> 
>> Changes applied as per previous comments.
>> - File names are modified and do not include the term JCE.
>> - Source folder structure is flat now and all belongs to "java/security/Provider" folder.
>> - Sign jar functionality removed.
>> 
>> Thanks,
>> Siba
>> 
>> -----Original Message-----
>> From: Valerie Peng
>> Sent: Wednesday, December 09, 2015 5:37 AM
>> To: Sibabrata Sahoo
>> Cc: jigsaw-dev at openjdk.java.net; security-dev at openjdk.java.net; Alan 
>> Bateman
>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security 
>> providers if they are in signed/unsigned modular JARs
>> 
>> Hi Siba,
>> 
>> Here are some nits:
>> 
>> I think it's somewhat misleading to use the term JCE here as what you are testing here is just security provider loading. JCE is more about security providers supporting export-controlled services/algorithms.
>> Since your provider is just an empty one, I don't think u need to sign it (again, it's only for JCE providers).
>> You can remove a lot of code as a result.
>> Also, your directory seems a bit deep, e.g. 
>> modules/src/jceprovidermodule/provider/TestJCEProvider.java vs modules/src/jceclientmodule/provider/TestJCEProvider.java. Can all of these files be under the same directory instead of spreading over several level of subdirectories? The file names are different enough to tell which is which. Other regression tests for provider loading functionality are under test/java/security/Provider. Easier to find this way.
>> 
>> Can you please make the appropriate changes, e.g. don't use the term JCE, get rid of the signing, and simplify the directory structure if possible?
>> 
>> Thanks,
>> Valerie
>> 
>> On 12/8/2015 2:04 PM, Valerie Peng wrote:
>>> Right, that'd be my expectation as well. Sounds like everything works.
>>> I will change to look at your latest webrev.
>>> Valerie
>>> 
>>> On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
>>>> Hi Valerie,
>>>> 
>>>> Here is the updated webrev: 
>>>> http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
>>>> 
>>>> Now the modular behavior for the test works as per expectation 
>>>> through JAKE build with the following condition.
>>>> If the provider jar is available under ModulePath then the 
>>>> "java.security" file should have the provider configuration entry 
>>>> as ProviderName while in case of ClassPath the entry should hold 
>>>> the full class name.
>>>> 
>>>> Thanks,
>>>> Siba
>>>> 
>>>> -----Original Message-----
>>>> From: Valerie Peng
>>>> Sent: Tuesday, December 08, 2015 4:46 AM
>>>> To: Sibabrata Sahoo
>>>> Cc: Alan Bateman; security-dev at openjdk.java.net; 
>>>> jigsaw-dev at openjdk.java.net
>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party 
>>>> security providers if they are in signed/unsigned modular JARs
>>>> 
>>>> Siba,
>>>> 
>>>> I have just started to review this webrev and not done yet.
>>>> As for your question, the java.security file in OpenJDK9 still uses 
>>>> the provider class names instead of provider names. Are you talking 
>>>> about the java.security file in Jigsaw? Which build (OpenJDK or
>>>> Jigsaw) have you tested against. I am pretty sure that I tested the 
>>>> 3rd party provider on classpath setting when I worked on the 
>>>> 7191662 changes.
>>>> 
>>>> Supposedly, if the jar files are available on class path, then you 
>>>> should specify its full *class name* in the java.security file for 
>>>> it to be instantiated. Otherwise, how would it find the class? Only 
>>>> the classes discovered by ServiceLoader can be identified using the 
>>>> provider name (which is different from the class name referred 
>>>> above). So, in your scenario, that would be 
>>>> "provider.TestJCEProvider" instead of "TEST".
>>>> 
>>>> If you still run into problems, try enable the java security debug 
>>>> flag and u should get a good  idea why it isn't loaded. Let me know 
>>>> if you still have questions.
>>>> 
>>>> Thanks,
>>>> Valerie
>>>> 
>>>> On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
>>>>> I would like to know more about this. As far, I can see the 
>>>>> "java.security" provider configuration available with JDK9, it 
>>>>> holds provider names instead of provider class names. In that case 
>>>>> how it resolve the fall back?
>>>>> 
>>>>> Thanks,
>>>>> Siba
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Alan Bateman
>>>>> Sent: Monday, November 30, 2015 4:54 PM
>>>>> To: Sibabrata Sahoo; security-dev at openjdk.java.net; 
>>>>> jigsaw-dev at openjdk.java.net
>>>>> Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party 
>>>>> security providers if they are in signed/unsigned modular JARs
>>>>> 
>>>>> On 30/11/2015 11:13, Sibabrata Sahoo wrote:
>>>>>> Here is the updated webrev:
>>>>>> http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
>>>>>> 
>>>>>> I have one question:
>>>>>> What should be the behavior when the older version of 3rd party 
>>>>>> JCE provider jar file(without service descriptor
>>>>>> "META-INF/services/*"&   working with<= JDK8) configured by 
>>>>>> "java.security" file, will be place in CLASS_PATH, running 
>>>>>> through
>>>>>> JDK9 and the client is using Security.getProvider() to look for 
>>>>>> the provider?
>>>>>> 
>>>>>> Currently the scenario fails to find the JCE provider. Is this 
>>>>>> right behavior? If it is, then jdk9 is not backward compatible to 
>>>>>> find the security provider provided through older jar files from 
>>>>>> CLASS_PATH.
>>>>>> 
>>>>> The JCE work in JDK 9 (via JDK-7191662) was meant to address this 
>>>>> point by falling back and attempting to load the class name
>>>>> specified via the security.provider.<N>   properties in the 
>>>>> java.security file. I'm sure Valerie can say more about this.
>>>>> 
>>>>> -Alan
> 


From sean.mullan at oracle.com  Tue Dec 22 16:36:30 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 22 Dec 2015 11:36:30 -0500
Subject: Code Review Request, 8133070 Hot lock on BulkCipher.isAvailable
In-Reply-To: <56758080.1000703@oracle.com>
References: <565D9774.9000304@oracle.com> <566F2584.5070502@oracle.com>
	<566F843B.4090605@oracle.com> <567427A8.5000105@oracle.com>
	<56758080.1000703@oracle.com>
Message-ID: <56797C0E.1010609@oracle.com>

The updated webrev looks good.

--Sean

On 12/19/2015 11:06 AM, Xuelei Fan wrote:
> new webrev: http://cr.openjdk.java.net/~xuelei/8133070/webrev.01/
>
> Updates to webrev.00:
> Re-org the get methods of SSLContextImpl so as to avoid repeated
> initialization of instance fields.
>
> On 12/18/2015 11:35 PM, Sean Mullan wrote:
>> Here are a few other other comments on the code:
>>
>> SSLContextImpl:
>>    - I noticed that SSLContext.init does not specify how it handles empty
>> arrays, and you have changed the code so that an empty TrustManager
>> array is treated like they are null - is this change in behavior a
>> compatibility issue at all? Could you file a follow-on issue to clarify
>> the behavior of SSLContext.init as to how it should handle empty arrays?
>>
> It's a bug of my update. Empty means no trust manager, which is
> different from using the default trust manager.
>
> I removed this update.
>
>>    - are there any race conditions that you need to worry about now that
>> you have removed the synchronized blocks from
>> getSupportedCipherSuiteList and getDefaultCipherSuite?
>>
> May be initialized repeatedly.  Should be OK as there is only one
> instance for the to-be-assigned value.
>
> The code can be more straightforward and effective.  I moved the impls
> into sub-classes.
>
>>    - on lines 781 and 789, an empty array is created and discarded if
>> there is not an exception thrown. It would be better to only create the
>> empty array when an exception is thrown (move it into the catch block).
>>
> Updated.
>
> Thanks,
> Xuelei
>
>> --Sean
>>
>>
>> On 12/14/2015 10:08 PM, Xuelei Fan wrote:
>>> On 12/15/2015 4:24 AM, Sean Mullan wrote:
>>>> Hi Xuelei,
>>>>
>>>> For JDK 9, the EC impl is defined to be in its own module
>>>> (jdk.crypto.ec). How does it affect this fix if that module is not
>>>> available/installed?
>>>>
>>> The SunJSSE provider would not support dynamically loading of crypto
>>> providers/modules.  At present, there are two providers that supports EC
>>> implementation, SunEC (jdk.crypto.ec) and SunPKCS11 (jdk.crypto.pkcs11).
>>>    If no EC provider, EC cipher suites would not be available to use.
>>> That's to say, EC cipher suites would not be enabled by default, and
>>> cannot be used for handshaking.  In the fix,
>>> JsseJce#EcAvailability.isAvailable is used to check the availability of
>>> EC crypto impl.
>>>
>>> Xuelei
>>>
>>>> --Sean
>>>>
>>>> On 12/01/2015 07:49 AM, Xuelei Fan wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the fix for JDK-8133070:
>>>>>
>>>>>       http://cr.openjdk.java.net/~xuelei/8133070/webrev.00/
>>>>>
>>>>> In (Open)JDK 6, EC cipher suites get supported by Java.  However, there
>>>>> is no default EC provider in JDK 6 at that time.  In order to support
>>>>> third part's EC algorithm JCE provider dynamically, it is hard-coded to
>>>>> check the cipher suite availability dynamically for EC algorithms in
>>>>> SunJSSE provider.
>>>>>
>>>>> Here is an example update in CipherSuite.java for the checking:
>>>>>
>>>>>      -   static final boolean DYNAMIC_AVAILABILITY = false;
>>>>>      +   static final boolean DYNAMIC_AVAILABILITY = true;
>>>>>
>>>>> The dynamically checking impacts the performance significantly as:
>>>>> 1. the check of the availability is expensive as it involves crypto
>>>>> operations.
>>>>> 2. a cache is used to maintain the availability of bulk ciphers in
>>>>> order
>>>>> to mitigate the #1 performance impact.  However, access and update to
>>>>> the cache need to be synchronized.
>>>>> 3. in order to support dynamically checking, the cache may be
>>>>> cleared if
>>>>> a particular cipher is not found or a new SSLContext is generated. As
>>>>> bring the performance impact of #1 back again.
>>>>>
>>>>> Later, AEAD algorithm is defined by Java.  The same mechanism is
>>>>> used to
>>>>> support AEAD ciphers.
>>>>>
>>>>> Now, EC and GCM algorithms are supported in JDK crypto providers. The
>>>>> hard-coded checking can get improved.  This fix updates:
>>>>> 1. remove the dynamically checking of cipher suite availability.
>>>>> 2. remove the cipher suite availability cache accordingly (need no
>>>>> synchronization accordingly)
>>>>> 3. other updates that impact by the availability checking.
>>>>>
>>>>> The performance improvement is tested with the following simple case.
>>>>> Run the following code 1000, 2000, 3000 times in single thread mode and
>>>>> measure the millisecond for each:
>>>>>
>>>>> ---------
>>>>> String[] cipherSuites =
>>>>>            {"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"};
>>>>> for (int i = 0; i < loops; i++) {  // loops: 1000, 2000, 3000
>>>>>        SSLEngine engine = SSLContext.getDefault().createSSLEngine();
>>>>>        engine.getEnabledCipherSuites();
>>>>>        engine.getSupportedCipherSuites();
>>>>> }
>>>>> ---------
>>>>>
>>>>> The milliseconds for each test case (less is better) look like:
>>>>>
>>>>>        loops   |  old    |  fixed
>>>>>       ---------+---------+----------
>>>>>       1000     |  2736   |  735
>>>>>       ---------+---------+----------
>>>>>       2000     |  3718   |  746
>>>>>       ---------+---------+----------
>>>>>       3000     |  4750   |  765
>>>>>       ---------+---------+----------
>>>>>
>>>>> This fix improves the performance.
>>>>>
>>>>> The existing regression testing get passed.  No new regression test is
>>>>> planned as this is a performance enhancement fix.
>>>>>
>>>>> Thanks,
>>>>> Xuelei
>>>>>
>>>
>

From rob.mckenna at oracle.com  Wed Dec 23 16:03:46 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 23 Dec 2015 16:03:46 +0000
Subject: RFR: 8146105 - Undo accidential changes to
	sun/security/ssl/SignatureAndHashAlgorithm.java
Message-ID: <567AC5E2.4060700@oracle.com>

Apologies folks,

I managed to push a change for 
https://bugs.openjdk.java.net/browse/JDK-8064330 along with 
https://bugs.openjdk.java.net/browse/JDK-7130985

I'd like to revert that particular portion of the change:

http://cr.openjdk.java.net/~robm/8146105/webrev.01/

	-Rob

From xuelei.fan at oracle.com  Thu Dec 24 15:25:02 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 24 Dec 2015 23:25:02 +0800
Subject: FYI, 8146192 Add test for JDK-8049321
Message-ID: <567C0E4E.9020605@oracle.com>

FYI.

I missed the test code while push the changeset for JDK-8049321.  This
update will push the changeset.

Please refer to the webrev for JDK-8049321:
   http://cr.openjdk.java.net/~xuelei/8049321/webrev.00/

Thanks,
Xuelei

From xuelei.fan at oracle.com  Thu Dec 24 15:51:57 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 24 Dec 2015 23:51:57 +0800
Subject: RFR: 8146105 - Undo accidential changes to
	sun/security/ssl/SignatureAndHashAlgorithm.java
In-Reply-To: <567AC5E2.4060700@oracle.com>
References: <567AC5E2.4060700@oracle.com>
Message-ID: <567C149D.5090609@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 12/24/2015 12:03 AM, Rob McKenna wrote:
> Apologies folks,
> 
> I managed to push a change for
> https://bugs.openjdk.java.net/browse/JDK-8064330 along with
> https://bugs.openjdk.java.net/browse/JDK-7130985
> 
> I'd like to revert that particular portion of the change:
> 
> http://cr.openjdk.java.net/~robm/8146105/webrev.01/
> 
>     -Rob


From xuelei.fan at oracle.com  Fri Dec 25 15:53:42 2015
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 25 Dec 2015 23:53:42 +0800
Subject: Code Review Request, 8146197 SignatureAlgorithms.java after push of
	JDK-8146192
Message-ID: <567D6686.2050302@oracle.com>

Hi,

Anyone available for a quick review?

   http://cr.openjdk.java.net/~xuelei/8146197/webrev.00/

A test failure caused by the removal of BASE64Decoder.  Updated to use
java.util.Base64.

Thanks,
Xuelei

From henry.jen at oracle.com  Fri Dec 25 18:29:35 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Fri, 25 Dec 2015 10:29:35 -0800
Subject: Code Review Request,
	8146197 SignatureAlgorithms.java after push of JDK-8146192
In-Reply-To: <567D6686.2050302@oracle.com>
References: <567D6686.2050302@oracle.com>
Message-ID: <EB467353-691D-4ABD-8B7A-3D2FCD68462B@oracle.com>

Not an official reviewer, but the change look good to me. 

Cheers,
Henry

> On Dec 25, 2015, at 7:53 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Hi,
> 
> Anyone available for a quick review?
> 
>   http://cr.openjdk.java.net/~xuelei/8146197/webrev.00/
> 
> A test failure caused by the removal of BASE64Decoder.  Updated to use
> java.util.Base64.
> 
> Thanks,
> Xuelei


From sean.mullan at oracle.com  Sun Dec 27 15:53:08 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Sun, 27 Dec 2015 10:53:08 -0500
Subject: Code Review Request,
	8146197 SignatureAlgorithms.java after push of JDK-8146192
In-Reply-To: <567D6686.2050302@oracle.com>
References: <567D6686.2050302@oracle.com>
Message-ID: <E8F65194-8509-4D8B-90B3-E1CE162CF381@oracle.com>

Looks fine to me. 

> On Dec 25, 2015, at 10:53 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Hi,
> 
> Anyone available for a quick review?
> 
>   http://cr.openjdk.java.net/~xuelei/8146197/webrev.00/
> 
> A test failure caused by the removal of BASE64Decoder.  Updated to use
> java.util.Base64.
> 
> Thanks,
> Xuelei

From mark.sheppard at oracle.com  Thu Dec 31 14:30:05 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Thu, 31 Dec 2015 14:30:05 +0000
Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for
	sun.net.spi.nameservice.NameServiceDescriptor
In-Reply-To: <5645DB41.8000704@oracle.com>
References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com>
	<5645DB41.8000704@oracle.com>
Message-ID: <56853BED.2070007@oracle.com>

Hi
   please oblige and review the current version of the fix  for
https://bugs.openjdk.java.net/browse/JDK-8134577

at
http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/

which is  based on feedback from the second review.

In summary the following changes have been made

* hosts file mapping structure has been changed to align with 
/etc/hosts, that is, <ip address>  <host alias list> rather than  
<hostname>  <ip address>

* elementary comment handling added, skip lines starting with #

* lookupAllHostAddr returns an array of InetAddresses, rather than a 
single element array containing the first host address mapping

* the illegal_state_exception  token handling has been removed, and a 
corresponding test deadlock/Hang.java removed

* transient key word added to member variables useLocalHostsFileLookup 
and hostsFileName

* added an explicit test to exercise the internal NameService

regards
Mark

On 13/11/2015 12:44, Mark Sheppard wrote:
> Hi,
>    to summarize the amendments below:
>
> ServiceConfigurationError removed - the code no longer reads the 
> nameservice provider property, it silently ignored
>
> try-with-resources statement added in getHostByAddr and 
> lookupAllHostAddr methods of NameService, and duplicate statements removed
>
> hosts file name in tests changed to TestHosts to avoid any potential 
> confusion with /etc/hosts
>
> regards
> Mark
>
>
>
> On 12/11/2015 16:46, Mark Sheppard wrote:
>> Hi,
>>     based on feedback from first review the updates have been amended
>> please oblige and review the current set of changes as per
>>
>> http://cr.openjdk.java.net/~msheppar/8134577/webrev.02/
>>
>> regards
>> Mark
>>
>> On 25/10/2015 23:32, Mark Sheppard wrote:
>>> Hi,
>>>    please oblige and review the following changes
>>> http://cr.openjdk.java.net/~msheppar/8134577/webrev/
>>>
>>> which address the issue raised in
>>> https://bugs.openjdk.java.net/browse/JDK-8134577
>>>
>>> the operative word has been "eliminate".
>>> As such, the interface and service descriptor 
>>> sun.net.spi.nameservice.NameService
>>> sun.net.spi.nameservice.NameServiceDescriptor*
>>> *together with its implementation 
>>> (sun.net.nameservice.dns.DNSNameService)
>>> has been remove from the JDK libraries.
>>>
>>> The immediate impact is seen in the JDK testing framework.
>>>
>>> To facilitate testing activity, and provide a replacement for the 
>>> customized NameService implementations in the
>>> JDK tests,  the default NameService has been extended to support
>>> the retrieval of host to IP address mappings from a file.
>>> The file path is specified with a system property " jdk.internal.hosts".
>>>
>>> Previously a nameservice provider was specified by setting the 
>>> system property
>>> "sun.net.spi.nameservice.provider.", as per the documentation
>>> http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html
>>>
>>> InetAddress now tests to determine if this property is set and will 
>>> throw a ServiceConfigurationError
>>> indicating that this functionality is no longer supported. The 
>>> choice of ServideConfigurationError may cause
>>> some debate, or disagreement. The rationale was that InternalError,  
>>> is documented to relate to a JVM error,
>>> and javax.naming.NamingException has a context of DirContext.
>>> A possible alternative candidate could be 
>>> javax.naming.ServiceUnavailableException.
>>> As such, the setting of the property 
>>> "sun.net.spi.nameservice.provider." was used, previously, as a 
>>> configuration
>>> parameter for the loading of a NamerService service provider, and as 
>>> this is now (considered) an error, ServiceConfigurationError,
>>> seemed a best fit!
>>>
>>> These changes impacted a number of jdk security tests, also. The 
>>> affected tetsts have been amended to adopt the
>>> changes, with the exception of 
>>> test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java
>>> which will require some rewrite.
>>>
>>> regards
>>> Mark
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/security-dev/attachments/20151231/b033d926/attachment.html>

From weijun.wang at oracle.com  Thu Dec 31 17:26:16 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 1 Jan 2016 01:26:16 +0800
Subject: RFR 8146377: test/sun/security/tools/jarsigner/concise_jarsigner.sh
	failing
Message-ID: <6FD46EB9-0806-4CD6-AE33-5B875391A0F9@oracle.com>

Hi

Please review the fix of https://bugs.openjdk.java.net/browse/JDK-8146377. Some years have more days than 365 and the test fails. The fix is simply

diff --git a/test/sun/security/tools/jarsigner/concise_jarsigner.sh b/test/sun/security/tools/jarsigner/concise_jarsigner.sh
--- a/test/sun/security/tools/jarsigner/concise_jarsigner.sh
+++ b/test/sun/security/tools/jarsigner/concise_jarsigner.sh
@@ -69,8 +69,8 @@
 # First part: output format
 # ==========================================================

-$KT -genkeypair -alias a1 -dname CN=a1 -validity 365
-$KT -genkeypair -alias a2 -dname CN=a2 -validity 365
+$KT -genkeypair -alias a1 -dname CN=a1 -validity 366
+$KT -genkeypair -alias a2 -dname CN=a2 -validity 366

 # a.jar includes 8 unsigned, 2 signed by a1 and a2, 2 signed by a3
 $JAR cvf a.jar A1.class A2.class

Thanks
Max