From mbalao at redhat.com  Wed Apr  1 00:22:58 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 31 Mar 2020 21:22:58 -0300
Subject: RFR 8239385: KerberosTicket client name refers wrongly to
 sAMAccountName in AD
In-Reply-To: <42935589-9E1B-4E2A-BD45-EFCD7C0127C3@oracle.com>
References: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com>
 <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com>
 <5a56bb03-42c7-74af-8a73-228803209ece@redhat.com>
 <5e4d1d7a-22f0-8f89-04de-acf1e5d14482@redhat.com>
 <42935589-9E1B-4E2A-BD45-EFCD7C0127C3@oracle.com>
Message-ID: <217ba90b-e708-bed5-4320-280717aa10fd@redhat.com>

Hi Max,

Thanks for having a look at the CSR.

On 3/30/20 11:39 PM, Weijun Wang wrote:
> 1. I don't think there is a need to talk about the java.security.krb5.conf system property, the krb5.conf file name is more popular.
> 

Added a reference to the krb5.conf file in the first place. I wish we
could keep a reference to the System property for completeness.

> 2. I'd rather always say "TGS requests" instead of "AP requests".
> 

Changed. This also helped me to fix an AS/AP typo.

I set the target release to JDK-15.

Look forward to the CSR approval.

Thanks,
Martin.-



From weijun.wang at oracle.com  Wed Apr  1 00:50:44 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 1 Apr 2020 08:50:44 +0800
Subject: RFR 8239385: KerberosTicket client name refers wrongly to
 sAMAccountName in AD
In-Reply-To: <217ba90b-e708-bed5-4320-280717aa10fd@redhat.com>
References: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com>
 <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com>
 <5a56bb03-42c7-74af-8a73-228803209ece@redhat.com>
 <5e4d1d7a-22f0-8f89-04de-acf1e5d14482@redhat.com>
 <42935589-9E1B-4E2A-BD45-EFCD7C0127C3@oracle.com>
 <217ba90b-e708-bed5-4320-280717aa10fd@redhat.com>
Message-ID: <EFA894C4-2131-4DB0-8161-33A23E9F0B36@oracle.com>



> On Apr 1, 2020, at 8:22 AM, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Max,
> 
> Thanks for having a look at the CSR.
> 
> On 3/30/20 11:39 PM, Weijun Wang wrote:
>> 1. I don't think there is a need to talk about the java.security.krb5.conf system property, the krb5.conf file name is more popular.
>> 
> 
> Added a reference to the krb5.conf file in the first place. I wish we
> could keep a reference to the System property for completeness.

OK. I just want to emphasize that we are following MIT krb5 the reference implementation of krb5, but not inventing something new.

--Max

> 
>> 2. I'd rather always say "TGS requests" instead of "AP requests".
>> 
> 
> Changed. This also helped me to fix an AS/AP typo.
> 
> I set the target release to JDK-15.
> 
> Look forward to the CSR approval.
> 
> Thanks,
> Martin.-
> 



From weijun.wang at oracle.com  Wed Apr  1 01:10:20 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 1 Apr 2020 09:10:20 +0800
Subject: RFR 8241960: The SHA3 message digests are not thread safe when
 cloned
In-Reply-To: <784d0590-357d-1da0-ba01-49fed43ad6b3@oracle.com>
References: <065849EF-ED24-4C50-AA9A-209D5890B074@azul.com>
 <784d0590-357d-1da0-ba01-49fed43ad6b3@oracle.com>
Message-ID: <4235234E-1D88-452C-AED3-A1DC673BDF0D@oracle.com>



> On Apr 1, 2020, at 4:01 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Hi Alexey,
> 
> Good catch, thanks for the report, I will review it.
> 
> On a first look, it seems that this is more about the clone() method of the SHA-3 impl missed copying/cloning an internal field.
> 
> Given that this is about SUN provider, I've modified the synopsis accordingly and move the priority up to P3.
> 
> It may not take multi-thread to reproduce this? If so, we can simplify the regression test.

Looks like a must:

    private void keccak() {
        // convert the 200-byte state into 25 lanes
        bytes2Lanes(state, lanes);
        // process the lanes through step mappings
        for (int ir = 0; ir < NR; ir++) {
            smIota(smChi(smPiRho(smTheta(lanes))), ir);
        }
        // convert the resulting 25 lanes back into 200-byte state
        lanes2Bytes(lanes, state);
    }

One object's lanes can only be used by another if this method is called by multiple threads at the same time.

--Max

> 
> Regards,
> Valerie
> On 3/31/2020 11:27 AM, Alexey Bakhtin wrote:
>> Hi All,
>> 
>> Please review fix for SHA3 message digests thread safety.
>> Issue reproduced on the JDK11, JDK13 and JDK14
>> JTREG test is provided in the patch
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8241960
>> Webrev: https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v0/
>> 
>> Regards
>> Alexey
>> 



From valerie.peng at oracle.com  Wed Apr  1 04:12:39 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 31 Mar 2020 21:12:39 -0700
Subject: RFR 8241960: The SHA3 message digests are not thread safe when
 cloned
In-Reply-To: <4235234E-1D88-452C-AED3-A1DC673BDF0D@oracle.com>
References: <065849EF-ED24-4C50-AA9A-209D5890B074@azul.com>
 <784d0590-357d-1da0-ba01-49fed43ad6b3@oracle.com>
 <4235234E-1D88-452C-AED3-A1DC673BDF0D@oracle.com>
Message-ID: <5c3137c8-8345-7f3b-b917-50b743e57cda@oracle.com>


Right, with a closer look, it does require multiple threads to trigger 
this problem.

Valerie


On 3/31/2020 6:10 PM, Weijun Wang wrote:
>
>> On Apr 1, 2020, at 4:01 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Hi Alexey,
>>
>> Good catch, thanks for the report, I will review it.
>>
>> On a first look, it seems that this is more about the clone() method of the SHA-3 impl missed copying/cloning an internal field.
>>
>> Given that this is about SUN provider, I've modified the synopsis accordingly and move the priority up to P3.
>>
>> It may not take multi-thread to reproduce this? If so, we can simplify the regression test.
> Looks like a must:
>
>      private void keccak() {
>          // convert the 200-byte state into 25 lanes
>          bytes2Lanes(state, lanes);
>          // process the lanes through step mappings
>          for (int ir = 0; ir < NR; ir++) {
>              smIota(smChi(smPiRho(smTheta(lanes))), ir);
>          }
>          // convert the resulting 25 lanes back into 200-byte state
>          lanes2Bytes(lanes, state);
>      }
>
> One object's lanes can only be used by another if this method is called by multiple threads at the same time.
>
> --Max
>
>> Regards,
>> Valerie
>> On 3/31/2020 11:27 AM, Alexey Bakhtin wrote:
>>> Hi All,
>>>
>>> Please review fix for SHA3 message digests thread safety.
>>> Issue reproduced on the JDK11, JDK13 and JDK14
>>> JTREG test is provided in the patch
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8241960
>>> Webrev: https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v0/
>>>
>>> Regards
>>> Alexey
>>>


From weijun.wang at oracle.com  Wed Apr  1 07:22:15 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 1 Apr 2020 15:22:15 +0800
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <7aca5038-026f-3319-7046-e617895b6ab1@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <E2A838B8-0CC1-4561-ACA4-F5676031DFDD@oracle.com>
 <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com>
 <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com>
 <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com>
 <3e6359a0-b165-942f-4371-cc67cdd1af89@oracle.com>
 <7aca5038-026f-3319-7046-e617895b6ab1@oracle.com>
Message-ID: <FE737B38-A84E-4EEA-8CBC-6D3849FE04D6@oracle.com>

While SignatureSpi says engineGetParameters() would throw an UOE when it's not overridden, it is not specified in Signature::getParameters:

     * <p> If this signature has been previously initialized with parameters
     * (by calling the {@code setParameter} method), this method returns
     * the same parameters. If this signature has not been initialized with
     * parameters, this method may return a combination of default and
     * randomly generated parameter values if the underlying
     * signature implementation supports it and can successfully generate
     * them. Otherwise, {@code null} is returned.

I'm afraid we'll have to return something here, maybe a mixture of a curve name and fields inside EdDSAParameterSpec.

--Max

> On Mar 31, 2020, at 12:25 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> On 3/30/20 8:52 PM, Anthony Scarpino wrote:
>> On 3/30/20 7:54 PM, Weijun Wang wrote:
>>> 
>>> 
>>>> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>> 
>>>> On 3/30/20 11:52 AM, Anthony Scarpino wrote:
>>>>> On 3/30/20 6:21 AM, Weijun Wang wrote:
>>>>>> I was playing with keytool with your patch and noticed
>>>>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an
>>>>>> EdECKey. While we use curve name instead of key size in EC to
>>>>>> describe the parameters, the size is still useful in determining the
>>>>>> strength.
>>>>> I think I should be able to access the parameter with the key's NamedParameterSpec to return the size.
>>>> 
>>>> I was wrong about this.  The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class.
>>>> 
>>>> The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc.
>>> 
>>> Yes.
>>> 
>>>> 
>>>> Tony
>>>> 
>>>>>> 
>>>>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm
>>>>>> not involved with previous discussions on EdDSA design, but why does
>>>>>> EdDSASignature.engineGetParameters() throw an UOE?
>>>>> Because the public API for engineGetParameter(String param) is deprecated would be my suspicion.
>>> 
>>> engineGetParameter() is deprecated, engineGetParameters() is not.
>> Oh sorry.  I'm not sure why, but I have to ask the question what is the point of this method?  If the user needs to set the parameters to do the a signature of verify, what is the need for a method that gets the parameter from Signature that should have just set?  Are the parameters returned changed from the initial setting?  In the EdDSA case they are not.
>> I don't have an immediate problem in having EdDSA return the same parameters back, I'm just not sure why it's necessary and I haven't see anything in the JEP as to why Adam decided against this.
>> Tony
> 
> Ok.. That's frustrating that engineSetParameters takes AlgorithmParameterSpec, but engineGetParameters returns AlgorithmParameter.  That confused me.
> 
> So I would say the reason EdDSASignature.engineGetParameters() is UOE is because the parameters are not exposed publicly.  The NamedParameterSpec tells the internals of EdDSA what parameters to use.  I know this to be a choice by Adam as he found it unnecessary to expose APIs that were unnecessary at this time with predefined EdDSA curves and with a implementation that did not allow arbitrary curves.
> 
> Tony
> 
>>> 
>>>>>> Another small problem:
>>>>>> 
>>>>>> You reverted the copyright year from 2020 to an earlier year in
>>>>>> module-info.java, keytool/Main.java.
>>>>> The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset.
>>> 
>>> Ah yes, I applied your patch to my old repo.
>>> 
>>> --Max
>>> 
>>>>>> 
>>>>>> Thanks, Max
>>>>>> 
>>>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino
>>>>>>> <anthony.scarpino at oracle.com> wrote:
>>>>>>> 
>>>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>>>>> Hi I need a code review for the EdDSA support in JEP 339.  The
>>>>>>>> code builds on the existing java implemented constant time
>>>>>>>> classes used for XDH and the NIST curves.  The change also adds
>>>>>>>> classes to the public API to support EdDSA operations. All
>>>>>>>> information about the JEP is located at: JEP 339:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev:
>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony
>>>>>>> 
>>>>>>> 
>>>>>>> I updated the webrev with some minor updates that were commented
>>>>>>> previously.
>>>>>>> 
>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>>>>> 
>>>>>>> Tony



From norman.maurer at googlemail.com  Wed Apr  1 07:32:43 2020
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Wed, 1 Apr 2020 09:32:43 +0200
Subject: Possible regression in JDK 14 related to SSLSessionContext /
 SSLSession on the server side
In-Reply-To: <ec76eec5-a358-f422-5b5d-fc4d1c22ccd6@oracle.com>
References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com>
 <c1535554-dbda-01a2-8e12-2fde5b65df3c@oracle.com>
 <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com>
 <e20df59f-9946-6015-22dc-284658c8a09b@oracle.com>
 <DF08DC63-3056-4982-ADC1-029C9A5417E2@googlemail.com>
 <ec76eec5-a358-f422-5b5d-fc4d1c22ccd6@oracle.com>
Message-ID: <8B48D9A2-D71C-44B3-B9B4-25F1436D1FE6@googlemail.com>

Please add a link to the bug once it is created.

Bye
Norman


> On 31. Mar 2020, at 17:35, Jamil Nimeh <jamil.j.nimeh at Oracle.Com> wrote:
> 
> Thanks Norman, I'm going to file a bug on this one.  After playing with it a bit more I found cases where even SSLServerSockets do run into the issue but it doesn't always happen.  Still working on characterizing it.
> 
> --Jamil
> 
> On 3/31/2020 7:11 AM, Norman Maurer wrote:
>> Yes thats about right? if setting to false it works as expected.
>> 
>> 
>> Bye
>> Norman
>> 
>> 
>>> On 31. Mar 2020, at 01:50, Jamil Nimeh <jamil.j.nimeh at Oracle.Com <mailto:jamil.j.nimeh at Oracle.Com>> wrote:
>>> 
>>> Hi Norman,
>>> 
>>> I've been able to run your test code and I can reproduce it.  Interestingly enough, it appears to happen when -Djdk.tls.server.enableSessionTicketExtension=true, which is the default position.  With session tickets enabled, I would see the issue in TLS 1.3 and 1.2 connections just as you did.  Setting the above property to false however allowed me to make successful connections.  Would you mind setting that property to false, just to make sure you and I see the same thing?
>>> 
>>> I did go back and run SSLServerSocket-based connections just to see if the session ticket settings had any impact on things, but they don't.  I can make connections to a socket based SSL server regardless of the property value on the server side.
>>> 
>>> Thanks,
>>> 
>>> --Jamil
>>> 
>>> On 3/30/2020 5:31 AM, Norman Maurer wrote:
>>>> Hey Sean,
>>>> 
>>>> There is not much to share as its just a simple handshake :)
>>>> 
>>>> Anyway here is a reproducer:
>>>> 
>>>> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer <https://github.com/normanmaurer/jdk_ssl_session_context_reproducer>
>>>> 
>>>> It basically does nothing more then complete the handshake and then calling engine.getSession().getSessionContext() which will return null on the server side since JDK 14 (earlier versions work).
>>>> I tested it with TLSv1.2 and TLSv1.3 and both times it produced the error on JDK 14.
>>>> 
>>>> 
>>>> Bye
>>>> Norman
>>>> 
>>>> 
>>>>> On 30. Mar 2020, at 13:22, Se?n Coffey <sean.coffey at oracle.com <mailto:sean.coffey at oracle.com>> wrote:
>>>>> 
>>>>> Looks interesting Norman. Do you want to share some more details about the peculiarities of this handshake before considering a fully fledged testcase ?
>>>>> 
>>>>> regards,
>>>>> Sean.
>>>>> 
>>>>> On 27/03/2020 12:48, Norman Maurer wrote:
>>>>>> Hi there,
>>>>>> 
>>>>>> I am just about to add JDK14 to the test matrix for netty and think I found a regression. Before I will invest time to write a standalone reproducer please let me know if you think this is a regression or not.
>>>>>> Basically after the handshake is complete SSLEngine.getSession().getSessionContext() returns null on the serverside when using JDK14. Running the same test with any previous version (JDK13 and earlier) doesn?t show the same result.
>>>>>> 
>>>>>> Does this sounds like a regression and if so should I provide a standalone reproducer here ?
>>>>>> 
>>>>>> Bye
>>>>>> Norman
>>>>>> 
>>>> 
>> 

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

From weijun.wang at oracle.com  Wed Apr  1 09:59:36 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 1 Apr 2020 17:59:36 +0800
Subject: [15] RFR 8241761 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (security-libs only)
In-Reply-To: <590603c4-d9b9-ac16-b0a7-c3be927efbe7@oracle.com>
References: <590603c4-d9b9-ac16-b0a7-c3be927efbe7@oracle.com>
Message-ID: <5027FFFF-6E24-4C3C-AAB9-B5E9EDD9C7A8@oracle.com>

Looks fine to me.

If I have to pick one tiny problem, you can remove a blank in line 58 below to make the indentation more precise:

src/java.security.sasl/share/classes/javax/security/sasl/SaslServer.java:

  57  *             status = ldap.sendBindResponse(mechanism, challenge,
  58  *                  SASL_BIND_IN_PROGRESS);

Thanks,
Max


> On Mar 31, 2020, at 5:39 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> Hello!
> 
> The fix follows up on JDK-8241727 [1].
> 
> This is a javadoc/comments only fix in the security-libs area.
> 
> The changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony.
> 
> Would you please help review this rather technical fix?
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241761
> WEBREV: http://cr.openjdk.java.net/~igerasim/8241761/00/webrev/
> 
> Thank in advance!
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8241727
> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 



From michael.osipov at siemens.com  Wed Apr  1 16:21:45 2020
From: michael.osipov at siemens.com (Osipov, Michael)
Date: Wed, 1 Apr 2020 18:21:45 +0200
Subject: Evaluation part 1 of JDK-6722928: Provide a default native GSS-API
 library on Windows
Message-ID: <8e63c57f-68d0-0294-3741-784492b51de1@siemens.com>

Hi Max,

at last I took some time to evaluate you SSPI bridge. This is part one. 
Interaction evaluation will follow in a second email.

Assumptions:
* All methods, objects behave the same as with JGSS
* AcceptSecurityContext is not implemented so should everything 
associated with it fail (GSSException)
* Code analysis happens based on 
https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/master/src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
and zulu13.29.9-ca-jdk13.0.2-win_x64

Findings C:
* sspi.cpp: Would it make sense to replace "__declspec(dllexport)" with 
JNIEXPORT?
* GSSManager#createCredential(): I'd expect an exception when *not* 
GSSCredential.INITIATE_ONLY is requested/passed
* sspi.cpp#L67-L68: Feels a bit awkward to permit SSPI_BRIDGE_TRACE="". 
Why not have "if (trace && *trace)"?
* sspi.cpp#L233: The function name says "show_oid", but I see no OID 
printed. Simply symbolic names.
* sspi.cpp#L290: Empty string check? like (realm && *realm)
* Usage of %p: If you don't know that %p is used it is hard to tell why 
this output is there. May turn to "at 0x%p" in general?
* sspi.cpp#L359: -2!= reads awkward. Reformat?
* sspi.cpp#L482-L483: This is highly questionable. While it is true for 
Windows, it does not stick to gss_compare_name behavior. Don't know what 
the correct approach would be here.
* sspi.cpp#L595: That's weird. A string leads to a length? Should it 
read: PP("Name found: %ls -> %s [%d]", names, buffer, len)
* sspi.cpp#L618: You are resetting cred_usage passed with the function. 
This looks like a bug to me.
* sspi.cpp#L619: Reads very bad, maybe turn into 
"PP("AcquireCredentialsHandle with usage: %d, creds: 0x%p", cred_usage, 
desired_mechs)"
* sspi.cpp#L627-L633: Trace message could be more expressive, e.g., 
"Requesting Kerberos mech"
* sspi.cpp#L657-L658 and sspi.cpp#L687-L688: They look wrong and do not 
correspond to GSSCredentialImpl.java#L628-L640. default value should be 
INITIATE_AND_ACCEPT.
   Same as in GSS-API:
$ sudo python3
 > Python 3.7.7 (default, Mar 19 2020, 21:26:00)
 > [Clang 9.0.1 (git at github.com:llvm/llvm-project.git 
c1a0a213378a458fbea1a5c77b31 on freebsd12
 > Type "help", "copyright", "credits" or "license" for more information.
 > >>> import gssapi
 > >>> cred = gssapi.Credentials(usage='nonsense')
 > >>> cred.usage
 > 'both'
This also may be a bug in py-gssapi/MIT Kerberos
* sspi.cpp#L149
** Can you apply a better output like ISO 8601? In strftime(3) that 
would be "%FT%T, ..."
** "%uld" does not seem to work here: 4294967295ld. Shouldn't that read 
"%"PRIu32" seconds" or "%lu seconds"?
* sspi.cpp#L744: "Comparison result: %d". You are not comparing the 
result, but print comparsion result.
* sspi.cpp#L841: man 3 gss_import_sec_context says: GSS_S_UNAVAILABLE
* sspi.cpp#L977-L979: Not helpful when the SEC_E_* not mapped to 
major/minor. This likely applies to most mapping functions.
* sspi.cpp#L1012: Maybe: "Names: client: %s, server: %s"?
* sspi.cpp#L1046: Maybe like gss_export_sec_context?
* sspi.cpp#L1169: Remove word "IMPLEMENTED"
* sspi.cpp#L1169: Maybe like gss_export_sec_context?
* sspi.cpp#L1480: Includes a trailing, redundant newline
* sspi.cpp#L729-L748: Why do you do this? The documentation for 
parameter 1 says: If the process that requests the handle does not have 
access to the credentials, the function returns an error. I have 
verified this with py-win32: win32security.AcquireCredentialsHandle(). 
Infact, it accepts any principal and always returns the default one. I 
found these:
** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
 > >>> cred, time = 
win32security.AcquireCredentialsHandle("Administrator at ORACLE.COM", 
"Kerberos", win32security.SECPKG_CRED_OUTBOUND, None, None)
 > >>> cred.QueryCredentialsAttributes(1)
 > 'osipovmi at AD001.SIEMENS.NET'


Findings Java:
* GssManager#createCredential() with ACCEPT_ONLY or INITIATE_AND_ACCEPT 
gives me weird credentials with partial null nembers. I'd expect an 
exception here.
* This is one fails, but shall work:
 > GSSManager manager = GSSManager.getInstance();
 > GSSName userName = manager.createName("osipovmi", GSSName.NT_USER_NAME);
 > GSSCredential cred = manager.createCredential(userName, 
GSSCredential.DEFAULT_LIFETIME, krb5Oid, GSSCredential.INITIATE_ONLY);
 > [SSPI:1627] >>>> Calling gss_create_empty_oid_set...
 > [SSPI:1542] >>>> Calling gss_add_oid_set_member...
 > [SSPI:612] >>>> Calling gss_acquire_cred...
 > [SSPI:619] AcquireCredentialsHandle with 0 00000257FFB199B0
 > [SSPI:262] gss_OID_set.count is 1
 > [SSPI:237] Kerberos mech
 > [SSPI:628] reqKerberos
 > [SSPI:152] cred expiration: 09/13/30828  04:48 4294967295ld
 > [SSPI:732] Acquiring cred with a name. Check if it's me.
 > [SSPI:791] >>>> Calling gss_inquire_cred...
 > [SSPI:811] Allocate new name at 00000257FFB2BC40
 > [SSPI:428] >>>> Calling gss_compare_name...
 > [SSPI:437] Comparing osipovmi at AD001.SIEMENS.NET and osipovmi
 > [SSPI:325] >>>> Calling gss_release_name 00000257FFB17830...
 > [SSPI:744] Comparing result: 0
 > [SSPI:767] >>>> Calling gss_release_cred...
 > [SSPI:1641] >>>> Calling gss_release_oid_set...
 > Exception in thread "main" GSSException: Failure unspecified at 
GSS-API level
 > 	at 
java.security.jgss/sun.security.jgss.wrapper.GSSLibStub.acquireCred(Native 
Method)

The problem is that I provide a local name and expect the default realm 
to be used. It seems like #createCredential() does not take that into 
account. It also has no avail when the canonicalized form is used. See 
sspi.cpp#L729-L748.
* GssManager#createContext(GSSCredential) still works although this 
should be a acceptor context. I expect an expception. Does not fail with 
JGSS either. MIT Kerberos with py-gssapi properly fails:
 > >>> cred = gssapi.Credentials(usage='accept') 
                                   >>> cred
 > <gssapi.creds.Credentials object at 0x80164bbb0>
 > >>> context = gssapi.SecurityContext(usage='initiate', creds=cred, 
name=canon_name, mech=gssapi.MechType.kerberos)
 > >>> context.step(None)
 > Traceback (most recent call last):
 >   File "<stdin>", line 1, in <module>
 >   File "<decorator-gen-15>", line 2, in step
 >   File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", 
line 167, in check_last_err
 >     return func(self, *args, **kwargs)
 >   File "<decorator-gen-5>", line 2, in step
 >   File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", 
line 127, in catch_and_return_token
 >     return func(self, *args, **kwargs)
 >   File 
"/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 
521, in step
 >     return self._initiator_step(token=token)
 >   File 
"/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 
542, in _initiator_step
 >     token)
 >   File "gssapi/raw/sec_contexts.pyx", line 245, in 
gssapi.raw.sec_contexts.init_sec_context
 > gssapi.raw.exceptions.MissingCredentialsError: Major (458752): Es 
wurden keine Anmeldedaten ?bergeben oder die Anmeldedaten waren nicht 
verf?gbar bzw. ein Zugriff darauf nicht m?glich., Minor (100001): 
Unknown code 0

That's it for now.

Michael


From sean.mullan at oracle.com  Wed Apr  1 19:47:36 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 1 Apr 2020 15:47:36 -0400
Subject: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property
 with a security one
In-Reply-To: <74433961-0fb3-c388-9906-fc3bcf5a9a23@redhat.com>
References: <74433961-0fb3-c388-9906-fc3bcf5a9a23@redhat.com>
Message-ID: <63bb7e08-0883-b610-0fc7-9ed9bc3a1a99@oracle.com>

On 3/30/20 7:58 PM, Martin Balao wrote:
> Hi,
> 
> I'd like to request a review for 8241888 [1].
> 
> Webrev.00:
> 
>   * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.00/

* PKIXValidator

65      * System property that if set (or set to "true"), allows trust 
anchor

Change this to "System or security property ..."

- Update the copyright date.

* java.security

1308 # X.509 v3 certificates used as Trusted Anchors (to validate signed 
code or TLS

s/Trusted/Trust

You should also say that if they include a Key Usage extension, the 
keyCertSign bit must be set.

--Sean

> 
> CSR (waiting for review): https://bugs.openjdk.java.net/browse/JDK-8241893
> 
> I've not included my regression test as it's a trivial change and my
> test is actually testing SecurityProperties -which has already been tested-.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8241888
> 


From jamil.j.nimeh at oracle.com  Wed Apr  1 21:37:28 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 1 Apr 2020 14:37:28 -0700
Subject: Possible regression in JDK 14 related to SSLSessionContext /
 SSLSession on the server side
In-Reply-To: <8B48D9A2-D71C-44B3-B9B4-25F1436D1FE6@googlemail.com>
References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com>
 <c1535554-dbda-01a2-8e12-2fde5b65df3c@oracle.com>
 <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com>
 <e20df59f-9946-6015-22dc-284658c8a09b@oracle.com>
 <DF08DC63-3056-4982-ADC1-029C9A5417E2@googlemail.com>
 <ec76eec5-a358-f422-5b5d-fc4d1c22ccd6@oracle.com>
 <8B48D9A2-D71C-44B3-B9B4-25F1436D1FE6@googlemail.com>
Message-ID: <5cc5e4d7-74a3-5252-574a-a761017bd294@oracle.com>

Hi Norman, session context issue is here:

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

--Jamil

On 4/1/2020 12:32 AM, Norman Maurer wrote:
> Please add a link to the bug once it is created.
>
> Bye
> Norman
>
>
>> On 31. Mar 2020, at 17:35, Jamil Nimeh <jamil.j.nimeh at Oracle.Com 
>> <mailto:jamil.j.nimeh at Oracle.Com>> wrote:
>>
>> Thanks Norman, I'm going to file a bug on this one.? After playing 
>> with it a bit more I found cases where even SSLServerSockets do run 
>> into the issue but it doesn't always happen.? Still working on 
>> characterizing it.
>>
>> --Jamil
>>
>> On 3/31/2020 7:11 AM, Norman Maurer wrote:
>>> Yes thats about right? if setting to false it works as expected.
>>>
>>>
>>> Bye
>>> Norman
>>>
>>>
>>>> On 31. Mar 2020, at 01:50, Jamil Nimeh <jamil.j.nimeh at Oracle.Com 
>>>> <mailto:jamil.j.nimeh at Oracle.Com>> wrote:
>>>>
>>>> Hi Norman,
>>>>
>>>> I've been able to run your test code and I can reproduce it. 
>>>> Interestingly enough, it appears to happen when 
>>>> -Djdk.tls.server.enableSessionTicketExtension=true, which is the 
>>>> default position.? With session tickets enabled, I would see the 
>>>> issue in TLS 1.3 and 1.2 connections just as you did.? Setting the 
>>>> above property to false however allowed me to make successful 
>>>> connections.? Would you mind setting that property to false, just 
>>>> to make sure you and I see the same thing?
>>>>
>>>> I did go back and run SSLServerSocket-based connections just to see 
>>>> if the session ticket settings had any impact on things, but they 
>>>> don't.? I can make connections to a socket based SSL server 
>>>> regardless of the property value on the server side.
>>>>
>>>> Thanks,
>>>>
>>>> --Jamil
>>>>
>>>> On 3/30/2020 5:31 AM, Norman Maurer wrote:
>>>>> Hey Sean,
>>>>>
>>>>> There is not much to share as its just a simple handshake :)
>>>>>
>>>>> Anyway here is a reproducer:
>>>>>
>>>>> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer
>>>>>
>>>>> It basically does nothing more then complete the handshake and 
>>>>> then calling engine.getSession().getSessionContext() which will 
>>>>> return null on the server side since JDK 14 (earlier versions work).
>>>>> I tested it with TLSv1.2 and TLSv1.3 and both times it produced 
>>>>> the error on JDK 14.
>>>>>
>>>>>
>>>>> Bye
>>>>> Norman
>>>>>
>>>>>
>>>>>> On 30. Mar 2020, at 13:22, Se?n Coffey <sean.coffey at oracle.com 
>>>>>> <mailto:sean.coffey at oracle.com>> wrote:
>>>>>>
>>>>>> Looks interesting Norman. Do you want to share some more details 
>>>>>> about the peculiarities of this handshake before considering a 
>>>>>> fully fledged testcase ?
>>>>>>
>>>>>> regards,
>>>>>> Sean.
>>>>>>
>>>>>> On 27/03/2020 12:48, Norman Maurer wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> I am just about to add JDK14 to the test matrix for netty and 
>>>>>>> think I found a regression. Before I will invest time to write a 
>>>>>>> standalone reproducer please let me know if you think this is a 
>>>>>>> regression or not.
>>>>>>> Basically after the handshake is complete 
>>>>>>> SSLEngine.getSession().getSessionContext() returns null on the 
>>>>>>> serverside when using JDK14. Running the same test with any 
>>>>>>> previous version (JDK13 and earlier) doesn?t show the same result.
>>>>>>>
>>>>>>> Does this sounds like a regression and if so should I provide a 
>>>>>>> standalone reproducer here ?
>>>>>>>
>>>>>>> Bye
>>>>>>> Norman
>>>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200401/9ac6d686/attachment.htm>

From mbalao at redhat.com  Wed Apr  1 21:53:27 2020
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 1 Apr 2020 18:53:27 -0300
Subject: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property
 with a security one
In-Reply-To: <63bb7e08-0883-b610-0fc7-9ed9bc3a1a99@oracle.com>
References: <74433961-0fb3-c388-9906-fc3bcf5a9a23@redhat.com>
 <63bb7e08-0883-b610-0fc7-9ed9bc3a1a99@oracle.com>
Message-ID: <2730a678-652a-af29-285d-ce25220e4089@redhat.com>

Hi Sean,

Thanks for having a look at this.

On 4/1/20 4:47 PM, Sean Mullan wrote:
> 
> 65????? * System property that if set (or set to "true"), allows trust
> anchor
> 
> Change this to "System or security property ..."

Fixed.

> 
> - Update the copyright date.

Fixed.

> 
> * java.security
> 
> 1308 # X.509 v3 certificates used as Trusted Anchors (to validate signed
> code or TLS
> 
> s/Trusted/Trust

Fixed.

> 
> You should also say that if they include a Key Usage extension, the
> keyCertSign bit must be set.

Fixed.

Webrev.01:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.01/

Thanks,
Martin.-




From anthony.scarpino at oracle.com  Thu Apr  2 01:21:08 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 1 Apr 2020 18:21:08 -0700
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <FE737B38-A84E-4EEA-8CBC-6D3849FE04D6@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <E2A838B8-0CC1-4561-ACA4-F5676031DFDD@oracle.com>
 <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com>
 <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com>
 <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com>
 <3e6359a0-b165-942f-4371-cc67cdd1af89@oracle.com>
 <7aca5038-026f-3319-7046-e617895b6ab1@oracle.com>
 <FE737B38-A84E-4EEA-8CBC-6D3849FE04D6@oracle.com>
Message-ID: <e9713843-91ad-cee6-9e5d-ccc4b934fdcb@oracle.com>


I understand what the spec says, but here is why I believe the code 
returns UOE.

EdDSASignature.setParameters only takes EdDSAParameterSpec and does not 
take NamedParameterSpec, which can define the curve.  The curve is 
defined during getInstance().  While there is an ASN.1 for the curve 
there is none defined for the values contained in EdDSAParameterSpec, 
prehash and context.  https://tools.ietf.org/html/rfc8410#page-3

I think it is confusing for EdDSASignature.getParameters() to give a 
AlgorithmParameters class that provides NamedParameterSpec which cannot 
be used with EdDSASignature.setParameters().

Below is what I could do to satisfy the API. I'm just not sure it has 
any more value than that:
 
https://cr.openjdk.java.net/~ascarpino/8166597/webrev.04/raw_files/new/src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAAlgorithmParameters.java

Tony

On 4/1/20 12:22 AM, Weijun Wang wrote:
> While SignatureSpi says engineGetParameters() would throw an UOE when it's not overridden, it is not specified in Signature::getParameters:
> 
>       * <p> If this signature has been previously initialized with parameters
>       * (by calling the {@code setParameter} method), this method returns
>       * the same parameters. If this signature has not been initialized with
>       * parameters, this method may return a combination of default and
>       * randomly generated parameter values if the underlying
>       * signature implementation supports it and can successfully generate
>       * them. Otherwise, {@code null} is returned.
> 
> I'm afraid we'll have to return something here, maybe a mixture of a curve name and fields inside EdDSAParameterSpec.
> 
> --Max
> 
>> On Mar 31, 2020, at 12:25 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>
>> On 3/30/20 8:52 PM, Anthony Scarpino wrote:
>>> On 3/30/20 7:54 PM, Weijun Wang wrote:
>>>>
>>>>
>>>>> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>>
>>>>> On 3/30/20 11:52 AM, Anthony Scarpino wrote:
>>>>>> On 3/30/20 6:21 AM, Weijun Wang wrote:
>>>>>>> I was playing with keytool with your patch and noticed
>>>>>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an
>>>>>>> EdECKey. While we use curve name instead of key size in EC to
>>>>>>> describe the parameters, the size is still useful in determining the
>>>>>>> strength.
>>>>>> I think I should be able to access the parameter with the key's NamedParameterSpec to return the size.
>>>>>
>>>>> I was wrong about this.  The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class.
>>>>>
>>>>> The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc.
>>>>
>>>> Yes.
>>>>
>>>>>
>>>>> Tony
>>>>>
>>>>>>>
>>>>>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm
>>>>>>> not involved with previous discussions on EdDSA design, but why does
>>>>>>> EdDSASignature.engineGetParameters() throw an UOE?
>>>>>> Because the public API for engineGetParameter(String param) is deprecated would be my suspicion.
>>>>
>>>> engineGetParameter() is deprecated, engineGetParameters() is not.
>>> Oh sorry.  I'm not sure why, but I have to ask the question what is the point of this method?  If the user needs to set the parameters to do the a signature of verify, what is the need for a method that gets the parameter from Signature that should have just set?  Are the parameters returned changed from the initial setting?  In the EdDSA case they are not.
>>> I don't have an immediate problem in having EdDSA return the same parameters back, I'm just not sure why it's necessary and I haven't see anything in the JEP as to why Adam decided against this.
>>> Tony
>>
>> Ok.. That's frustrating that engineSetParameters takes AlgorithmParameterSpec, but engineGetParameters returns AlgorithmParameter.  That confused me.
>>
>> So I would say the reason EdDSASignature.engineGetParameters() is UOE is because the parameters are not exposed publicly.  The NamedParameterSpec tells the internals of EdDSA what parameters to use.  I know this to be a choice by Adam as he found it unnecessary to expose APIs that were unnecessary at this time with predefined EdDSA curves and with a implementation that did not allow arbitrary curves.
>>
>> Tony
>>
>>>>
>>>>>>> Another small problem:
>>>>>>>
>>>>>>> You reverted the copyright year from 2020 to an earlier year in
>>>>>>> module-info.java, keytool/Main.java.
>>>>>> The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset.
>>>>
>>>> Ah yes, I applied your patch to my old repo.
>>>>
>>>> --Max
>>>>
>>>>>>>
>>>>>>> Thanks, Max
>>>>>>>
>>>>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino
>>>>>>>> <anthony.scarpino at oracle.com> wrote:
>>>>>>>>
>>>>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>>>>>> Hi I need a code review for the EdDSA support in JEP 339.  The
>>>>>>>>> code builds on the existing java implemented constant time
>>>>>>>>> classes used for XDH and the NIST curves.  The change also adds
>>>>>>>>> classes to the public API to support EdDSA operations. All
>>>>>>>>> information about the JEP is located at: JEP 339:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev:
>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony
>>>>>>>>
>>>>>>>>
>>>>>>>> I updated the webrev with some minor updates that were commented
>>>>>>>> previously.
>>>>>>>>
>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>>>>>>
>>>>>>>> Tony
> 



From weijun.wang at oracle.com  Thu Apr  2 01:44:31 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 2 Apr 2020 09:44:31 +0800
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <e9713843-91ad-cee6-9e5d-ccc4b934fdcb@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <E2A838B8-0CC1-4561-ACA4-F5676031DFDD@oracle.com>
 <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com>
 <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com>
 <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com>
 <3e6359a0-b165-942f-4371-cc67cdd1af89@oracle.com>
 <7aca5038-026f-3319-7046-e617895b6ab1@oracle.com>
 <FE737B38-A84E-4EEA-8CBC-6D3849FE04D6@oracle.com>
 <e9713843-91ad-cee6-9e5d-ccc4b934fdcb@oracle.com>
Message-ID: <0D196885-AD5A-4759-8713-C68244A9BF97@oracle.com>

Two comments:

1. Signature::getParameters explicitly specifies that the return value should match that set in setParameter(). Therefore although the types of params are different we need to make sure the contents are essentially the same. This means the getParameters() result should be designed after EdDSAParameterSpec.

2. If the Signature is of "EDDSA" type (i.e. not ed25519 or ed448), then before calling initSign() one does not know what named curve will be used. This means the result will not include curve info.

--Max

> On Apr 2, 2020, at 9:21 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> 
> I understand what the spec says, but here is why I believe the code returns UOE.
> 
> EdDSASignature.setParameters only takes EdDSAParameterSpec and does not take NamedParameterSpec, which can define the curve.  The curve is defined during getInstance().  While there is an ASN.1 for the curve there is none defined for the values contained in EdDSAParameterSpec, prehash and context.  https://tools.ietf.org/html/rfc8410#page-3
> 
> I think it is confusing for EdDSASignature.getParameters() to give a AlgorithmParameters class that provides NamedParameterSpec which cannot be used with EdDSASignature.setParameters().
> 
> Below is what I could do to satisfy the API. I'm just not sure it has any more value than that:
> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.04/raw_files/new/src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAAlgorithmParameters.java
> 
> Tony
> 
> On 4/1/20 12:22 AM, Weijun Wang wrote:
>> While SignatureSpi says engineGetParameters() would throw an UOE when it's not overridden, it is not specified in Signature::getParameters:
>>      * <p> If this signature has been previously initialized with parameters
>>      * (by calling the {@code setParameter} method), this method returns
>>      * the same parameters. If this signature has not been initialized with
>>      * parameters, this method may return a combination of default and
>>      * randomly generated parameter values if the underlying
>>      * signature implementation supports it and can successfully generate
>>      * them. Otherwise, {@code null} is returned.
>> I'm afraid we'll have to return something here, maybe a mixture of a curve name and fields inside EdDSAParameterSpec.
>> --Max
>>> On Mar 31, 2020, at 12:25 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>> 
>>> On 3/30/20 8:52 PM, Anthony Scarpino wrote:
>>>> On 3/30/20 7:54 PM, Weijun Wang wrote:
>>>>> 
>>>>> 
>>>>>> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>>> 
>>>>>> On 3/30/20 11:52 AM, Anthony Scarpino wrote:
>>>>>>> On 3/30/20 6:21 AM, Weijun Wang wrote:
>>>>>>>> I was playing with keytool with your patch and noticed
>>>>>>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an
>>>>>>>> EdECKey. While we use curve name instead of key size in EC to
>>>>>>>> describe the parameters, the size is still useful in determining the
>>>>>>>> strength.
>>>>>>> I think I should be able to access the parameter with the key's NamedParameterSpec to return the size.
>>>>>> 
>>>>>> I was wrong about this.  The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class.
>>>>>> 
>>>>>> The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc.
>>>>> 
>>>>> Yes.
>>>>> 
>>>>>> 
>>>>>> Tony
>>>>>> 
>>>>>>>> 
>>>>>>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm
>>>>>>>> not involved with previous discussions on EdDSA design, but why does
>>>>>>>> EdDSASignature.engineGetParameters() throw an UOE?
>>>>>>> Because the public API for engineGetParameter(String param) is deprecated would be my suspicion.
>>>>> 
>>>>> engineGetParameter() is deprecated, engineGetParameters() is not.
>>>> Oh sorry.  I'm not sure why, but I have to ask the question what is the point of this method?  If the user needs to set the parameters to do the a signature of verify, what is the need for a method that gets the parameter from Signature that should have just set?  Are the parameters returned changed from the initial setting?  In the EdDSA case they are not.
>>>> I don't have an immediate problem in having EdDSA return the same parameters back, I'm just not sure why it's necessary and I haven't see anything in the JEP as to why Adam decided against this.
>>>> Tony
>>> 
>>> Ok.. That's frustrating that engineSetParameters takes AlgorithmParameterSpec, but engineGetParameters returns AlgorithmParameter.  That confused me.
>>> 
>>> So I would say the reason EdDSASignature.engineGetParameters() is UOE is because the parameters are not exposed publicly.  The NamedParameterSpec tells the internals of EdDSA what parameters to use.  I know this to be a choice by Adam as he found it unnecessary to expose APIs that were unnecessary at this time with predefined EdDSA curves and with a implementation that did not allow arbitrary curves.
>>> 
>>> Tony
>>> 
>>>>> 
>>>>>>>> Another small problem:
>>>>>>>> 
>>>>>>>> You reverted the copyright year from 2020 to an earlier year in
>>>>>>>> module-info.java, keytool/Main.java.
>>>>>>> The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset.
>>>>> 
>>>>> Ah yes, I applied your patch to my old repo.
>>>>> 
>>>>> --Max
>>>>> 
>>>>>>>> 
>>>>>>>> Thanks, Max
>>>>>>>> 
>>>>>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino
>>>>>>>>> <anthony.scarpino at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>>>>>>> Hi I need a code review for the EdDSA support in JEP 339.  The
>>>>>>>>>> code builds on the existing java implemented constant time
>>>>>>>>>> classes used for XDH and the NIST curves.  The change also adds
>>>>>>>>>> classes to the public API to support EdDSA operations. All
>>>>>>>>>> information about the JEP is located at: JEP 339:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev:
>>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I updated the webrev with some minor updates that were commented
>>>>>>>>> previously.
>>>>>>>>> 
>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>>>>>>> 
>>>>>>>>> Tony
> 



From anthony.scarpino at oracle.com  Thu Apr  2 02:45:15 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 1 Apr 2020 19:45:15 -0700
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <0D196885-AD5A-4759-8713-C68244A9BF97@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <E2A838B8-0CC1-4561-ACA4-F5676031DFDD@oracle.com>
 <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com>
 <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com>
 <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com>
 <3e6359a0-b165-942f-4371-cc67cdd1af89@oracle.com>
 <7aca5038-026f-3319-7046-e617895b6ab1@oracle.com>
 <FE737B38-A84E-4EEA-8CBC-6D3849FE04D6@oracle.com>
 <e9713843-91ad-cee6-9e5d-ccc4b934fdcb@oracle.com>
 <0D196885-AD5A-4759-8713-C68244A9BF97@oracle.com>
Message-ID: <5a58d78c-99f0-4435-ce6c-40dc03cd1034@oracle.com>

On 4/1/20 6:44 PM, Weijun Wang wrote:
> Two comments:
> 
> 1. Signature::getParameters explicitly specifies that the return value should match that set in setParameter(). Therefore although the types of params are different we need to make sure the contents are essentially the same. This means the getParameters() result should be designed after EdDSAParameterSpec.

If that is the case, then at the least both 
AlgorithmParameter.getEncoded methods will not be supported or return an 
empty array because there is no official encoding.

> 
> 2. If the Signature is of "EDDSA" type (i.e. not ed25519 or ed448), then before calling initSign() one does not know what named curve will be used. This means the result will not include curve info.
If I remember correctly that's the way all the other EC curves work, so 
this is nothing new.
In any case for Signature EDDSA is defaulting to 25519. I saw the 
default today and I'm not sure I like it, I would rather the user 
specify ED25519 and ED448.  The generic way EDDSA is used sometimes in 
this code I feel makes it more confusing.

> 
> --Max
> 
>> On Apr 2, 2020, at 9:21 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>
>>
>> I understand what the spec says, but here is why I believe the code returns UOE.
>>
>> EdDSASignature.setParameters only takes EdDSAParameterSpec and does not take NamedParameterSpec, which can define the curve.  The curve is defined during getInstance().  While there is an ASN.1 for the curve there is none defined for the values contained in EdDSAParameterSpec, prehash and context.  https://tools.ietf.org/html/rfc8410#page-3
>>
>> I think it is confusing for EdDSASignature.getParameters() to give a AlgorithmParameters class that provides NamedParameterSpec which cannot be used with EdDSASignature.setParameters().
>>
>> Below is what I could do to satisfy the API. I'm just not sure it has any more value than that:
>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.04/raw_files/new/src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAAlgorithmParameters.java
>>
>> Tony
>>
>> On 4/1/20 12:22 AM, Weijun Wang wrote:
>>> While SignatureSpi says engineGetParameters() would throw an UOE when it's not overridden, it is not specified in Signature::getParameters:
>>>       * <p> If this signature has been previously initialized with parameters
>>>       * (by calling the {@code setParameter} method), this method returns
>>>       * the same parameters. If this signature has not been initialized with
>>>       * parameters, this method may return a combination of default and
>>>       * randomly generated parameter values if the underlying
>>>       * signature implementation supports it and can successfully generate
>>>       * them. Otherwise, {@code null} is returned.
>>> I'm afraid we'll have to return something here, maybe a mixture of a curve name and fields inside EdDSAParameterSpec.
>>> --Max
>>>> On Mar 31, 2020, at 12:25 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>
>>>> On 3/30/20 8:52 PM, Anthony Scarpino wrote:
>>>>> On 3/30/20 7:54 PM, Weijun Wang wrote:
>>>>>>
>>>>>>
>>>>>>> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>>>>
>>>>>>> On 3/30/20 11:52 AM, Anthony Scarpino wrote:
>>>>>>>> On 3/30/20 6:21 AM, Weijun Wang wrote:
>>>>>>>>> I was playing with keytool with your patch and noticed
>>>>>>>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an
>>>>>>>>> EdECKey. While we use curve name instead of key size in EC to
>>>>>>>>> describe the parameters, the size is still useful in determining the
>>>>>>>>> strength.
>>>>>>>> I think I should be able to access the parameter with the key's NamedParameterSpec to return the size.
>>>>>>>
>>>>>>> I was wrong about this.  The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class.
>>>>>>>
>>>>>>> The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc.
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>>>
>>>>>>> Tony
>>>>>>>
>>>>>>>>>
>>>>>>>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm
>>>>>>>>> not involved with previous discussions on EdDSA design, but why does
>>>>>>>>> EdDSASignature.engineGetParameters() throw an UOE?
>>>>>>>> Because the public API for engineGetParameter(String param) is deprecated would be my suspicion.
>>>>>>
>>>>>> engineGetParameter() is deprecated, engineGetParameters() is not.
>>>>> Oh sorry.  I'm not sure why, but I have to ask the question what is the point of this method?  If the user needs to set the parameters to do the a signature of verify, what is the need for a method that gets the parameter from Signature that should have just set?  Are the parameters returned changed from the initial setting?  In the EdDSA case they are not.
>>>>> I don't have an immediate problem in having EdDSA return the same parameters back, I'm just not sure why it's necessary and I haven't see anything in the JEP as to why Adam decided against this.
>>>>> Tony
>>>>
>>>> Ok.. That's frustrating that engineSetParameters takes AlgorithmParameterSpec, but engineGetParameters returns AlgorithmParameter.  That confused me.
>>>>
>>>> So I would say the reason EdDSASignature.engineGetParameters() is UOE is because the parameters are not exposed publicly.  The NamedParameterSpec tells the internals of EdDSA what parameters to use.  I know this to be a choice by Adam as he found it unnecessary to expose APIs that were unnecessary at this time with predefined EdDSA curves and with a implementation that did not allow arbitrary curves.
>>>>
>>>> Tony
>>>>
>>>>>>
>>>>>>>>> Another small problem:
>>>>>>>>>
>>>>>>>>> You reverted the copyright year from 2020 to an earlier year in
>>>>>>>>> module-info.java, keytool/Main.java.
>>>>>>>> The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset.
>>>>>>
>>>>>> Ah yes, I applied your patch to my old repo.
>>>>>>
>>>>>> --Max
>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks, Max
>>>>>>>>>
>>>>>>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino
>>>>>>>>>> <anthony.scarpino at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>>>>>>>> Hi I need a code review for the EdDSA support in JEP 339.  The
>>>>>>>>>>> code builds on the existing java implemented constant time
>>>>>>>>>>> classes used for XDH and the NIST curves.  The change also adds
>>>>>>>>>>> classes to the public API to support EdDSA operations. All
>>>>>>>>>>> information about the JEP is located at: JEP 339:
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR:
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev:
>>>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I updated the webrev with some minor updates that were commented
>>>>>>>>>> previously.
>>>>>>>>>>
>>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>>>>>>>>
>>>>>>>>>> Tony
>>
> 



From weijun.wang at oracle.com  Thu Apr  2 04:31:07 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 2 Apr 2020 12:31:07 +0800
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <5a58d78c-99f0-4435-ce6c-40dc03cd1034@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <E2A838B8-0CC1-4561-ACA4-F5676031DFDD@oracle.com>
 <931a3d7c-cbca-4961-3474-0e2872a34026@oracle.com>
 <5a6648f4-f4c0-040e-ceb8-1fb6cbab4e77@oracle.com>
 <335ADFF1-D22E-4074-A94E-A2EEA5944D5F@oracle.com>
 <3e6359a0-b165-942f-4371-cc67cdd1af89@oracle.com>
 <7aca5038-026f-3319-7046-e617895b6ab1@oracle.com>
 <FE737B38-A84E-4EEA-8CBC-6D3849FE04D6@oracle.com>
 <e9713843-91ad-cee6-9e5d-ccc4b934fdcb@oracle.com>
 <0D196885-AD5A-4759-8713-C68244A9BF97@oracle.com>
 <5a58d78c-99f0-4435-ce6c-40dc03cd1034@oracle.com>
Message-ID: <E8C2EB3B-C752-4C49-BC7A-8BE8805D0F84@oracle.com>

I just read https://tools.ietf.org/html/rfc8410 and it intentionally did not encode prehash and context anywhere. If AlgorithmParameters' main purpose is to decode/encode this, then looks like it's useless here.

The EDDSA case is quite unusual because normally anything set by setParameter on the signing side should be available as byte array thru getParameters().getEncoded() so that it can encoded inside the signature and readable by the verifying side. But here, according to RFC 8410, prehash should be used; according to RFC 8032, context "SHOULD be a constant string specified by the protocol using it" and therefore should be negotiated/determined elsewhere.

Anyway, so far we have found 3 ways to deal with this:

1. EdDSASignature::engineGetParameters throws UOE.
2. EdDSASignature::engineGetParameters returns null.
3. EdDSASignature::engineGetParameters returns something but it.getEncoded() returns null

Neither is perfect.

1. No one might expect an UOE.
2. Conflict with spec, when setParameter() was called.
3. No AlgorithmParametersSpi::engineGetEncoded has ever returned a null.

My current preference is 2), seems like the least chance to break existing programs (at least RSASignature has returned null before). This means a spec change in Signature::getParameters is need to clarify this. We might also need to add a paragraph into the spec of EdDSAParameterSpec saying it does not have a counterpart AlgorithmParameters type because of RFC 8410. We can define an AlgorithmParameters later if a future RFC defined anything.

Thanks,
Max

> On Apr 2, 2020, at 10:45 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> On 4/1/20 6:44 PM, Weijun Wang wrote:
>> Two comments:
>> 1. Signature::getParameters explicitly specifies that the return value should match that set in setParameter(). Therefore although the types of params are different we need to make sure the contents are essentially the same. This means the getParameters() result should be designed after EdDSAParameterSpec.
> 
> If that is the case, then at the least both AlgorithmParameter.getEncoded methods will not be supported or return an empty array because there is no official encoding.
> 
>> 2. If the Signature is of "EDDSA" type (i.e. not ed25519 or ed448), then before calling initSign() one does not know what named curve will be used. This means the result will not include curve info.
> If I remember correctly that's the way all the other EC curves work, so this is nothing new.
> In any case for Signature EDDSA is defaulting to 25519. I saw the default today and I'm not sure I like it, I would rather the user specify ED25519 and ED448.  The generic way EDDSA is used sometimes in this code I feel makes it more confusing.
> 
>> --Max
>>> On Apr 2, 2020, at 9:21 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>> 
>>> 
>>> I understand what the spec says, but here is why I believe the code returns UOE.
>>> 
>>> EdDSASignature.setParameters only takes EdDSAParameterSpec and does not take NamedParameterSpec, which can define the curve.  The curve is defined during getInstance().  While there is an ASN.1 for the curve there is none defined for the values contained in EdDSAParameterSpec, prehash and context.  https://tools.ietf.org/html/rfc8410#page-3
>>> 
>>> I think it is confusing for EdDSASignature.getParameters() to give a AlgorithmParameters class that provides NamedParameterSpec which cannot be used with EdDSASignature.setParameters().
>>> 
>>> Below is what I could do to satisfy the API. I'm just not sure it has any more value than that:
>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.04/raw_files/new/src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAAlgorithmParameters.java
>>> 
>>> Tony
>>> 
>>> On 4/1/20 12:22 AM, Weijun Wang wrote:
>>>> While SignatureSpi says engineGetParameters() would throw an UOE when it's not overridden, it is not specified in Signature::getParameters:
>>>>      * <p> If this signature has been previously initialized with parameters
>>>>      * (by calling the {@code setParameter} method), this method returns
>>>>      * the same parameters. If this signature has not been initialized with
>>>>      * parameters, this method may return a combination of default and
>>>>      * randomly generated parameter values if the underlying
>>>>      * signature implementation supports it and can successfully generate
>>>>      * them. Otherwise, {@code null} is returned.
>>>> I'm afraid we'll have to return something here, maybe a mixture of a curve name and fields inside EdDSAParameterSpec.
>>>> --Max
>>>>> On Mar 31, 2020, at 12:25 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>> 
>>>>> On 3/30/20 8:52 PM, Anthony Scarpino wrote:
>>>>>> On 3/30/20 7:54 PM, Weijun Wang wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> On 3/30/20 11:52 AM, Anthony Scarpino wrote:
>>>>>>>>> On 3/30/20 6:21 AM, Weijun Wang wrote:
>>>>>>>>>> I was playing with keytool with your patch and noticed
>>>>>>>>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an
>>>>>>>>>> EdECKey. While we use curve name instead of key size in EC to
>>>>>>>>>> describe the parameters, the size is still useful in determining the
>>>>>>>>>> strength.
>>>>>>>>> I think I should be able to access the parameter with the key's NamedParameterSpec to return the size.
>>>>>>>> 
>>>>>>>> I was wrong about this.  The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class.
>>>>>>>> 
>>>>>>>> The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc.
>>>>>>> 
>>>>>>> Yes.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Tony
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm
>>>>>>>>>> not involved with previous discussions on EdDSA design, but why does
>>>>>>>>>> EdDSASignature.engineGetParameters() throw an UOE?
>>>>>>>>> Because the public API for engineGetParameter(String param) is deprecated would be my suspicion.
>>>>>>> 
>>>>>>> engineGetParameter() is deprecated, engineGetParameters() is not.
>>>>>> Oh sorry.  I'm not sure why, but I have to ask the question what is the point of this method?  If the user needs to set the parameters to do the a signature of verify, what is the need for a method that gets the parameter from Signature that should have just set?  Are the parameters returned changed from the initial setting?  In the EdDSA case they are not.
>>>>>> I don't have an immediate problem in having EdDSA return the same parameters back, I'm just not sure why it's necessary and I haven't see anything in the JEP as to why Adam decided against this.
>>>>>> Tony
>>>>> 
>>>>> Ok.. That's frustrating that engineSetParameters takes AlgorithmParameterSpec, but engineGetParameters returns AlgorithmParameter.  That confused me.
>>>>> 
>>>>> So I would say the reason EdDSASignature.engineGetParameters() is UOE is because the parameters are not exposed publicly.  The NamedParameterSpec tells the internals of EdDSA what parameters to use.  I know this to be a choice by Adam as he found it unnecessary to expose APIs that were unnecessary at this time with predefined EdDSA curves and with a implementation that did not allow arbitrary curves.
>>>>> 
>>>>> Tony
>>>>> 
>>>>>>> 
>>>>>>>>>> Another small problem:
>>>>>>>>>> 
>>>>>>>>>> You reverted the copyright year from 2020 to an earlier year in
>>>>>>>>>> module-info.java, keytool/Main.java.
>>>>>>>>> The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset.
>>>>>>> 
>>>>>>> Ah yes, I applied your patch to my old repo.
>>>>>>> 
>>>>>>> --Max
>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Thanks, Max
>>>>>>>>>> 
>>>>>>>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino
>>>>>>>>>>> <anthony.scarpino at oracle.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>>>>>>>>> Hi I need a code review for the EdDSA support in JEP 339.  The
>>>>>>>>>>>> code builds on the existing java implemented constant time
>>>>>>>>>>>> classes used for XDH and the NIST curves.  The change also adds
>>>>>>>>>>>> classes to the public API to support EdDSA operations. All
>>>>>>>>>>>> information about the JEP is located at: JEP 339:
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR:
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev:
>>>>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I updated the webrev with some minor updates that were commented
>>>>>>>>>>> previously.
>>>>>>>>>>> 
>>>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>>>>>>>>> 
>>>>>>>>>>> Tony
>>> 
> 



From anthony.scarpino at oracle.com  Thu Apr  2 05:33:52 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 1 Apr 2020 22:33:52 -0700
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <E8C2EB3B-C752-4C49-BC7A-8BE8805D0F84@oracle.com>
References: <E8C2EB3B-C752-4C49-BC7A-8BE8805D0F84@oracle.com>
Message-ID: <55EFDFFA-9F07-450F-9C1E-9C5007D5C21D@oracle.com>

I can agree with #2. We won?t be setting a precedent by returning null.  Either 1 or 2 allow us to better support a future RFC with an encoding.  #3, probably creates more potential problems than we need.

I believe a majority of EdDSA usage doesn?t use the parameters. As far as I know browsers and ssh don?t support them, so I don?t think we are significantly harming anyone by doing this. 

Tony 

> On Apr 1, 2020, at 9:31 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> ?I just read https://tools.ietf.org/html/rfc8410 and it intentionally did not encode prehash and context anywhere. If AlgorithmParameters' main purpose is to decode/encode this, then looks like it's useless here.
> 
> The EDDSA case is quite unusual because normally anything set by setParameter on the signing side should be available as byte array thru getParameters().getEncoded() so that it can encoded inside the signature and readable by the verifying side. But here, according to RFC 8410, prehash should be used; according to RFC 8032, context "SHOULD be a constant string specified by the protocol using it" and therefore should be negotiated/determined elsewhere.
> 
> Anyway, so far we have found 3 ways to deal with this:
> 
> 1. EdDSASignature::engineGetParameters throws UOE.
> 2. EdDSASignature::engineGetParameters returns null.
> 3. EdDSASignature::engineGetParameters returns something but it.getEncoded() returns null
> 
> Neither is perfect.
> 
> 1. No one might expect an UOE.
> 2. Conflict with spec, when setParameter() was called.
> 3. No AlgorithmParametersSpi::engineGetEncoded has ever returned a null.
> 
> My current preference is 2), seems like the least chance to break existing programs (at least RSASignature has returned null before). This means a spec change in Signature::getParameters is need to clarify this. We might also need to add a paragraph into the spec of EdDSAParameterSpec saying it does not have a counterpart AlgorithmParameters type because of RFC 8410. We can define an AlgorithmParameters later if a future RFC defined anything.
> 
> Thanks,
> Max
> 
>> On Apr 2, 2020, at 10:45 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>> 
>>> On 4/1/20 6:44 PM, Weijun Wang wrote:
>>> Two comments:
>>> 1. Signature::getParameters explicitly specifies that the return value should match that set in setParameter(). Therefore although the types of params are different we need to make sure the contents are essentially the same. This means the getParameters() result should be designed after EdDSAParameterSpec.
>> 
>> If that is the case, then at the least both AlgorithmParameter.getEncoded methods will not be supported or return an empty array because there is no official encoding.
>> 
>>> 2. If the Signature is of "EDDSA" type (i.e. not ed25519 or ed448), then before calling initSign() one does not know what named curve will be used. This means the result will not include curve info.
>> If I remember correctly that's the way all the other EC curves work, so this is nothing new.
>> In any case for Signature EDDSA is defaulting to 25519. I saw the default today and I'm not sure I like it, I would rather the user specify ED25519 and ED448.  The generic way EDDSA is used sometimes in this code I feel makes it more confusing.
>> 
>>> --Max
>>>> On Apr 2, 2020, at 9:21 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>> 
>>>> 
>>>> I understand what the spec says, but here is why I believe the code returns UOE.
>>>> 
>>>> EdDSASignature.setParameters only takes EdDSAParameterSpec and does not take NamedParameterSpec, which can define the curve.  The curve is defined during getInstance().  While there is an ASN.1 for the curve there is none defined for the values contained in EdDSAParameterSpec, prehash and context.  https://tools.ietf.org/html/rfc8410#page-3
>>>> 
>>>> I think it is confusing for EdDSASignature.getParameters() to give a AlgorithmParameters class that provides NamedParameterSpec which cannot be used with EdDSASignature.setParameters().
>>>> 
>>>> Below is what I could do to satisfy the API. I'm just not sure it has any more value than that:
>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.04/raw_files/new/src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAAlgorithmParameters.java
>>>> 
>>>> Tony
>>>> 
>>>> On 4/1/20 12:22 AM, Weijun Wang wrote:
>>>>> While SignatureSpi says engineGetParameters() would throw an UOE when it's not overridden, it is not specified in Signature::getParameters:
>>>>>     * <p> If this signature has been previously initialized with parameters
>>>>>     * (by calling the {@code setParameter} method), this method returns
>>>>>     * the same parameters. If this signature has not been initialized with
>>>>>     * parameters, this method may return a combination of default and
>>>>>     * randomly generated parameter values if the underlying
>>>>>     * signature implementation supports it and can successfully generate
>>>>>     * them. Otherwise, {@code null} is returned.
>>>>> I'm afraid we'll have to return something here, maybe a mixture of a curve name and fields inside EdDSAParameterSpec.
>>>>> --Max
>>>>>> On Mar 31, 2020, at 12:25 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>>> 
>>>>>> On 3/30/20 8:52 PM, Anthony Scarpino wrote:
>>>>>>> On 3/30/20 7:54 PM, Weijun Wang wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Mar 31, 2020, at 10:50 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>>>>>> 
>>>>>>>>> On 3/30/20 11:52 AM, Anthony Scarpino wrote:
>>>>>>>>>> On 3/30/20 6:21 AM, Weijun Wang wrote:
>>>>>>>>>>> I was playing with keytool with your patch and noticed
>>>>>>>>>>> sun.security.util.KeyUtil.getKeySize(Key) does not support an
>>>>>>>>>>> EdECKey. While we use curve name instead of key size in EC to
>>>>>>>>>>> describe the parameters, the size is still useful in determining the
>>>>>>>>>>> strength.
>>>>>>>>>> I think I should be able to access the parameter with the key's NamedParameterSpec to return the size.
>>>>>>>>> 
>>>>>>>>> I was wrong about this.  The parameters are part of jdk.crypto.ec while KeyUtil is part of java.base, so I cannot access the internal EdDSAParameters class.
>>>>>>>>> 
>>>>>>>>> The easiest way would be to look at the NamedParameterSpec and return a hardcoded length based on the curve used. It's not ideal, but all these curves don't change lengths unlike for RSA, AES, etc.
>>>>>>>> 
>>>>>>>> Yes.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Tony
>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> There is also a KeyUtil.getKeySize(AlgorithmParameters) nearby. I'm
>>>>>>>>>>> not involved with previous discussions on EdDSA design, but why does
>>>>>>>>>>> EdDSASignature.engineGetParameters() throw an UOE?
>>>>>>>>>> Because the public API for engineGetParameter(String param) is deprecated would be my suspicion.
>>>>>>>> 
>>>>>>>> engineGetParameter() is deprecated, engineGetParameters() is not.
>>>>>>> Oh sorry.  I'm not sure why, but I have to ask the question what is the point of this method?  If the user needs to set the parameters to do the a signature of verify, what is the need for a method that gets the parameter from Signature that should have just set?  Are the parameters returned changed from the initial setting?  In the EdDSA case they are not.
>>>>>>> I don't have an immediate problem in having EdDSA return the same parameters back, I'm just not sure why it's necessary and I haven't see anything in the JEP as to why Adam decided against this.
>>>>>>> Tony
>>>>>> 
>>>>>> Ok.. That's frustrating that engineSetParameters takes AlgorithmParameterSpec, but engineGetParameters returns AlgorithmParameter.  That confused me.
>>>>>> 
>>>>>> So I would say the reason EdDSASignature.engineGetParameters() is UOE is because the parameters are not exposed publicly.  The NamedParameterSpec tells the internals of EdDSA what parameters to use.  I know this to be a choice by Adam as he found it unnecessary to expose APIs that were unnecessary at this time with predefined EdDSA curves and with a implementation that did not allow arbitrary curves.
>>>>>> 
>>>>>> Tony
>>>>>> 
>>>>>>>> 
>>>>>>>>>>> Another small problem:
>>>>>>>>>>> 
>>>>>>>>>>> You reverted the copyright year from 2020 to an earlier year in
>>>>>>>>>>> module-info.java, keytool/Main.java.
>>>>>>>>>> The copyright has not been reverted, the jdk repo was updated to 2020 from another changeset.
>>>>>>>> 
>>>>>>>> Ah yes, I applied your patch to my old repo.
>>>>>>>> 
>>>>>>>> --Max
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thanks, Max
>>>>>>>>>>> 
>>>>>>>>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino
>>>>>>>>>>>> <anthony.scarpino at oracle.com> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>>>>>>>>>> Hi I need a code review for the EdDSA support in JEP 339.  The
>>>>>>>>>>>>> code builds on the existing java implemented constant time
>>>>>>>>>>>>> classes used for XDH and the NIST curves.  The change also adds
>>>>>>>>>>>>> classes to the public API to support EdDSA operations. All
>>>>>>>>>>>>> information about the JEP is located at: JEP 339:
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8199231 CSR:
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8190219 webrev:
>>>>>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ thanks Tony
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> I updated the webrev with some minor updates that were commented
>>>>>>>>>>>> previously.
>>>>>>>>>>>> 
>>>>>>>>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>>>>>>>>>> 
>>>>>>>>>>>> Tony
>>>> 
>> 
> 



From prasadarao.koppula at oracle.com  Thu Apr  2 05:36:08 2020
From: prasadarao.koppula at oracle.com (Prasadrao Koppula)
Date: Wed, 1 Apr 2020 22:36:08 -0700 (PDT)
Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role
In-Reply-To: <1788edc0-97f3-48cf-8b04-fd6520e1df16@default>
References: <939a2142-60b6-49e8-873f-3f3888293342@default>
 <1788edc0-97f3-48cf-8b04-fd6520e1df16@default>
Message-ID: <03fa3cf6-6862-4fb4-aa19-6708d57e8c27@default>

Gentle ping?

 

Thanks,

Prasad.K

 

From: Prasadrao Koppula 
Sent: Monday, March 30, 2020 7:21 PM
To: security-dev at openjdk.java.net
Subject: RE: RFR[jdk] 8237474: Default SSLEngine should create in server role

 

Hi,

 

Added @implnote and updated test changes, here is the new webrev, please review it.  

 

Webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.01/

issue: https://bugs.openjdk.java.net/browse/JDK-8237474

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

 

 

Thanks,

Prasad.K

 

From: Prasadrao Koppula 
Sent: Friday, February 7, 2020 5:03 PM
To: HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net
Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role

 

Hi,

 

Could you please review this patch. Default server role mode was flipped in SSLEngine, to client role mode as part of SSL package code refactoring for TLSv1.3, this patch flips back default client role to server role in SSLEngine.

 

webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/

issue: https://bugs.openjdk.java.net/browse/JDK-8237474

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

 

 

Thanks,

Prasad.K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200401/dd81bdaa/attachment.htm>

From ivan.gerasimov at oracle.com  Thu Apr  2 06:38:40 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 1 Apr 2020 23:38:40 -0700
Subject: [15] RFR 8241761 : Typos: empty lines in javadoc, inconsistent
 indents, etc. (security-libs only)
In-Reply-To: <5027FFFF-6E24-4C3C-AAB9-B5E9EDD9C7A8@oracle.com>
References: <590603c4-d9b9-ac16-b0a7-c3be927efbe7@oracle.com>
 <5027FFFF-6E24-4C3C-AAB9-B5E9EDD9C7A8@oracle.com>
Message-ID: <3f5f1ca9-7ad2-b152-be02-be7f0b024523@oracle.com>

Thank you Max!

I've made the suggested adjustment and pushed the fix.

With kind regards,

Ivan

On 4/1/20 2:59 AM, Weijun Wang wrote:
> Looks fine to me.
>
> If I have to pick one tiny problem, you can remove a blank in line 58 below to make the indentation more precise:
>
> src/java.security.sasl/share/classes/javax/security/sasl/SaslServer.java:
>
>    57  *             status = ldap.sendBindResponse(mechanism, challenge,
>    58  *                  SASL_BIND_IN_PROGRESS);
>
> Thanks,
> Max
>
>
>> On Mar 31, 2020, at 5:39 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> Hello!
>>
>> The fix follows up on JDK-8241727 [1].
>>
>> This is a javadoc/comments only fix in the security-libs area.
>>
>> The changes are to remove redundant empty lines, correct indentation, or otherwise restore harmony.
>>
>> Would you please help review this rather technical fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8241761
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8241761/00/webrev/
>>
>> Thank in advance!
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8241727
>>
>> -- 
>> With kind regards,
>> Ivan Gerasimov
>>
-- 
With kind regards,
Ivan Gerasimov



From weijun.wang at oracle.com  Thu Apr  2 07:43:28 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 2 Apr 2020 15:43:28 +0800
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <55EFDFFA-9F07-450F-9C1E-9C5007D5C21D@oracle.com>
References: <E8C2EB3B-C752-4C49-BC7A-8BE8805D0F84@oracle.com>
 <55EFDFFA-9F07-450F-9C1E-9C5007D5C21D@oracle.com>
Message-ID: <22D9C944-AEA8-41A6-814D-48FD3823B8B2@oracle.com>

One more thing:

https://tools.ietf.org/html/rfc8410#section-1

   In [RFC8032] the elliptic curve signature system Edwards-curve
   Digital Signature Algorithm (EdDSA) is described along with a
   recommendation for the use of the curve25519 and curve448.  EdDSA has
   defined two modes: the PureEdDSA mode without prehashing and the
   HashEdDSA mode with prehashing.  The convention used for identifying
   the algorithm/curve combinations is to use "Ed25519" and "Ed448" for
   the PureEdDSA mode.

Does this mean we should reject prehash=true for "Ed25519" and "Ed448"?

Thanks,
Max



From norman.maurer at googlemail.com  Thu Apr  2 13:57:26 2020
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Thu, 2 Apr 2020 15:57:26 +0200
Subject: Possible regression in JDK 14 related to SSLSessionContext /
 SSLSession on the server side
In-Reply-To: <5cc5e4d7-74a3-5252-574a-a761017bd294@oracle.com>
References: <982CE16C-06E9-456A-A637-DDB7848CE546@googlemail.com>
 <c1535554-dbda-01a2-8e12-2fde5b65df3c@oracle.com>
 <41271A68-2A81-4E87-ACE3-6409C7D7DCEE@googlemail.com>
 <e20df59f-9946-6015-22dc-284658c8a09b@oracle.com>
 <DF08DC63-3056-4982-ADC1-029C9A5417E2@googlemail.com>
 <ec76eec5-a358-f422-5b5d-fc4d1c22ccd6@oracle.com>
 <8B48D9A2-D71C-44B3-B9B4-25F1436D1FE6@googlemail.com>
 <5cc5e4d7-74a3-5252-574a-a761017bd294@oracle.com>
Message-ID: <01CAB1E0-81E7-468A-8228-D6CB9A303698@googlemail.com>

Thanks a lot? 

Happy to be able to help here.

Once you have a fix ready let me know and I can verify it with the netty testsuite.

Bye
Norman


> On 1. Apr 2020, at 23:37, Jamil Nimeh <jamil.j.nimeh at Oracle.Com> wrote:
> 
> Hi Norman, session context issue is here:
> 
> https://bugs.openjdk.java.net/browse/JDK-8242008 <https://bugs.openjdk.java.net/browse/JDK-8242008>
> --Jamil
> 
> On 4/1/2020 12:32 AM, Norman Maurer wrote:
>> Please add a link to the bug once it is created.
>> 
>> Bye
>> Norman
>> 
>> 
>>> On 31. Mar 2020, at 17:35, Jamil Nimeh <jamil.j.nimeh at Oracle.Com <mailto:jamil.j.nimeh at Oracle.Com>> wrote:
>>> 
>>> Thanks Norman, I'm going to file a bug on this one.  After playing with it a bit more I found cases where even SSLServerSockets do run into the issue but it doesn't always happen.  Still working on characterizing it.
>>> 
>>> --Jamil
>>> 
>>> On 3/31/2020 7:11 AM, Norman Maurer wrote:
>>>> Yes thats about right? if setting to false it works as expected.
>>>> 
>>>> 
>>>> Bye
>>>> Norman
>>>> 
>>>> 
>>>>> On 31. Mar 2020, at 01:50, Jamil Nimeh <jamil.j.nimeh at Oracle.Com <mailto:jamil.j.nimeh at Oracle.Com>> wrote:
>>>>> 
>>>>> Hi Norman,
>>>>> 
>>>>> I've been able to run your test code and I can reproduce it.  Interestingly enough, it appears to happen when -Djdk.tls.server.enableSessionTicketExtension=true, which is the default position.  With session tickets enabled, I would see the issue in TLS 1.3 and 1.2 connections just as you did.  Setting the above property to false however allowed me to make successful connections.  Would you mind setting that property to false, just to make sure you and I see the same thing?
>>>>> 
>>>>> I did go back and run SSLServerSocket-based connections just to see if the session ticket settings had any impact on things, but they don't.  I can make connections to a socket based SSL server regardless of the property value on the server side.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> --Jamil
>>>>> 
>>>>> On 3/30/2020 5:31 AM, Norman Maurer wrote:
>>>>>> Hey Sean,
>>>>>> 
>>>>>> There is not much to share as its just a simple handshake :)
>>>>>> 
>>>>>> Anyway here is a reproducer:
>>>>>> 
>>>>>> https://github.com/normanmaurer/jdk_ssl_session_context_reproducer <https://github.com/normanmaurer/jdk_ssl_session_context_reproducer>
>>>>>> 
>>>>>> It basically does nothing more then complete the handshake and then calling engine.getSession().getSessionContext() which will return null on the server side since JDK 14 (earlier versions work).
>>>>>> I tested it with TLSv1.2 and TLSv1.3 and both times it produced the error on JDK 14.
>>>>>> 
>>>>>> 
>>>>>> Bye
>>>>>> Norman
>>>>>> 
>>>>>> 
>>>>>>> On 30. Mar 2020, at 13:22, Se?n Coffey <sean.coffey at oracle.com <mailto:sean.coffey at oracle.com>> wrote:
>>>>>>> 
>>>>>>> Looks interesting Norman. Do you want to share some more details about the peculiarities of this handshake before considering a fully fledged testcase ?
>>>>>>> 
>>>>>>> regards,
>>>>>>> Sean.
>>>>>>> 
>>>>>>> On 27/03/2020 12:48, Norman Maurer wrote:
>>>>>>>> Hi there,
>>>>>>>> 
>>>>>>>> I am just about to add JDK14 to the test matrix for netty and think I found a regression. Before I will invest time to write a standalone reproducer please let me know if you think this is a regression or not.
>>>>>>>> Basically after the handshake is complete SSLEngine.getSession().getSessionContext() returns null on the serverside when using JDK14. Running the same test with any previous version (JDK13 and earlier) doesn?t show the same result.
>>>>>>>> 
>>>>>>>> Does this sounds like a regression and if so should I provide a standalone reproducer here ?
>>>>>>>> 
>>>>>>>> Bye
>>>>>>>> Norman
>>>>>>>> 
>>>>>> 
>>>> 
>> 

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

From xuelei.fan at oracle.com  Thu Apr  2 15:42:06 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 2 Apr 2020 08:42:06 -0700
Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role
In-Reply-To: <1788edc0-97f3-48cf-8b04-fd6520e1df16@default>
References: <939a2142-60b6-49e8-873f-3f3888293342@default>
 <1788edc0-97f3-48cf-8b04-fd6520e1df16@default>
Message-ID: <adac0396-d49f-f11e-d7b6-53dc7151a07f@oracle.com>

Please update copyright year to 2020.

SSLEngine.java
--------------
@@ -1109,10 +1115,14 @@
+     * @implNote
+     * The JDK SunJSSE provider implementation returns false unless 
{@link setUseClientMode}
+     *          is used to change the mode to true.

For the link, I may add parameter, and limit the line under 80 
characters, and don't indent the lines.

+     * @implNote
-     * The JDK SunJSSE provider implementation returns false unless 
{@link setUseClientMode}
-     *          is used to change the mode to true.
+     * The JDK SunJSSE provider implementation returns false unless
+     * {@link setUseClientMode(boolean)} is used to change the mode
+      * to true.

It's fine to leave the CSR  as it is.

Otherwise, looks fine to me.

Xuelei

On 3/30/2020 6:50 AM, Prasadrao Koppula wrote:
> Hi,
> 
> Added @implnote and updated test changes, here is the new webrev, please 
> review it.
> 
> Webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.01/
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8237474
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
> 
> Thanks,
> 
> Prasad.K
> 
> *From:* Prasadrao Koppula
> *Sent:* Friday, February 7, 2020 5:03 PM
> *To:* security-dev at openjdk.java.net
> *Subject:* RFR[jdk] 8237474: Default SSLEngine should create in server role
> 
> Hi,
> 
> Could you please review this patch. Default server role mode was flipped 
> in SSLEngine, to client role mode as part of SSL package code 
> refactoring for TLSv1.3, this patch flips back default client role to 
> server role in SSLEngine.
> 
> webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8237474
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
> 
> Thanks,
> 
> Prasad.K
> 


From prasadarao.koppula at oracle.com  Thu Apr  2 15:56:27 2020
From: prasadarao.koppula at oracle.com (Prasadrao Koppula)
Date: Thu, 2 Apr 2020 08:56:27 -0700 (PDT)
Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role
In-Reply-To: <adac0396-d49f-f11e-d7b6-53dc7151a07f@oracle.com>
References: <939a2142-60b6-49e8-873f-3f3888293342@default>
 <1788edc0-97f3-48cf-8b04-fd6520e1df16@default>
 <adac0396-d49f-f11e-d7b6-53dc7151a07f@oracle.com>
Message-ID: <df3728ad-0ea4-4bc5-b05c-7fec1e5914e4@default>

Thanks for review Xuelei, I will incorporate your suggestions. 

Thanks,
Prasad.K

> -----Original Message-----
> From: Xuelei Fan
> Sent: Thursday, April 2, 2020 9:12 PM
> To: security-dev at openjdk.java.net
> Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role
> 
> Please update copyright year to 2020.
> 
> SSLEngine.java
> --------------
> @@ -1109,10 +1115,14 @@
> +     * @implNote
> +     * The JDK SunJSSE provider implementation returns false unless
> {@link setUseClientMode}
> +     *          is used to change the mode to true.
> 
> For the link, I may add parameter, and limit the line under 80 characters, and
> don't indent the lines.
> 
> +     * @implNote
> -     * The JDK SunJSSE provider implementation returns false unless
> {@link setUseClientMode}
> -     *          is used to change the mode to true.
> +     * The JDK SunJSSE provider implementation returns false unless
> +     * {@link setUseClientMode(boolean)} is used to change the mode
> +      * to true.
> 
> It's fine to leave the CSR  as it is.
> 
> Otherwise, looks fine to me.
> 
> Xuelei
> 
> On 3/30/2020 6:50 AM, Prasadrao Koppula wrote:
> > Hi,
> >
> > Added @implnote and updated test changes, here is the new webrev,
> > please review it.
> >
> > Webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.01/
> >
> > issue: https://bugs.openjdk.java.net/browse/JDK-8237474
> >
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
> >
> > Thanks,
> >
> > Prasad.K
> >
> > *From:* Prasadrao Koppula
> > *Sent:* Friday, February 7, 2020 5:03 PM
> > *To:* security-dev at openjdk.java.net
> > *Subject:* RFR[jdk] 8237474: Default SSLEngine should create in server
> > role
> >
> > Hi,
> >
> > Could you please review this patch. Default server role mode was
> > flipped in SSLEngine, to client role mode as part of SSL package code
> > refactoring for TLSv1.3, this patch flips back default client role to
> > server role in SSLEngine.
> >
> > webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/
> >
> > issue: https://bugs.openjdk.java.net/browse/JDK-8237474
> >
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
> >
> > Thanks,
> >
> > Prasad.K
> >


From sean.mullan at oracle.com  Thu Apr  2 20:02:33 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 2 Apr 2020 16:02:33 -0400
Subject: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property
 with a security one
In-Reply-To: <2730a678-652a-af29-285d-ce25220e4089@redhat.com>
References: <74433961-0fb3-c388-9906-fc3bcf5a9a23@redhat.com>
 <63bb7e08-0883-b610-0fc7-9ed9bc3a1a99@oracle.com>
 <2730a678-652a-af29-285d-ce25220e4089@redhat.com>
Message-ID: <7ba2a5ff-f675-55ce-63a4-9004df332fba@oracle.com>

On 4/1/20 5:53 PM, Martin Balao wrote:
> Fixed.
> 
> Webrev.01:
> 
>   *http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.01/

In the java.security file might add the sentence "The default value of 
the property is "false"" just to avoid any confusion.

--Sean


From mbalao at redhat.com  Thu Apr  2 21:23:13 2020
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 2 Apr 2020 18:23:13 -0300
Subject: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property
 with a security one
In-Reply-To: <7ba2a5ff-f675-55ce-63a4-9004df332fba@oracle.com>
References: <74433961-0fb3-c388-9906-fc3bcf5a9a23@redhat.com>
 <63bb7e08-0883-b610-0fc7-9ed9bc3a1a99@oracle.com>
 <2730a678-652a-af29-285d-ce25220e4089@redhat.com>
 <7ba2a5ff-f675-55ce-63a4-9004df332fba@oracle.com>
Message-ID: <de28a7b9-5967-9241-8bea-4edcc5103deb@redhat.com>

Hi,

Webrev.02:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.02

On 4/2/20 5:02 PM, Sean Mullan wrote:
> 
> In the java.security file might add the sentence "The default value of
> the property is "false"" just to avoid any confusion.
> 

Added.

Thanks,
Martin.-



From valerie.peng at oracle.com  Thu Apr  2 23:51:41 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 2 Apr 2020 16:51:41 -0700
Subject: RFR 8241960: The SHA3 message digests are not thread safe when
 cloned
In-Reply-To: <784d0590-357d-1da0-ba01-49fed43ad6b3@oracle.com>
References: <065849EF-ED24-4C50-AA9A-209D5890B074@azul.com>
 <784d0590-357d-1da0-ba01-49fed43ad6b3@oracle.com>
Message-ID: <217d9ea6-ffbc-c9f3-0be1-f3bcc759e1d4@oracle.com>

Hi Alexey,

In general looks pretty good, just some comments on the regression test:

- line 28: The duration value 10 may be lowered to shorten the execution 
time. On a Linux machine, with threadFactor=5, each digest algo takes 
about (2xduration+2) sec and overall takes ~283sec. Cutting the duration 
value drastically to 2, I still can reproduce the bug. Maybe 4 would be 
a better default value considering the execution time.

- line 43: add "SHA-512/224", "SHA-512/256" to the ALGORITHM_ARRAY?

- line 50: instead of hardcoding 5 here, why not just use threadsFactor 
(assigned with default value 5 on line 48)?

- line 52-55: I think you meant to use 5 (instead of the value 180) as 
the default min duration on line 52. Then, use duration variable instead 
of the hardcoded? 5 on line54. For testing purpose, why not just use the 
supplied value? You already have default values if none are supplied.

- Consider iterating through existing providers and remove 
isSHA3supported() method. This way all providers which supports the 
digest algorithm are tested and no provider-specific knowledge is 
needed. For example:

 ??????? Provider[] provs = Security.getProviders();

 ??????? for (Provider p : provs) {

 ??????????? System.out.println("Testing provider " + p.getName() + "...");

 ??????????? for (String alg: ALGORITHM_ARRAY) {

 ???????????     try {

 ???????????????     MessageDigest md = MessageDigest.getInstance(alg, p);

 ???????????????     testThreadSafe(md, input, nTasks, duration, false);

 ? ? ? ? ? ? ? ? ....

- line 76: missing space char between } and catch.

Thanks,
Valerie
On 3/31/2020 1:01 PM, Valerie Peng wrote:
> Hi Alexey,
>
> Good catch, thanks for the report, I will review it.
>
> On a first look, it seems that this is more about the clone() method 
> of the SHA-3 impl missed copying/cloning an internal field.
>
> Given that this is about SUN provider, I've modified the synopsis 
> accordingly and move the priority up to P3.
>
> It may not take multi-thread to reproduce this? If so, we can simplify 
> the regression test.
>
> Regards,
> Valerie
> On 3/31/2020 11:27 AM, Alexey Bakhtin wrote:
>> Hi All,
>>
>> Please review fix for SHA3 message digests thread safety.
>> Issue reproduced on the JDK11, JDK13 and JDK14
>> JTREG test is provided in the patch
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8241960
>> Webrev: https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v0/
>>
>> Regards
>> Alexey
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200402/5f833465/attachment.htm>

From weijun.wang at oracle.com  Fri Apr  3 03:34:07 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 3 Apr 2020 11:34:07 +0800
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
Message-ID: <7F1CE671-0ED5-4B6A-A919-7CAF29B381FE@oracle.com>

Another question:

Why does getAlgorithm() of PublicKey and PrivateKey return "EdDSA" instead of "Ed25519" and "Ed448"?

Do we suggest people using "EdDSA" or "Ed25519"/"Ed448" when calling KeyFactory.getInstance() and KeyPairGenerator.getInstance()?

Thanks,
Max

> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>> Hi
>> I need a code review for the EdDSA support in JEP 339.  The code builds on the existing java implemented constant time classes used for XDH and the NIST curves.  The change also adds classes to the public API to support EdDSA operations.
>> All information about the JEP is located at:
>> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219
>> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/
>> thanks
>> Tony
> 
> 
> I updated the webrev with some minor updates that were commented previously.
> 
> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
> 
> Tony



From weijun.wang at oracle.com  Fri Apr  3 10:07:07 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 3 Apr 2020 18:07:07 +0800
Subject: RFR 8240848: ArrayIndexOutOfBoundsException buf for
 TextCallbackHandler
In-Reply-To: <DD2A90DB-B32E-4E90-89DB-A81EA8ADE1B5@oracle.com>
References: <DD2A90DB-B32E-4E90-89DB-A81EA8ADE1B5@oracle.com>
Message-ID: <C9F9FF21-C601-427A-86BE-7CE95C185269@oracle.com>

Ping again.

> On Mar 12, 2020, at 9:21 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please take a review at
> 
>   http://cr.openjdk.java.net/~weijun/8240848/webrev.00/
> 
> The problem is that selection has a different meaning for a specified optionType (the option value) and an unspecified one (the option index).
> 
> I also take this chance to make ConfirmationCallback more robust.
> 
> Thanks,
> Max
> 



From alexey at azul.com  Fri Apr  3 12:40:05 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Fri, 3 Apr 2020 12:40:05 +0000
Subject: RFR 8241960: The SHA3 message digests are not thread safe when
 cloned
In-Reply-To: <217d9ea6-ffbc-c9f3-0be1-f3bcc759e1d4@oracle.com>
References: <065849EF-ED24-4C50-AA9A-209D5890B074@azul.com>
 <784d0590-357d-1da0-ba01-49fed43ad6b3@oracle.com>
 <217d9ea6-ffbc-c9f3-0be1-f3bcc759e1d4@oracle.com>
Message-ID: <F701FE92-49A1-468A-82DE-E014DA522BB1@azul.com>

Hello Valeri,

Thank you for review. Please, have a look at updated patch at :  https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v1/

I?ve fixed your findings and renamed test class to ThreadSafetyTest. Jtreg already has ThreadSafeTest class for java.text.Normalizer functionality.

Thank you
Alexey

On 3 Apr 2020, at 02:51, Valerie Peng <valerie.peng at oracle.com<mailto:valerie.peng at oracle.com>> wrote:


Hi Alexey,

In general looks pretty good, just some comments on the regression test:

- line 28: The duration value 10 may be lowered to shorten the execution time. On a Linux machine, with threadFactor=5, each digest algo takes about (2xduration+2) sec and overall takes ~283sec. Cutting the duration value drastically to 2, I still can reproduce the bug. Maybe 4 would be a better default value considering the execution time.

- line 43: add "SHA-512/224", "SHA-512/256" to the ALGORITHM_ARRAY?

- line 50: instead of hardcoding 5 here, why not just use threadsFactor (assigned with default value 5 on line 48)?

- line 52-55: I think you meant to use 5 (instead of the value 180) as the default min duration on line 52. Then, use duration variable instead of the hardcoded  5 on line54. For testing purpose, why not just use the supplied value? You already have default values if none are supplied.

- Consider iterating through existing providers and remove isSHA3supported() method. This way all providers which supports the digest algorithm are tested and no provider-specific knowledge is needed. For example:

        Provider[] provs = Security.getProviders();

        for (Provider p : provs) {

            System.out.println("Testing provider " + p.getName() + "...");

            for (String alg: ALGORITHM_ARRAY) {

                try {

                    MessageDigest md = MessageDigest.getInstance(alg, p);

                    testThreadSafe(md, input, nTasks, duration, false);

                ....

- line 76: missing space char between } and catch.

Thanks,
Valerie


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

From valerie.peng at oracle.com  Fri Apr  3 19:36:29 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 3 Apr 2020 12:36:29 -0700
Subject: RFR 8241960: The SHA3 message digests are not thread safe when
 cloned
In-Reply-To: <F701FE92-49A1-468A-82DE-E014DA522BB1@azul.com>
References: <065849EF-ED24-4C50-AA9A-209D5890B074@azul.com>
 <784d0590-357d-1da0-ba01-49fed43ad6b3@oracle.com>
 <217d9ea6-ffbc-c9f3-0be1-f3bcc759e1d4@oracle.com>
 <F701FE92-49A1-468A-82DE-E014DA522BB1@azul.com>
Message-ID: <3f5cd79b-ba1a-e74d-37a6-956d817120d5@oracle.com>

The updated webrev looks good. I will proceed with pre-integration 
testing and push the changes on your behalf once the testing is done.

In the mean time, if you have any particular wording for the commit 
message, please send it my way.

Thanks,
Valerie
On 4/3/2020 5:40 AM, Alexey Bakhtin wrote:
> Hello Valeri,
>
> Thank you for review. Please, have a look at updated patch at : 
> https://cr.openjdk.java.net/~abakhtin/8241960/webrev.v1/
>
> I?ve fixed your findings and renamed test class to ThreadSafetyTest. 
> Jtreg already has ThreadSafeTest class for java.text.Normalizer 
> functionality.
>
> Thank you
> Alexey
>
>> On 3 Apr 2020, at 02:51, Valerie Peng <valerie.peng at oracle.com 
>> <mailto:valerie.peng at oracle.com>> wrote:
>>
>> Hi Alexey,
>>
>> In general looks pretty good, just some comments on the regression test:
>>
>> - line 28: The duration value 10 may be lowered to shorten the 
>> execution time. On a Linux machine, with threadFactor=5, each digest 
>> algo takes about (2xduration+2) sec and overall takes ~283sec. 
>> Cutting the duration value drastically to 2, I still can reproduce 
>> the bug. Maybe 4 would be a better default value considering the 
>> execution time.
>>
>> - line 43: add "SHA-512/224", "SHA-512/256" to the ALGORITHM_ARRAY?
>>
>> - line 50: instead of hardcoding 5 here, why not just use 
>> threadsFactor (assigned with default value 5 on line 48)?
>>
>> - line 52-55: I think you meant to use 5 (instead of the value 180) 
>> as the default min duration on line 52. Then, use duration variable 
>> instead of the hardcoded? 5 on line54. For testing purpose, why not 
>> just use the supplied value? You already have default values if none 
>> are supplied.
>>
>> - Consider iterating through existing providers and remove 
>> isSHA3supported() method. This way all providers which supports the 
>> digest algorithm are tested and no provider-specific knowledge is 
>> needed. For example:
>>
>>  ??????? Provider[] provs = Security.getProviders();
>>  ??????? for (Provider p : provs) {
>>  ??????????? System.out.println("Testing provider " + p.getName() + "...");
>>  ??????????? for (String alg: ALGORITHM_ARRAY) {
>>  ???????????     try {
>>  ???????????????     MessageDigest md = MessageDigest.getInstance(alg, p);
>>  ???????????????     testThreadSafe(md, input, nTasks, duration, false);
>>  ? ? ? ? ? ? ? ? ....
>>
>> - line 76: missing space char between } and catch.
>>
>> Thanks,
>> Valerie
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200403/a714447d/attachment.htm>

From valerie.peng at oracle.com  Fri Apr  3 21:32:37 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 3 Apr 2020 14:32:37 -0700
Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
In-Reply-To: <492f53ff-8f79-2a16-20a4-445b655f94a1@comcast.net>
References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com>
 <93e5a1a8-671c-2c73-2580-3f944092a229@comcast.net>
 <44c5a123-db7a-d4e5-d978-df3e089b37ba@oracle.com>
 <492f53ff-8f79-2a16-20a4-445b655f94a1@comcast.net>
Message-ID: <87fadfda-a7d4-edef-6de2-7de8914dc977@oracle.com>

Hi Mike,

We can update SunPKCS11 provider when the PKCS#11 official header files 
are updated with SHA3 and Hmac w/ SHA3.

I agree with you on the ideal case is to have no lagging in JCA and the 
SunPKCS11 provider.

The main reason for the lagging is that we need to test and make sure 
the added functionality works. I checked NSS which is what existing 
PKCS11 regression tests use and it does not have any SHA3 support. Do 
you know other PKCS11 vendors which supports SHA3 and Hmac w/ SHA3? If 
there are many, it'll help me justifying this when the official headers 
are not updated yet.

I am not sure if I understand your suggestion of PKCS11 specific 
mechanism naming convention. Is it about duplicating the pending SHA3 
mechanism definitions in SunPKCS11 provider? It's trivial to add the 
SHA3 related mechanism definitions to SunPKCS11 provider, but the 
convention is to add things only after they are official as it may be 
hard to change due to backward compatibility concern.

Thanks & hope you get enough sleep during this difficult time...

Valerie

On 3/31/2020 10:15 AM, Michael StJohns wrote:
> Sorry - this one got past me.
>
> For PKCS11 - the assignment of mechanism numbers can happen at any 
> time and doesn't necessarily result in a new version of the 
> specification.? In this case, the API won't change, so there's no 
> reason - since the mechanism numbers have been assigned since last May 
> at least - to wait for V3.? Among other things, I would expect that 
> various vendors have already implemented these in their 2.xx 
> implementations.
>
> One of the reasons I ended up using the SunPKCS11 wrapper classes 
> directly quite a while ago was that the PKCS11 spec hadn't been 
> updated, but that my PKCS11 provider was supplying various EC 
> mechanisms that I needed. Ideally, the JCA and SunPKCS11 provider 
> support should *precede* any given underlying PKCS11 device support, 
> not trail it by 6-12 months.
>
> The assignment of mechanism numbers is exactly equivalent to the 
> assignment of TLS cipher suite numbers - the underlying protocol 
> doesn't change, so this is mostly a change to the mapping tables and 
> enclosed classes.
>
> In any event, any given PKCS11 implementation may or may not support 
> any given set of mechanisms - the provider really ought to be calling 
> C_GetMechanismList() and using that as the list of supported JNA 
> mechanisms.
>
> Sorry - I'm dealing with a bit of lack of sleep here so I may be 
> babbling, but I'm wondering if it might not be a bad idea to add some 
> sort of PKCS11 specific mechanism naming convention to allow for the 
> lag/lead problem? E.g?? PKCS11_DIGEST_000002B0 would be PKCS11's 
> CKM_SHA3_256 hashing function given
>
>> #define CKM_SHA3_2560x000002B0
>>
> Just a thought.
>
> Thanks - Mike
>
>
> On 3/19/2020 5:27 PM, Valerie Peng wrote:
>> Hi Mike,
>>
>> Thanks for heads up. From what I can gather, SHA3 inclusion is part 
>> of PKCS#11 v3. Is this the next release which you are referring to? 
>> Or will there be an update to v2.40? Is there any schedule info for 
>> these update/release do you know?
>>
>> Following the convention, we normally don't add something which the 
>> underlying library has no support yet. With the new 6-month JDK 
>> release cycle, it's much faster for the added functionality to be 
>> available. So, I'd still prefer to update SunPKCS11 provider with 
>> SHA-3 once they are officially included.
>>
>> Valerie
>>
>> On 3/18/2020 4:07 PM, Michael StJohns wrote:
>>> On 3/18/2020 6:57 PM, Valerie Peng wrote:
>>>>
>>>> Anyone has time to help review this straight forward RFE? It's to 
>>>> add SHA-3 support to Hmac.
>>>>
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/
>>>>
>>>> Mach5 run is clean.
>>>>
>>>> Thanks,
>>>> Valerie
>>>
>>> Valerie -
>>>
>>> I know the RFE says no PKCS11 because 2.40 doesn't include those 
>>> items, but OASIS PKCS11 has proposed? SHA3 identifiers at 
>>> https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result 
>>> - maybe reach out and ask if these have been allocated pending the 
>>> next release?
>>>
>>> Mike
>>>
>>>
>>> #define CKM_SHA3_256????????????? 0x000002b0UL
>>> ?#define CKM_SHA3_256_HMAC???????? 0x000002b1UL
>>> ?#define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL
>>> ?#define CKM_SHA3_224????????????? 0x000002b5UL
>>> ?#define CKM_SHA3_224_HMAC???????? 0x000002b6UL
>>> ?#define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL
>>> ?#define CKM_SHA3_384????????????? 0x000002c0UL
>>> ?#define CKM_SHA3_384_HMAC???????? 0x000002c1UL
>>> ?#define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL
>>> ?#define CKM_SHA3_512????????????? 0x000002d0UL
>>> ?#define CKM_SHA3_512_HMAC???????? 0x000002d1UL
>>> ?#define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200403/b96b0619/attachment.htm>

From anthony.scarpino at oracle.com  Fri Apr  3 22:02:40 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 3 Apr 2020 15:02:40 -0700
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <7F1CE671-0ED5-4B6A-A919-7CAF29B381FE@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <7F1CE671-0ED5-4B6A-A919-7CAF29B381FE@oracle.com>
Message-ID: <7ea7e69b-30fc-1c77-603d-1498f28b1188@oracle.com>

On 4/2/20 8:34 PM, Weijun Wang wrote:
> Another question:
> 
> Why does getAlgorithm() of PublicKey and PrivateKey return "EdDSA"
> instead of "Ed25519" and "Ed448"?
> 
> Do we suggest people using "EdDSA" or "Ed25519"/"Ed448" when calling
> KeyFactory.getInstance() andKeyPairGenerator.getInstance()?

I don't think the code is suggesting anything. I believe the 
implementation is trying to be consistent with the API and other 
asymmetric keys factories and generators.  Just using EC as an example 
one uses "EC" for the getInstance() and provides the 
AlgorithmParameterSpec to generate the publicKey

kf = KeyFactory.getInstance("EC");
ECParameterSpec.ep = ..
kf.generatePublicKey(ep)

Being consistent for EDDSA, replace "EC" with "EDDSA" and specify a 
NamedParameterSpec to generate the public key; however, it is allowed to 
replace "EC" with ED25519. Similar to how XDH does it. Unfortunately 
generatePublicKey requires an AlgorithmParameterSpec, which is redundant 
in this case:
---
kf = KeyFactory.getInstance("ED25519")
...
kf.generatePublicKey(NamedParameterSpec.ED5519);
---

Since existing code follows the first example we should be consistent 
for apps adding EDDSA.

For KeyPairGenerator, initialize() isn't required to be called with 
getInstance("ED25519") to generate the key, but it will accept an 
initialize() call.  What's different is "EDDSA" will default to ED25519 
and does not require initialize(), but it will accept initialize() to 
change it to ED448.  I believe this is to be consistent with EC and RSA 
that need initialize().

To complete all the EDDSA entries, Signature is different because, the 
key provides the details about the curve.  It's similar to 
KeyPairGenerator, "EDDSA" doesn't lock you into a particular curve, 
allowing the key to specify the curve, which follows the EC/RSA logic. 
Specifying the curve at getInstance() locks you into that curve so at 
least NoSuchAlgorithm will be thrown at getInstance() unlike other 
asymmetric algorithms.

So to wrap all this up, it makes sense for consistency with prior 
behavior that all 3 classes have an EDDSA entry.  And the specific curve 
usage is also consistent with what has already been integrated with XDH.

Tony


> Thanks,
> Max
> 
>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>
>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>> Hi
>>> I need a code review for the EdDSA support in JEP 339.  The code builds on the existing java implemented constant time classes used for XDH and the NIST curves.  The change also adds classes to the public API to support EdDSA operations.
>>> All information about the JEP is located at:
>>> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219
>>> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/
>>> thanks
>>> Tony
>>
>>
>> I updated the webrev with some minor updates that were commented previously.
>>
>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>
>> Tony
> 



From xuelei.fan at oracle.com  Fri Apr  3 23:13:08 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 3 Apr 2020 16:13:08 -0700
Subject: RFR [15] JDK-8242145, New System Properties to configure the TLS
 signature schemes
Message-ID: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>

Hi,

Could I get the following update reviewed?

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

Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147

A third party's TLS implementation may not be able to handle a certain 
signature schemes, and cannot interop with JDK.  Although the 
implementation does not comply to TLS specifications, the impact could 
be significant if an application that uses the implementation is popular.

Thanks,
Xuelei


From mstjohns at comcast.net  Sat Apr  4 00:29:47 2020
From: mstjohns at comcast.net (Michael StJohns)
Date: Fri, 3 Apr 2020 20:29:47 -0400
Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
In-Reply-To: <87fadfda-a7d4-edef-6de2-7de8914dc977@oracle.com>
References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com>
 <93e5a1a8-671c-2c73-2580-3f944092a229@comcast.net>
 <44c5a123-db7a-d4e5-d978-df3e089b37ba@oracle.com>
 <492f53ff-8f79-2a16-20a4-445b655f94a1@comcast.net>
 <87fadfda-a7d4-edef-6de2-7de8914dc977@oracle.com>
Message-ID: <6b91c6a4-7b4d-99d8-817e-cbbe32dbad01@comcast.net>

Hi Valerie -

In line

On 4/3/2020 5:32 PM, Valerie Peng wrote:
>
> Hi Mike,
>
> We can update SunPKCS11 provider when the PKCS#11 official header 
> files are updated with SHA3 and Hmac w/ SHA3.
>
> I agree with you on the ideal case is to have no lagging in JCA and 
> the SunPKCS11 provider.
>
> The main reason for the lagging is that we need to test and make sure 
> the added functionality works. I checked NSS which is what existing 
> PKCS11 regression tests use and it does not have any SHA3 support. Do 
> you know other PKCS11 vendors which supports SHA3 and Hmac w/ SHA3? If 
> there are many, it'll help me justifying this when the official 
> headers are not updated yet.
>
I've got an include file from Utimaco dated 27 March 2017 that includes 
the SHA3 assignments from PKCS11 - and their collateral says they 
implement SHA3 (this is all of the message digest, hmac and signature 
mechanisms, and key derivation mechanisms specified for PKCS11 3.0.

Safenet ProtectServer has it 
https://data-protection-updates.gemalto.com/2018/04/27/product-release-safenet-protecttoolkit-5-6/

I can't find anything that says nCipher has it.

That's two out of three of the big ones.

> I am not sure if I understand your suggestion of PKCS11 specific 
> mechanism naming convention. Is it about duplicating the pending SHA3 
> mechanism definitions in SunPKCS11 provider? It's trivial to add the 
> SHA3 related mechanism definitions to SunPKCS11 provider, but the 
> convention is to add things only after they are official as it may be 
> hard to change due to backward compatibility concern.
>
Something like MessageDigest.getInstance ("SHA3_256", pkcs11provider) 
ends up mapping to an underlying call "CK_MECHANISM m = new CK_MECHANISM 
(CKM_SHA3_256);" where CKM_SHA3_256 is? "public static long CKM_SHA3_256 
= 0x000002b0L;"

There are at times a number of proprietary or provider specific 
algorithms that the underlying PKCS11 dll might support, but for which 
the Java PKCS11 provider doesn't have the string (name) to mechanism 
number mapping, but for which the API is the same as for any other 
algorithm of its class.

For example, the Utimaco PKCS11 definitions include

#define CKM_DES3_RETAIL_MAC??????????? 0x80000135??? // Retail-MAC with 
0-Padding

Which is unlikely to be part of any PKCS11 standard, but could be 
accessed by

Mac.getInstance ("PKCS11_MAC_16_80000135", pkcs11provider); // 16 is the 
mac length.

So this is an escape mechanism to permit access to provider extensions 
without having to reflect them back into the Java PKCS11 provider.

(When support for EC algorithms were being kept from various software - 
including NSS - due to nervousness about patent claims, I ended up using 
the PKCS11 wrapper classes directly specifically because I couldn't do 
an ECDSA via the PKCS11 provider.? That hasn't been the case for a 
while, but it's always bothered me that the JCA got in the way of the 
underlying provider.)

I don't know that is doable given the current architecture (which 
usually requires an OID for a mechanism to register it for SunPKCS11), 
but something to think about.

> Thanks & hope you get enough sleep during this difficult time...
>
*laugh* I'm doing better thanks.? I wrenched something in my shoulder 
and it kept me awake or woke me up when I was sleeping. Much better now.

Thanks! Mike


> Valerie
>
> On 3/31/2020 10:15 AM, Michael StJohns wrote:
>> Sorry - this one got past me.
>>
>> For PKCS11 - the assignment of mechanism numbers can happen at any 
>> time and doesn't necessarily result in a new version of the 
>> specification.? In this case, the API won't change, so there's no 
>> reason - since the mechanism numbers have been assigned since last 
>> May at least - to wait for V3.? Among other things, I would expect 
>> that various vendors have already implemented these in their 2.xx 
>> implementations.
>>
>> One of the reasons I ended up using the SunPKCS11 wrapper classes 
>> directly quite a while ago was that the PKCS11 spec hadn't been 
>> updated, but that my PKCS11 provider was supplying various EC 
>> mechanisms that I needed. Ideally, the JCA and SunPKCS11 provider 
>> support should *precede* any given underlying PKCS11 device support, 
>> not trail it by 6-12 months.
>>
>> The assignment of mechanism numbers is exactly equivalent to the 
>> assignment of TLS cipher suite numbers - the underlying protocol 
>> doesn't change, so this is mostly a change to the mapping tables and 
>> enclosed classes.
>>
>> In any event, any given PKCS11 implementation may or may not support 
>> any given set of mechanisms - the provider really ought to be calling 
>> C_GetMechanismList() and using that as the list of supported JNA 
>> mechanisms.
>>
>> Sorry - I'm dealing with a bit of lack of sleep here so I may be 
>> babbling, but I'm wondering if it might not be a bad idea to add some 
>> sort of PKCS11 specific mechanism naming convention to allow for the 
>> lag/lead problem??? E.g?? PKCS11_DIGEST_000002B0 would be PKCS11's 
>> CKM_SHA3_256 hashing function given
>>
>>> #define CKM_SHA3_2560x000002B0
>>>
>> Just a thought.
>>
>> Thanks - Mike
>>
>>
>> On 3/19/2020 5:27 PM, Valerie Peng wrote:
>>> Hi Mike,
>>>
>>> Thanks for heads up. From what I can gather, SHA3 inclusion is part 
>>> of PKCS#11 v3. Is this the next release which you are referring to? 
>>> Or will there be an update to v2.40? Is there any schedule info for 
>>> these update/release do you know?
>>>
>>> Following the convention, we normally don't add something which the 
>>> underlying library has no support yet. With the new 6-month JDK 
>>> release cycle, it's much faster for the added functionality to be 
>>> available. So, I'd still prefer to update SunPKCS11 provider with 
>>> SHA-3 once they are officially included.
>>>
>>> Valerie
>>>
>>> On 3/18/2020 4:07 PM, Michael StJohns wrote:
>>>> On 3/18/2020 6:57 PM, Valerie Peng wrote:
>>>>>
>>>>> Anyone has time to help review this straight forward RFE? It's to 
>>>>> add SHA-3 support to Hmac.
>>>>>
>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/
>>>>>
>>>>> Mach5 run is clean.
>>>>>
>>>>> Thanks,
>>>>> Valerie
>>>>
>>>> Valerie -
>>>>
>>>> I know the RFE says no PKCS11 because 2.40 doesn't include those 
>>>> items, but OASIS PKCS11 has proposed? SHA3 identifiers at 
>>>> https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result 
>>>> - maybe reach out and ask if these have been allocated pending the 
>>>> next release?
>>>>
>>>> Mike
>>>>
>>>>
>>>> #define CKM_SHA3_256????????????? 0x000002b0UL
>>>> ?#define CKM_SHA3_256_HMAC???????? 0x000002b1UL
>>>> ?#define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL
>>>> ?#define CKM_SHA3_224????????????? 0x000002b5UL
>>>> ?#define CKM_SHA3_224_HMAC???????? 0x000002b6UL
>>>> ?#define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL
>>>> ?#define CKM_SHA3_384????????????? 0x000002c0UL
>>>> ?#define CKM_SHA3_384_HMAC???????? 0x000002c1UL
>>>> ?#define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL
>>>> ?#define CKM_SHA3_512????????????? 0x000002d0UL
>>>> ?#define CKM_SHA3_512_HMAC???????? 0x000002d1UL
>>>> ?#define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL
>>>>
>>>>
>>

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

From xuelei.fan at oracle.com  Sun Apr  5 01:11:53 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 4 Apr 2020 18:11:53 -0700
Subject: RFR [15] JDK-8215711, Missing key_share extension for (EC)DHE key
 exchange should alert missing_extension
Message-ID: <e78db5a4-eee7-de99-73aa-ccbee88794b1@oracle.com>

Hi,

Could I have the following update reviewed?

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

In the current TLS implementation, if one of "supported_groups" 
extension and "key_share" extension is not present in the ClientHello 
handshake message, the internal_error alter will be used.  Per the spec 
(RFC 8846), the alert should be "missing_extension" alert.

The fuzzing test passed with this update.  No new regression test 
(noreg-external).

Thanks,
Xuelei


From hai-may.chao at oracle.com  Sun Apr  5 06:41:20 2020
From: hai-may.chao at oracle.com (Hai-May Chao)
Date: Sat, 4 Apr 2020 23:41:20 -0700
Subject: RFR[15]: 8172404: Tools should warn if weak algorithms are used
 before restricting them
Message-ID: <1A4115A0-3C12-40A2-A42F-54297E7E233F@oracle.com>

Hi,

I'd like to request a review for:

Bug: https://bugs.openjdk.java.net/browse/JDK-8172404 <https://bugs.openjdk.java.net/browse/JDK-8172404>
CSR: https://bugs.openjdk.java.net/browse/JDK-8238640 <https://bugs.openjdk.java.net/browse/JDK-8238640>

It?d be useful to start warning users that certain algorithms and key lengths are becoming weak, so that users could begin transition away from them before they are actually disabled. A new security property named jdk.security.legacyAlgorithms is added to the java.security file to list the legacy algorithms. The keytool and jarsigner tools are enhanced to enforce the new property and to emit the warning messages when legacy algorithms are used.

Thanks,
Hai-May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200404/691e04f0/attachment.htm>

From weijun.wang at oracle.com  Sun Apr  5 09:11:51 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sun, 5 Apr 2020 02:11:51 -0700 (PDT)
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <7ea7e69b-30fc-1c77-603d-1498f28b1188@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <7F1CE671-0ED5-4B6A-A919-7CAF29B381FE@oracle.com>
 <7ea7e69b-30fc-1c77-603d-1498f28b1188@oracle.com>
Message-ID: <3C69580D-DF19-4634-94B0-3429D4883F24@oracle.com>

OK, I undertand now:

1. Crypto primitives (Signature/KeyFactory/KeyPairGenerator) would support all "EdDSA" and "Ed25519"/"Ed448", and their getAlgorithm() returns what was used back in getInstance().

2. Key's getAlgorithm() always returns "EdDSA".

Thanks,
Max

> On Apr 4, 2020, at 6:02 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> On 4/2/20 8:34 PM, Weijun Wang wrote:
>> Another question:
>> Why does getAlgorithm() of PublicKey and PrivateKey return "EdDSA"
>> instead of "Ed25519" and "Ed448"?
>> Do we suggest people using "EdDSA" or "Ed25519"/"Ed448" when calling
>> KeyFactory.getInstance() andKeyPairGenerator.getInstance()?
> 
> I don't think the code is suggesting anything. I believe the implementation is trying to be consistent with the API and other asymmetric keys factories and generators.  Just using EC as an example one uses "EC" for the getInstance() and provides the AlgorithmParameterSpec to generate the publicKey
> 
> kf = KeyFactory.getInstance("EC");
> ECParameterSpec.ep = ..
> kf.generatePublicKey(ep)
> 
> Being consistent for EDDSA, replace "EC" with "EDDSA" and specify a NamedParameterSpec to generate the public key; however, it is allowed to replace "EC" with ED25519. Similar to how XDH does it. Unfortunately generatePublicKey requires an AlgorithmParameterSpec, which is redundant in this case:
> ---
> kf = KeyFactory.getInstance("ED25519")
> ...
> kf.generatePublicKey(NamedParameterSpec.ED5519);
> ---
> 
> Since existing code follows the first example we should be consistent for apps adding EDDSA.
> 
> For KeyPairGenerator, initialize() isn't required to be called with getInstance("ED25519") to generate the key, but it will accept an initialize() call.  What's different is "EDDSA" will default to ED25519 and does not require initialize(), but it will accept initialize() to change it to ED448.  I believe this is to be consistent with EC and RSA that need initialize().
> 
> To complete all the EDDSA entries, Signature is different because, the key provides the details about the curve.  It's similar to KeyPairGenerator, "EDDSA" doesn't lock you into a particular curve, allowing the key to specify the curve, which follows the EC/RSA logic. Specifying the curve at getInstance() locks you into that curve so at least NoSuchAlgorithm will be thrown at getInstance() unlike other asymmetric algorithms.
> 
> So to wrap all this up, it makes sense for consistency with prior behavior that all 3 classes have an EDDSA entry.  And the specific curve usage is also consistent with what has already been integrated with XDH.
> 
> Tony
> 
> 
>> Thanks,
>> Max
>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>> 
>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>> Hi
>>>> I need a code review for the EdDSA support in JEP 339.  The code builds on the existing java implemented constant time classes used for XDH and the NIST curves.  The change also adds classes to the public API to support EdDSA operations.
>>>> All information about the JEP is located at:
>>>> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231
>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219
>>>> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/
>>>> thanks
>>>> Tony
>>> 
>>> 
>>> I updated the webrev with some minor updates that were commented previously.
>>> 
>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>> 
>>> Tony
> 



From hai-may.chao at oracle.com  Sun Apr  5 16:51:34 2020
From: hai-may.chao at oracle.com (Hai-May Chao)
Date: Sun, 5 Apr 2020 09:51:34 -0700
Subject: RFR[15]: 8172404: Tools should warn if weak algorithms are used
 before restricting them
In-Reply-To: <1A4115A0-3C12-40A2-A42F-54297E7E233F@oracle.com>
References: <1A4115A0-3C12-40A2-A42F-54297E7E233F@oracle.com>
Message-ID: <B63672DC-8070-434E-830C-51F47E79DE81@oracle.com>

Here is the webrev:

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

Thanks,
Hai-May


> On Apr 4, 2020, at 11:41 PM, Hai-May Chao <hai-may.chao at oracle.com> wrote:
> 
> Hi,
> 
> I'd like to request a review for:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172404 <https://bugs.openjdk.java.net/browse/JDK-8172404>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8238640 <https://bugs.openjdk.java.net/browse/JDK-8238640>
> 
> It?d be useful to start warning users that certain algorithms and key lengths are becoming weak, so that users could begin transition away from them before they are actually disabled. A new security property named jdk.security.legacyAlgorithms is added to the java.security file to list the legacy algorithms. The keytool and jarsigner tools are enhanced to enforce the new property and to emit the warning messages when legacy algorithms are used.
> 
> Thanks,
> Hai-May

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

From anthony.scarpino at oracle.com  Sun Apr  5 20:41:35 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Sun, 5 Apr 2020 13:41:35 -0700
Subject: RFR [15] JDK-8215711, Missing key_share extension for (EC)DHE key
 exchange should alert missing_extension
In-Reply-To: <e78db5a4-eee7-de99-73aa-ccbee88794b1@oracle.com>
References: <e78db5a4-eee7-de99-73aa-ccbee88794b1@oracle.com>
Message-ID: <be646f07-948c-63db-d5a4-b814c9df4b3d@oracle.com>

On 4/4/20 6:11 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I have the following update reviewed?
> 
>  ??? http://cr.openjdk.java.net/~xuelei/8215711/webrev.00/
> 
> In the current TLS implementation, if one of "supported_groups" 
> extension and "key_share" extension is not present in the ClientHello 
> handshake message, the internal_error alter will be used.? Per the spec 
> (RFC 8846), the alert should be "missing_extension" alert.
> 
> The fuzzing test passed with this update.? No new regression test 
> (noreg-external).
> 
> Thanks,
> Xuelei

The change looks fine. It looks like you implemented what is in section 
9.2, and it looks like the absent methods will be called from the 
consumeOnLoad() as all those extensions can be in a ClientHello msg.

thanks

Tony


From xuelei.fan at oracle.com  Sun Apr  5 20:51:57 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sun, 5 Apr 2020 13:51:57 -0700
Subject: RFR [15] JDK-8215711, Missing key_share extension for (EC)DHE key
 exchange should alert missing_extension
In-Reply-To: <be646f07-948c-63db-d5a4-b814c9df4b3d@oracle.com>
References: <e78db5a4-eee7-de99-73aa-ccbee88794b1@oracle.com>
 <be646f07-948c-63db-d5a4-b814c9df4b3d@oracle.com>
Message-ID: <c962cb0e-f608-0021-63e6-82ad69f14c11@oracle.com>

On 4/5/2020 1:41 PM, Anthony Scarpino wrote:
> On 4/4/20 6:11 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I have the following update reviewed?
>>
>> ???? http://cr.openjdk.java.net/~xuelei/8215711/webrev.00/
>>
>> In the current TLS implementation, if one of "supported_groups" 
>> extension and "key_share" extension is not present in the ClientHello 
>> handshake message, the internal_error alter will be used.? Per the 
>> spec (RFC 8846), the alert should be "missing_extension" alert.
>>
>> The fuzzing test passed with this update.? No new regression test 
>> (noreg-external).
>>
>> Thanks,
>> Xuelei
> 
> The change looks fine. It looks like you implemented what is in section 
> 9.2, and it looks like the absent methods will be called from the 
> consumeOnLoad() as all those extensions can be in a ClientHello msg.
> 
Yes.

Thanks for the review!

Xuelei


From weijun.wang at oracle.com  Mon Apr  6 07:17:35 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 6 Apr 2020 15:17:35 +0800
Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
In-Reply-To: <F144DF74-BEC3-4D60-AF76-8CC260E9BD64@oracle.com>
References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com>
 <AM6PR03MB4389C21F2BF848D3CBFB57E6FFF70@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com>
 <0d51107d-618c-b72b-9e2d-88e07ba88645@oracle.com>
 <EAD376AF-3615-4F12-AF93-6A940B84AA04@oracle.com>
 <16f323d4-52eb-5bd3-90b7-426a4ce5379f@oracle.com>
 <F144DF74-BEC3-4D60-AF76-8CC260E9BD64@oracle.com>
Message-ID: <A1F79B2D-1B05-4510-BB13-10FFC82A6B84@oracle.com>

FYI: I'm about to work on CMS support for RSASSA-PSS and EdDSA, and would like to move all signature-related methods (everyone starting from makeSigAlg) from AlgorithmId.java to SingatureUtil.java. Hopefully it will not conflict with your code change.

--Max

> On Mar 21, 2020, at 5:48 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> 
>> On Mar 21, 2020, at 2:39 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>> 
>> As I have started prototyping changes for minimizing the current duplication of oids in various providers and sun.security.x509.AlgorithmId class, I choose to leave AlgorithmId class out for now.
> 
> Very glad to hear this. No need to touch more on AlgorithmId.java then.
> 
> Thanks,
> Max
> 



From weijun.wang at oracle.com  Mon Apr  6 08:34:17 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 6 Apr 2020 16:34:17 +0800
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <3C69580D-DF19-4634-94B0-3429D4883F24@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <7F1CE671-0ED5-4B6A-A919-7CAF29B381FE@oracle.com>
 <7ea7e69b-30fc-1c77-603d-1498f28b1188@oracle.com>
 <3C69580D-DF19-4634-94B0-3429D4883F24@oracle.com>
Message-ID: <63552B92-CB20-4BE7-A629-39AF048E12EB@oracle.com>

Some other issues:

1. AlgorithmId::derEncode. Otherwise openssl does not like the extra NULL.

@@ -196,7 +205,8 @@
             } else {
                 bytes.putNull();
             }*/
-            if (algid.equals(RSASSA_PSS_oid)) {
+            if (algid.equals(RSASSA_PSS_oid) || algid.equals(ed448_oid)
+                    || algid.equals(ed25519_oid)) {
                 // RFC 4055 3.3: when an RSASSA-PSS key does not require
                 // parameter validation, field is absent.
             } else {

2. AlgorithmId::getWithParameterSpec. Please return "AlgorithmId.get(algName)" when "spec instanceof EdDSAParameterSpec". 

Thanks,
Max

> On Apr 5, 2020, at 5:11 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> OK, I undertand now:
> 
> 1. Crypto primitives (Signature/KeyFactory/KeyPairGenerator) would support all "EdDSA" and "Ed25519"/"Ed448", and their getAlgorithm() returns what was used back in getInstance().
> 
> 2. Key's getAlgorithm() always returns "EdDSA".
> 
> Thanks,
> Max
> 
>> On Apr 4, 2020, at 6:02 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>> 
>> On 4/2/20 8:34 PM, Weijun Wang wrote:
>>> Another question:
>>> Why does getAlgorithm() of PublicKey and PrivateKey return "EdDSA"
>>> instead of "Ed25519" and "Ed448"?
>>> Do we suggest people using "EdDSA" or "Ed25519"/"Ed448" when calling
>>> KeyFactory.getInstance() andKeyPairGenerator.getInstance()?
>> 
>> I don't think the code is suggesting anything. I believe the implementation is trying to be consistent with the API and other asymmetric keys factories and generators.  Just using EC as an example one uses "EC" for the getInstance() and provides the AlgorithmParameterSpec to generate the publicKey
>> 
>> kf = KeyFactory.getInstance("EC");
>> ECParameterSpec.ep = ..
>> kf.generatePublicKey(ep)
>> 
>> Being consistent for EDDSA, replace "EC" with "EDDSA" and specify a NamedParameterSpec to generate the public key; however, it is allowed to replace "EC" with ED25519. Similar to how XDH does it. Unfortunately generatePublicKey requires an AlgorithmParameterSpec, which is redundant in this case:
>> ---
>> kf = KeyFactory.getInstance("ED25519")
>> ...
>> kf.generatePublicKey(NamedParameterSpec.ED5519);
>> ---
>> 
>> Since existing code follows the first example we should be consistent for apps adding EDDSA.
>> 
>> For KeyPairGenerator, initialize() isn't required to be called with getInstance("ED25519") to generate the key, but it will accept an initialize() call.  What's different is "EDDSA" will default to ED25519 and does not require initialize(), but it will accept initialize() to change it to ED448.  I believe this is to be consistent with EC and RSA that need initialize().
>> 
>> To complete all the EDDSA entries, Signature is different because, the key provides the details about the curve.  It's similar to KeyPairGenerator, "EDDSA" doesn't lock you into a particular curve, allowing the key to specify the curve, which follows the EC/RSA logic. Specifying the curve at getInstance() locks you into that curve so at least NoSuchAlgorithm will be thrown at getInstance() unlike other asymmetric algorithms.
>> 
>> So to wrap all this up, it makes sense for consistency with prior behavior that all 3 classes have an EDDSA entry.  And the specific curve usage is also consistent with what has already been integrated with XDH.
>> 
>> Tony
>> 
>> 
>>> Thanks,
>>> Max
>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>> 
>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>> Hi
>>>>> I need a code review for the EdDSA support in JEP 339.  The code builds on the existing java implemented constant time classes used for XDH and the NIST curves.  The change also adds classes to the public API to support EdDSA operations.
>>>>> All information about the JEP is located at:
>>>>> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231
>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219
>>>>> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/
>>>>> thanks
>>>>> Tony
>>>> 
>>>> 
>>>> I updated the webrev with some minor updates that were commented previously.
>>>> 
>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>> 
>>>> Tony
>> 
> 



From valerie.peng at oracle.com  Tue Apr  7 02:43:24 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 6 Apr 2020 19:43:24 -0700
Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
In-Reply-To: <A1F79B2D-1B05-4510-BB13-10FFC82A6B84@oracle.com>
References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com>
 <AM6PR03MB4389C21F2BF848D3CBFB57E6FFF70@AM6PR03MB4389.eurprd03.prod.outlook.com>
 <80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com>
 <0d51107d-618c-b72b-9e2d-88e07ba88645@oracle.com>
 <EAD376AF-3615-4F12-AF93-6A940B84AA04@oracle.com>
 <16f323d4-52eb-5bd3-90b7-426a4ce5379f@oracle.com>
 <F144DF74-BEC3-4D60-AF76-8CC260E9BD64@oracle.com>
 <A1F79B2D-1B05-4510-BB13-10FFC82A6B84@oracle.com>
Message-ID: <9915b73b-7bd1-7391-1a31-4d4259d3df07@oracle.com>


Thanks for the heads up. It should be straightforward to handle/merge.

Valerie


On 4/6/2020 12:17 AM, Weijun Wang wrote:
> FYI: I'm about to work on CMS support for RSASSA-PSS and EdDSA, and would like to move all signature-related methods (everyone starting from makeSigAlg) from AlgorithmId.java to SingatureUtil.java. Hopefully it will not conflict with your code change.
>
> --Max
>
>> On Mar 21, 2020, at 5:48 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>>
>>
>>> On Mar 21, 2020, at 2:39 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>
>>> As I have started prototyping changes for minimizing the current duplication of oids in various providers and sun.security.x509.AlgorithmId class, I choose to leave AlgorithmId class out for now.
>> Very glad to hear this. No need to touch more on AlgorithmId.java then.
>>
>> Thanks,
>> Max
>>


From weijun.wang at oracle.com  Tue Apr  7 03:11:42 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 7 Apr 2020 11:11:42 +0800
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
Message-ID: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>

Please review the fix at

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

The major change is inside X509CRLImpl.java to allow params setting and reading.

I also take this chance to:

1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".

2. Revert a former change in X509CertImpl.java, which might be a safer call.

Thanks,
Max



From weijun.wang at oracle.com  Tue Apr  7 03:14:26 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 7 Apr 2020 11:14:26 +0800
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <63552B92-CB20-4BE7-A629-39AF048E12EB@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
 <7F1CE671-0ED5-4B6A-A919-7CAF29B381FE@oracle.com>
 <7ea7e69b-30fc-1c77-603d-1498f28b1188@oracle.com>
 <3C69580D-DF19-4634-94B0-3429D4883F24@oracle.com>
 <63552B92-CB20-4BE7-A629-39AF048E12EB@oracle.com>
Message-ID: <43F637D2-902E-4C0B-8B40-E86918FB7AFB@oracle.com>

I don't know what the final solution for getParameters now but we can be sure it won't return something that has a non-null getEncoded(), this means the following change is necessary:

diff --git a/src/java.base/share/classes/sun/security/x509/X509CertImpl.java b/src/java.base/share/classes/sun/security/x509/X509CertImpl.java
--- a/src/java.base/share/classes/sun/security/x509/X509CertImpl.java
+++ b/src/java.base/share/classes/sun/security/x509/X509CertImpl.java
@@ -602,8 +602,12 @@
                     null);
 
             // in case the name is reset
+            AlgorithmParameters p = null;
             if (signingParams != null) {
-                algId = AlgorithmId.get(sigEngine.getParameters());
+                p = sigEngine.getParameters();
+            }
+            if (p != null) {
+                algId = AlgorithmId.get(p);
             } else {
                 algId = AlgorithmId.get(algorithm);
             }

If we decide getParameters() should throw an exception, the check will be different.

PKCS10::encodeAndSign got it correctly.

X509CRLimpl::sign has not considered possible parameters at all. I've just asked for a code view at http://cr.openjdk.java.net/~weijun/8242184/webrev.00/ to add it but it will need to same adjustment once EdDSA is added.

Thanks,
Max


> On Apr 6, 2020, at 4:34 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Some other issues:
> 
> 1. AlgorithmId::derEncode. Otherwise openssl does not like the extra NULL.
> 
> @@ -196,7 +205,8 @@
>             } else {
>                 bytes.putNull();
>             }*/
> -            if (algid.equals(RSASSA_PSS_oid)) {
> +            if (algid.equals(RSASSA_PSS_oid) || algid.equals(ed448_oid)
> +                    || algid.equals(ed25519_oid)) {
>                 // RFC 4055 3.3: when an RSASSA-PSS key does not require
>                 // parameter validation, field is absent.
>             } else {
> 
> 2. AlgorithmId::getWithParameterSpec. Please return "AlgorithmId.get(algName)" when "spec instanceof EdDSAParameterSpec". 
> 
> Thanks,
> Max
> 
>> On Apr 5, 2020, at 5:11 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>> 
>> OK, I undertand now:
>> 
>> 1. Crypto primitives (Signature/KeyFactory/KeyPairGenerator) would support all "EdDSA" and "Ed25519"/"Ed448", and their getAlgorithm() returns what was used back in getInstance().
>> 
>> 2. Key's getAlgorithm() always returns "EdDSA".
>> 
>> Thanks,
>> Max
>> 
>>> On Apr 4, 2020, at 6:02 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>> 
>>> On 4/2/20 8:34 PM, Weijun Wang wrote:
>>>> Another question:
>>>> Why does getAlgorithm() of PublicKey and PrivateKey return "EdDSA"
>>>> instead of "Ed25519" and "Ed448"?
>>>> Do we suggest people using "EdDSA" or "Ed25519"/"Ed448" when calling
>>>> KeyFactory.getInstance() andKeyPairGenerator.getInstance()?
>>> 
>>> I don't think the code is suggesting anything. I believe the implementation is trying to be consistent with the API and other asymmetric keys factories and generators.  Just using EC as an example one uses "EC" for the getInstance() and provides the AlgorithmParameterSpec to generate the publicKey
>>> 
>>> kf = KeyFactory.getInstance("EC");
>>> ECParameterSpec.ep = ..
>>> kf.generatePublicKey(ep)
>>> 
>>> Being consistent for EDDSA, replace "EC" with "EDDSA" and specify a NamedParameterSpec to generate the public key; however, it is allowed to replace "EC" with ED25519. Similar to how XDH does it. Unfortunately generatePublicKey requires an AlgorithmParameterSpec, which is redundant in this case:
>>> ---
>>> kf = KeyFactory.getInstance("ED25519")
>>> ...
>>> kf.generatePublicKey(NamedParameterSpec.ED5519);
>>> ---
>>> 
>>> Since existing code follows the first example we should be consistent for apps adding EDDSA.
>>> 
>>> For KeyPairGenerator, initialize() isn't required to be called with getInstance("ED25519") to generate the key, but it will accept an initialize() call.  What's different is "EDDSA" will default to ED25519 and does not require initialize(), but it will accept initialize() to change it to ED448.  I believe this is to be consistent with EC and RSA that need initialize().
>>> 
>>> To complete all the EDDSA entries, Signature is different because, the key provides the details about the curve.  It's similar to KeyPairGenerator, "EDDSA" doesn't lock you into a particular curve, allowing the key to specify the curve, which follows the EC/RSA logic. Specifying the curve at getInstance() locks you into that curve so at least NoSuchAlgorithm will be thrown at getInstance() unlike other asymmetric algorithms.
>>> 
>>> So to wrap all this up, it makes sense for consistency with prior behavior that all 3 classes have an EDDSA entry.  And the specific curve usage is also consistent with what has already been integrated with XDH.
>>> 
>>> Tony
>>> 
>>> 
>>>> Thanks,
>>>> Max
>>>>> On Mar 24, 2020, at 2:53 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>>>> 
>>>>> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>>>>>> Hi
>>>>>> I need a code review for the EdDSA support in JEP 339.  The code builds on the existing java implemented constant time classes used for XDH and the NIST curves.  The change also adds classes to the public API to support EdDSA operations.
>>>>>> All information about the JEP is located at:
>>>>>> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231
>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219
>>>>>> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/
>>>>>> thanks
>>>>>> Tony
>>>>> 
>>>>> 
>>>>> I updated the webrev with some minor updates that were commented previously.
>>>>> 
>>>>> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/
>>>>> 
>>>>> Tony
>>> 
>> 
> 



From weijun.wang at oracle.com  Tue Apr  7 08:04:14 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 7 Apr 2020 16:04:14 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
Message-ID: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>

I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:

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

Please review everything at:

   Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
            CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
         webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/

The CSR "Problem" section has more info on why it's better to remove it now.

Thanks,
Max



From sean.coffey at oracle.com  Tue Apr  7 18:51:29 2020
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 7 Apr 2020 19:51:29 +0100
Subject: RFR[jdk] 8237474: Default SSLEngine should create in server role
In-Reply-To: <df3728ad-0ea4-4bc5-b05c-7fec1e5914e4@default>
References: <939a2142-60b6-49e8-873f-3f3888293342@default>
 <1788edc0-97f3-48cf-8b04-fd6520e1df16@default>
 <adac0396-d49f-f11e-d7b6-53dc7151a07f@oracle.com>
 <df3728ad-0ea4-4bc5-b05c-7fec1e5914e4@default>
Message-ID: <882c181f-92db-096a-f7dc-00021068604c@oracle.com>

Looks good to me also Prasad. Trivially, I think you can drop the 
'object' word in this implNote:

"for a new {@code SSLEngine} object"

Also, don't forget to create the release note sub-task for this change.

regards,
Sean.

On 02/04/2020 16:56, Prasadrao Koppula wrote:
> Thanks for review Xuelei, I will incorporate your suggestions.
>
> Thanks,
> Prasad.K
>
>> -----Original Message-----
>> From: Xuelei Fan
>> Sent: Thursday, April 2, 2020 9:12 PM
>> To: security-dev at openjdk.java.net
>> Subject: Re: RFR[jdk] 8237474: Default SSLEngine should create in server role
>>
>> Please update copyright year to 2020.
>>
>> SSLEngine.java
>> --------------
>> @@ -1109,10 +1115,14 @@
>> +     * @implNote
>> +     * The JDK SunJSSE provider implementation returns false unless
>> {@link setUseClientMode}
>> +     *          is used to change the mode to true.
>>
>> For the link, I may add parameter, and limit the line under 80 characters, and
>> don't indent the lines.
>>
>> +     * @implNote
>> -     * The JDK SunJSSE provider implementation returns false unless
>> {@link setUseClientMode}
>> -     *          is used to change the mode to true.
>> +     * The JDK SunJSSE provider implementation returns false unless
>> +     * {@link setUseClientMode(boolean)} is used to change the mode
>> +      * to true.
>>
>> It's fine to leave the CSR  as it is.
>>
>> Otherwise, looks fine to me.
>>
>> Xuelei
>>
>> On 3/30/2020 6:50 AM, Prasadrao Koppula wrote:
>>> Hi,
>>>
>>> Added @implnote and updated test changes, here is the new webrev,
>>> please review it.
>>>
>>> Webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.01/
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8237474
>>>
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
>>>
>>> Thanks,
>>>
>>> Prasad.K
>>>
>>> *From:* Prasadrao Koppula
>>> *Sent:* Friday, February 7, 2020 5:03 PM
>>> *To:* security-dev at openjdk.java.net
>>> *Subject:* RFR[jdk] 8237474: Default SSLEngine should create in server
>>> role
>>>
>>> Hi,
>>>
>>> Could you please review this patch. Default server role mode was
>>> flipped in SSLEngine, to client role mode as part of SSL package code
>>> refactoring for TLSv1.3, this patch flips back default client role to
>>> server role in SSLEngine.
>>>
>>> webrev: http://cr.openjdk.java.net/~pkoppula/8237474/webrev.00/
>>>
>>> issue: https://bugs.openjdk.java.net/browse/JDK-8237474
>>>
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238593
>>>
>>> Thanks,
>>>
>>> Prasad.K
>>>


From jamil.j.nimeh at oracle.com  Tue Apr  7 19:53:02 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 7 Apr 2020 12:53:02 -0700
Subject: RDR: JDK-8242294 JSSE Client does not throw SSLException when an
 alert occurs during handshaking
Message-ID: <93b0c7e5-9f29-a6df-4215-d69a4aa190e2@oracle.com>

Hello all,

This is a fix that brings the JSSE client from JDK 11+ back in line with 
the JDK 8 behavior of delivering SSLException on subsequent reads after 
a handshake has failed due to an alert condition.

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

Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8242294/webrev.01

Thanks,

--Jamil



From xuelei.fan at oracle.com  Tue Apr  7 20:44:18 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 7 Apr 2020 13:44:18 -0700
Subject: RDR: JDK-8242294 JSSE Client does not throw SSLException when an
 alert occurs during handshaking
In-Reply-To: <93b0c7e5-9f29-a6df-4215-d69a4aa190e2@oracle.com>
References: <93b0c7e5-9f29-a6df-4215-d69a4aa190e2@oracle.com>
Message-ID: <f073503b-1ea1-4546-38ff-aa5cf5714fd9@oracle.com>

The conContext.isBroken condition in line 1124 is duplicated, and could 
be safely removed, I think.  Otherwise, looks good to me.  I don't think 
there's need for another round of RFR.

Thanks,
Xuelei

On 4/7/2020 12:53 PM, Jamil Nimeh wrote:
> Hello all,
> 
> This is a fix that brings the JSSE client from JDK 11+ back in line with 
> the JDK 8 behavior of delivering SSLException on subsequent reads after 
> a handshake has failed due to an alert condition.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8242294
> 
> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8242294/webrev.01
> 
> Thanks,
> 
> --Jamil
> 


From jamil.j.nimeh at oracle.com  Wed Apr  8 00:06:13 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 7 Apr 2020 17:06:13 -0700
Subject: RDR: JDK-8242294 JSSE Client does not throw SSLException when an
 alert occurs during handshaking
In-Reply-To: <f073503b-1ea1-4546-38ff-aa5cf5714fd9@oracle.com>
References: <93b0c7e5-9f29-a6df-4215-d69a4aa190e2@oracle.com>
 <f073503b-1ea1-4546-38ff-aa5cf5714fd9@oracle.com>
Message-ID: <8b922779-946e-85f1-dc87-f206f25b18fe@oracle.com>

Yes, I think you're right.? I'll remove that so it just tests for the 
isInputCloseNotified and rerun the tests just to be sure.

Thanks for the feedback,

--Jamil

On 4/7/20 1:44 PM, Xuelei Fan wrote:
> The conContext.isBroken condition in line 1124 is duplicated, and 
> could be safely removed, I think.? Otherwise, looks good to me.? I 
> don't think there's need for another round of RFR.
>
> Thanks,
> Xuelei
>
> On 4/7/2020 12:53 PM, Jamil Nimeh wrote:
>> Hello all,
>>
>> This is a fix that brings the JSSE client from JDK 11+ back in line 
>> with the JDK 8 behavior of delivering SSLException on subsequent 
>> reads after a handshake has failed due to an alert condition.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242294
>>
>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8242294/webrev.01
>>
>> Thanks,
>>
>> --Jamil
>>


From hai-may.chao at oracle.com  Wed Apr  8 00:46:37 2020
From: hai-may.chao at oracle.com (Hai-May Chao)
Date: Tue, 7 Apr 2020 17:46:37 -0700
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
In-Reply-To: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
References: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
Message-ID: <D7642E64-765C-4485-A587-6FE4DC4CC272@oracle.com>

Hi Max,

Changes look good to me.

Hai-May


> On Apr 6, 2020, at 8:11 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please review the fix at
> 
>   http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
> 
> The major change is inside X509CRLImpl.java to allow params setting and reading.
> 
> I also take this chance to:
> 
> 1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".
> 
> 2. Revert a former change in X509CertImpl.java, which might be a safer call.
> 
> Thanks,
> Max
> 



From xuelei.fan at oracle.com  Wed Apr  8 01:12:55 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 7 Apr 2020 18:12:55 -0700
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
In-Reply-To: <D7642E64-765C-4485-A587-6FE4DC4CC272@oracle.com>
References: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
 <D7642E64-765C-4485-A587-6FE4DC4CC272@oracle.com>
Message-ID: <ad9e4926-58db-42ee-f988-90b2c71ae304@oracle.com>

+1.

Xuelei

On 4/7/2020 5:46 PM, Hai-May Chao wrote:
> Hi Max,
> 
> Changes look good to me.
> 
> Hai-May
> 
> 
>> On Apr 6, 2020, at 8:11 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Please review the fix at
>>
>>    http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
>>
>> The major change is inside X509CRLImpl.java to allow params setting and reading.
>>
>> I also take this chance to:
>>
>> 1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".
>>
>> 2. Revert a former change in X509CertImpl.java, which might be a safer call.
>>
>> Thanks,
>> Max
>>
> 


From hai-may.chao at oracle.com  Wed Apr  8 01:18:09 2020
From: hai-may.chao at oracle.com (Hai-May Chao)
Date: Tue, 7 Apr 2020 18:18:09 -0700
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
Message-ID: <03D6E5C7-906B-48A0-9733-1A9CFDC455EA@oracle.com>

Hi Max,

Changes look good to me.

Is there a man page bug being filed for this?

Thanks,
Hai-May


> On Apr 7, 2020, at 1:04 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
> 
>            JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
> 
> Please review everything at:
> 
>   Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>            CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>         webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
> 
> The CSR "Problem" section has more info on why it's better to remove it now.
> 
> Thanks,
> Max
> 



From xuelei.fan at oracle.com  Wed Apr  8 01:25:39 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 7 Apr 2020 18:25:39 -0700
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <03D6E5C7-906B-48A0-9733-1A9CFDC455EA@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
 <03D6E5C7-906B-48A0-9733-1A9CFDC455EA@oracle.com>
Message-ID: <df66ba4d-dc9f-b500-2dac-21d2b926b59d@oracle.com>

+1.

Xuelei

On 4/7/2020 6:18 PM, Hai-May Chao wrote:
> Hi Max,
> 
> Changes look good to me.
> 
> Is there a man page bug being filed for this?
> 
> Thanks,
> Hai-May
> 
> 
>> On Apr 7, 2020, at 1:04 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>
>>             JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>
>> Please review everything at:
>>
>>    Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>             CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>          webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>
>> The CSR "Problem" section has more info on why it's better to remove it now.
>>
>> Thanks,
>> Max
>>
> 


From weijun.wang at oracle.com  Wed Apr  8 01:41:51 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 8 Apr 2020 09:41:51 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <df66ba4d-dc9f-b500-2dac-21d2b926b59d@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
 <03D6E5C7-906B-48A0-9733-1A9CFDC455EA@oracle.com>
 <df66ba4d-dc9f-b500-2dac-21d2b926b59d@oracle.com>
Message-ID: <42F503BC-482C-4246-AB96-C8BCA07CD0CA@oracle.com>

Can you please add your name as a CSR reviewer?

Thanks,
Max

> On Apr 8, 2020, at 9:25 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> +1.
> 
> Xuelei
> 
> On 4/7/2020 6:18 PM, Hai-May Chao wrote:
>> Hi Max,
>> Changes look good to me.
>> Is there a man page bug being filed for this?
>> Thanks,
>> Hai-May
>>> On Apr 7, 2020, at 1:04 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>> 
>>>            JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>> 
>>> Please review everything at:
>>> 
>>>   Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>            CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>         webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>> 
>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>> 
>>> Thanks,
>>> Max
>>> 



From Xuelei.Fan at Oracle.Com  Wed Apr  8 01:57:41 2020
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Tue, 7 Apr 2020 18:57:41 -0700
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <42F503BC-482C-4246-AB96-C8BCA07CD0CA@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
 <03D6E5C7-906B-48A0-9733-1A9CFDC455EA@oracle.com>
 <df66ba4d-dc9f-b500-2dac-21d2b926b59d@oracle.com>
 <42F503BC-482C-4246-AB96-C8BCA07CD0CA@oracle.com>
Message-ID: <4BDE1BB5-4F88-43F3-8DD1-827DE148E903@Oracle.Com>

I added my name to the CSR.

> On Apr 7, 2020, at 6:41 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Can you please add your name as a CSR reviewer?
> 
> Thanks,
> Max
> 
>> On Apr 8, 2020, at 9:25 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> 
>> +1.
>> 
>> Xuelei
>> 
>>> On 4/7/2020 6:18 PM, Hai-May Chao wrote:
>>> Hi Max,
>>> Changes look good to me.
>>> Is there a man page bug being filed for this?
>>> Thanks,
>>> Hai-May
>>>> On Apr 7, 2020, at 1:04 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>> 
>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>> 
>>>>           JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>> 
>>>> Please review everything at:
>>>> 
>>>>  Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>           CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>        webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>> 
>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>> 
>>>> Thanks,
>>>> Max
>>>> 
> 



From weijun.wang at oracle.com  Wed Apr  8 02:32:15 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 8 Apr 2020 10:32:15 +0800
Subject: RFR 8240848: ArrayIndexOutOfBoundsException buf for
 TextCallbackHandler
In-Reply-To: <DD2A90DB-B32E-4E90-89DB-A81EA8ADE1B5@oracle.com>
References: <DD2A90DB-B32E-4E90-89DB-A81EA8ADE1B5@oracle.com>
Message-ID: <596C7987-F088-4E51-96D8-8085A2856D4C@oracle.com>

I'd removed the change on ConfirmationCallback. Will address it in another fix together with some other similar changes.

Webrev updated in-place. Please take a review.

Thanks,
Max

> On Mar 12, 2020, at 9:21 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please take a review at
> 
>   http://cr.openjdk.java.net/~weijun/8240848/webrev.00/
> 
> The problem is that selection has a different meaning for a specified optionType (the option value) and an unspecified one (the option index).
> 
> I also take this chance to make ConfirmationCallback more robust.
> 
> Thanks,
> Max
> 



From weijun.wang at oracle.com  Wed Apr  8 03:13:04 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 8 Apr 2020 11:13:04 +0800
Subject: RFR[15]: 8172404: Tools should warn if weak algorithms are used
 before restricting them
In-Reply-To: <B63672DC-8070-434E-830C-51F47E79DE81@oracle.com>
References: <1A4115A0-3C12-40A2-A42F-54297E7E233F@oracle.com>
 <B63672DC-8070-434E-830C-51F47E79DE81@oracle.com>
Message-ID: <C2318E76-64D3-48FA-AD88-5A19F8F56AE7@oracle.com>

Everything looks fine, except a very tiny issue:

1332     private String verifyWithWeak(PublicKey key) {
1333         if (DISABLED_CHECK.permits(SIG_PRIMITIVE_SET, key)) {
1334             if (LEGACY_CHECK.permits(SIG_PRIMITIVE_SET, key)) {
1335                 int kLen = KeyUtil.getKeySize(key);
1336                 if (kLen >= 0) {
1337                     return String.format(rb.getString("key.bit"), kLen);
1338                 } else {
1339                     return rb.getString("unknown.size");
1340                 }
1341             } else {
1342                 weakPublicKey = key;
1343                 legacyAlg |= 8;
1344                 return String.format(rb.getString("key.bit.weak"), KeyUtil.getKeySize(key));
1345             }
1346         } else {
1347            disabledAlgFound = true;
1348            return String.format(rb.getString("key.bit.disabled"), KeyUtil.getKeySize(key));
1349         }
1350     }

You can move line 1335 before line 1334 since the size is also used in the else block on lines 1342-1344.

Thanks,
Max

> On Apr 6, 2020, at 12:51 AM, Hai-May Chao <hai-may.chao at oracle.com> wrote:
> 
> Here is the webrev:
> 
> http://cr.openjdk.java.net/~weijun/8172404/webrev.00/
> 
> Thanks,
> Hai-May
> 
> 
>> On Apr 4, 2020, at 11:41 PM, Hai-May Chao <hai-may.chao at oracle.com> wrote:
>> 
>> Hi,
>> 
>> I'd like to request a review for:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172404
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238640
>> 
>> It?d be useful to start warning users that certain algorithms and key lengths are becoming weak, so that users could begin transition away from them before they are actually disabled. A new security property named jdk.security.legacyAlgorithms is added to the java.security file to list the legacy algorithms. The keytool and jarsigner tools are enhanced to enforce the new property and to emit the warning messages when legacy algorithms are used.
>> 
>> Thanks,
>> Hai-May
> 



From valerie.peng at oracle.com  Wed Apr  8 03:46:40 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 7 Apr 2020 20:46:40 -0700
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
In-Reply-To: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
References: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
Message-ID: <79520d02-75b3-fc2e-f2bb-880245d75f3a@oracle.com>

Hi Max,

Not all of the comments are related to the changes in the webrev, just 
notice some PSS related inconsistency and thought I will ask:

<AlgorithmId.java>

- For RSASSA-PSS keys, existing code in 
getDefaultAlgorithmParameterSpec(...) (line 1121) decides the default 
based on key size. I think we should consider checking if the key 
contains PSS parameters. If present, use it as default.

- In the checkKeyAndSigAlgMatch(...) method (line 1027), don't we need 
to add checking for RSASSA-PSS signature? RSASSA-PSS sig can take both 
RSA and RSASSA-PSS keys.

- The getEncAlgFromSigAlg(...) method just returns the key algorithm as 
result when the specified signature algorithm does not contain "with". 
As RSASSA-PSS signature can use both RSASSA-PSS and RSA keys, should it 
still return key algorithm?

- The makeSigAlg(...) method does not work for RSASSA-PSS.

<X509CRLImpl.java>

- The sign() methods of X509CertImpl class do not generate default 
parameters automatically. Have you considered adding a sign() method to 
X509CRLImpl class which has extra signature parameter spec argument and 
move the default parameter call to the caller instead of inside 
X509CRLImpl? I think it's more suitable for the caller to generate the 
default unless there are many callers all need the same functionality.

Thanks,

Valerie

On 4/6/2020 8:11 PM, Weijun Wang wrote:
> Please review the fix at
>
>     http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
>
> The major change is inside X509CRLImpl.java to allow params setting and reading.
>
> I also take this chance to:
>
> 1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".
>
> 2. Revert a former change in X509CertImpl.java, which might be a safer call.
>
> Thanks,
> Max
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200407/2a3feef6/attachment.htm>

From mbalao at redhat.com  Wed Apr  8 03:51:35 2020
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 8 Apr 2020 00:51:35 -0300
Subject: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property
 with a security one
In-Reply-To: <de28a7b9-5967-9241-8bea-4edcc5103deb@redhat.com>
References: <74433961-0fb3-c388-9906-fc3bcf5a9a23@redhat.com>
 <63bb7e08-0883-b610-0fc7-9ed9bc3a1a99@oracle.com>
 <2730a678-652a-af29-285d-ce25220e4089@redhat.com>
 <7ba2a5ff-f675-55ce-63a4-9004df332fba@oracle.com>
 <de28a7b9-5967-9241-8bea-4edcc5103deb@redhat.com>
Message-ID: <068f6300-e105-79b0-26aa-087982b73d45@redhat.com>

Hi Sean,

On 4/2/20 6:23 PM, Martin Balao wrote:
> Webrev.02:
> 
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.02
> 
> On 4/2/20 5:02 PM, Sean Mullan wrote:
>>
>> In the java.security file might add the sentence "The default value of
>> the property is "false"" just to avoid any confusion.
>>
> 
> Added.

Am I clear to push Webrev.02? CSR has been approved today [1].

Thanks,
Martin.-

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



From weijun.wang at oracle.com  Wed Apr  8 04:04:30 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 8 Apr 2020 12:04:30 +0800
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
In-Reply-To: <79520d02-75b3-fc2e-f2bb-880245d75f3a@oracle.com>
References: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
 <79520d02-75b3-fc2e-f2bb-880245d75f3a@oracle.com>
Message-ID: <FC326B36-45BE-4499-A26A-AC0A95CCB297@oracle.com>



> On Apr 8, 2020, at 11:46 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Hi Max,
> 
> Not all of the comments are related to the changes in the webrev, just notice some PSS related inconsistency and thought I will ask:
> 
> <AlgorithmId.java>
> 
> - For RSASSA-PSS keys, existing code in getDefaultAlgorithmParameterSpec(...) (line 1121) decides the default based on key size. I think we should consider checking if the key contains PSS parameters. If present, use it as default.

Correct.

> 
> - In the checkKeyAndSigAlgMatch(...) method (line 1027), don't we need to add checking for RSASSA-PSS signature? RSASSA-PSS sig can take both RSA and RSASSA-PSS keys.
> 
> - The getEncAlgFromSigAlg(...) method just returns the key algorithm as result when the specified signature algorithm does not contain "with". As RSASSA-PSS signature can use both RSASSA-PSS and RSA keys, should it still return key algorithm?
> 
> - The makeSigAlg(...) method does not work for RSASSA-PSS. 

These are for JAR file signing. The support for RSASSA-PSS is very poor in this area. I am thinking about fixing these in "8242068: Signed JAR support for RSASSA-PSS and EdDSA".

> 
> <X509CRLImpl.java>
> 
> - The sign() methods of X509CertImpl class do not generate default parameters automatically. Have you considered adding a sign() method to X509CRLImpl class which has extra signature       parameter spec argument and move the default parameter call to the caller instead of inside X509CRLImpl? I think it's more suitable for the caller to generate the default unless there are many callers all need the same functionality.

But this X509CertImpl method is not used anywhere. If only for JDK internal use, I'd rather sacrifice this flexibility and introduce a method like

    public static Signature fromKey(String sigAlg, Key Privatekey, String provider)
            throws NoSuchAlgorithmException, NoSuchProviderException,
                   InvalidKeyException{
        Signature sigEngine = (provider == null || provider.isEmpty())
                ? Signature.getInstance(sigAlg)
                : Signature.getInstance(sigAlg, provider);
        AlgorithmParameterSpec params = SignatureUtil
                .getDefaultAlgorithmParameterSpec(sigAlg, key);
        try {
            SignatureUtil.initSignWithParam(sigEngine, key, params,
                    null);
        } catch (InvalidAlgorithmParameterException e) {
            throw new AssertionError("getDefaultAlgorithmParameterSpec", e);
        }
        return s;
    }

There are quite some places that need this pattern. If necessary later, we can add a nullable AlgorithmParameterSpec argument.

Thanks,
Max

> 
> Thanks,
> 
> Valerie
> 
> On 4/6/2020 8:11 PM, Weijun Wang wrote:
>> Please review the fix at
>> 
>>    
>> http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
>> 
>> 
>> The major change is inside X509CRLImpl.java to allow params setting and reading.
>> 
>> I also take this chance to:
>> 
>> 1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".
>> 
>> 2. Revert a former change in X509CertImpl.java, which might be a safer call.
>> 
>> Thanks,
>> Max
>> 
>> 



From hai-may.chao at oracle.com  Wed Apr  8 06:18:32 2020
From: hai-may.chao at oracle.com (Hai-May Chao)
Date: Tue, 7 Apr 2020 23:18:32 -0700
Subject: RFR[15]: 8172404: Tools should warn if weak algorithms are used
 before restricting them
In-Reply-To: <C2318E76-64D3-48FA-AD88-5A19F8F56AE7@oracle.com>
References: <1A4115A0-3C12-40A2-A42F-54297E7E233F@oracle.com>
 <B63672DC-8070-434E-830C-51F47E79DE81@oracle.com>
 <C2318E76-64D3-48FA-AD88-5A19F8F56AE7@oracle.com>
Message-ID: <D6FD631C-FCC6-426C-84A3-BB4C1FCA15E0@oracle.com>

Hi Max,

Thanks for your review.
I?ve updated webrev with your comment.

Hai-May


> On Apr 7, 2020, at 8:13 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Everything looks fine, except a very tiny issue:
> 
> 1332     private String verifyWithWeak(PublicKey key) {
> 1333         if (DISABLED_CHECK.permits(SIG_PRIMITIVE_SET, key)) {
> 1334             if (LEGACY_CHECK.permits(SIG_PRIMITIVE_SET, key)) {
> 1335                 int kLen = KeyUtil.getKeySize(key);
> 1336                 if (kLen >= 0) {
> 1337                     return String.format(rb.getString("key.bit"), kLen);
> 1338                 } else {
> 1339                     return rb.getString("unknown.size");
> 1340                 }
> 1341             } else {
> 1342                 weakPublicKey = key;
> 1343                 legacyAlg |= 8;
> 1344                 return String.format(rb.getString("key.bit.weak"), KeyUtil.getKeySize(key));
> 1345             }
> 1346         } else {
> 1347            disabledAlgFound = true;
> 1348            return String.format(rb.getString("key.bit.disabled"), KeyUtil.getKeySize(key));
> 1349         }
> 1350     }
> 
> You can move line 1335 before line 1334 since the size is also used in the else block on lines 1342-1344.
> 
> Thanks,
> Max
> 
>> On Apr 6, 2020, at 12:51 AM, Hai-May Chao <hai-may.chao at oracle.com> wrote:
>> 
>> Here is the webrev:
>> 
>> http://cr.openjdk.java.net/~weijun/8172404/webrev.00/
>> 
>> Thanks,
>> Hai-May
>> 
>> 
>>> On Apr 4, 2020, at 11:41 PM, Hai-May Chao <hai-may.chao at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I'd like to request a review for:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172404
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8238640
>>> 
>>> It?d be useful to start warning users that certain algorithms and key lengths are becoming weak, so that users could begin transition away from them before they are actually disabled. A new security property named jdk.security.legacyAlgorithms is added to the java.security file to list the legacy algorithms. The keytool and jarsigner tools are enhanced to enforce the new property and to emit the warning messages when legacy algorithms are used.
>>> 
>>> Thanks,
>>> Hai-May
>> 
> 



From rahul.r.yadav at oracle.com  Wed Apr  8 09:13:44 2020
From: rahul.r.yadav at oracle.com (Rahul)
Date: Wed, 08 Apr 2020 10:13:44 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
Message-ID: <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>

Updated patch after considering the impact of returning default parameters on the http client.
TLS versions earlier limited to 1.2 and above by client, now will support all versions(wrt the scenarios for this bug).
    
    Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
    Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
    
    Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.01/
    
    -- Rahul

?On 27/03/2020, 16:23, "net-dev on behalf of Xuelei Fan" <net-dev-bounces at openjdk.java.net on behalf of xuelei.fan at oracle.com> wrote:

    On 3/27/2020 5:52 AM, Chris Hegarty wrote:
    > Xuelei,
    > 
    > Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property.
    > 
    > Is there a specification or other documentation describing `jdk.tls.client.protocols` ?
    > 
    See the jdk.tls.client.protocols line in table 'Table 8-3 System 
    Properties and Customized Items" in JSSE Reference Guides:
    
    "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9
    
    For your quick reference, I copied the note here:
    
    ---------------
    Customized Item:
    Default handshaking protocols for TLS/DTLS clients.
    
    Notes:
    To enable specific SunJSSE protocols on the client, specify them in a 
    comma-separated list within quotation marks; all other supported 
    protocols are not enabled on the client
    For example,
    
         If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default 
    protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while 
    SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled
    
         If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting 
    on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled
    ---------------
    
    
    > It is my understanding that the property only affects the *default* protocol?s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default?)`,
    It is correct that the property impact the default SSLContext only.  The 
    default SSLContext instance could get from:
         SSLContext.getInstance("Default");
         SSLContext.getInstance("TLS");
         SSLContext.getInstance("DTLS");
    
    
    > and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do?
    Yes.
    
    Xuelei
    
    > -Chris.
    > 
    >> On 26 Mar 2020, at 16:58, Xuelei Fan <xuelei.fan at oracle.com> wrote:
    >>
    >> With this update, the logic looks like: if TLSv1.3 is not enabled in the SSLContext, use TLSv1.2 instead;  Otherwise, use TLSv1.3 and TLSv1.2.
    >>
    >> There may be a couple of issues:
    >> 1. TLSv1.2 may be not enabled, although TLSv1.3 is enabled.
    >> For example:
    >>    System.setProperty("jdk.tls.client.protocols", "TLSv1.3")
    >>    System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
    >>
    >> 2. TLSv1.2 may be not supported in the SSLContext.
    >> For example:
    >>    SSLContext context = SSLContext.getInstance("DTLS");
    >>    HttpClient.newBuilder().sslContext(context)...
    >>
    >> 3. The application may not want to use TLS 1.2.
    >> For example:
    >>    System.setProperty("jdk.tls.client.protocols", "TLSv1.1, TLSv1.0")
    >>
    >> The System property may be shared by code other than httpclient.  So the setting may not consider the impact on httpclient.
    >>
    >> I may use enabled protocols only. If no TLSv1.2/TLSv1.3, I may use an empty protocol array, and test to see what happens in the httpclient implementation stack.
    >>
    >> Xuelei
    >>
    >> On 3/26/2020 9:28 AM, Sean Mullan wrote:
    >>> Cross-posting to security-dev as this involves TLS/SSL configuration.
    >>> --Sean
    >>> On 3/26/20 10:02 AM, rahul.r.yadav at oracle.com wrote:
    >>>> Hello,
    >>>>
    >>>> Request to have my fix reviewed for issues:
    >>>>
    >>>>       JDK-8239595 : ssl context version is not respected
    >>>>       JDK-8239594 : jdk.tls.client.protocols is not respected
    >>>>
    >>>> The fix updates jdk.internal.net.http.HttpClientImpl.getDefaultParams(SSLContext ctx)
    >>>> to use ctx.getDefaultSSLParameters()instead of ctx.getSupportedSSLParameters(),
    >>>> as the latter does not respect the context parameters set by the user.
    >>>>
    >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
    >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
    >>>>
    >>>> Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.00/
    >>>>
    >>>> -- Rahul
    > 
    




From chris.hegarty at oracle.com  Wed Apr  8 10:00:08 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 8 Apr 2020 11:00:08 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
Message-ID: <62C88803-0F74-46D3-ADE0-84A69B3B0CC7@oracle.com>



> On 8 Apr 2020, at 10:13, Rahul <rahul.r.yadav at oracle.com> wrote:
> 
> Updated patch after considering the impact of returning default parameters on the http client.
> TLS versions earlier limited to 1.2 and above by client, now will support all versions(wrt the scenarios for this bug).
> 
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8239595
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8239594
> 
>    Webrev: http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.01/

Thanks for persevering with this. The changes and test look good to me.

-Chris.

From sean.mullan at oracle.com  Wed Apr  8 12:32:51 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Apr 2020 08:32:51 -0400
Subject: RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property
 with a security one
In-Reply-To: <068f6300-e105-79b0-26aa-087982b73d45@redhat.com>
References: <74433961-0fb3-c388-9906-fc3bcf5a9a23@redhat.com>
 <63bb7e08-0883-b610-0fc7-9ed9bc3a1a99@oracle.com>
 <2730a678-652a-af29-285d-ce25220e4089@redhat.com>
 <7ba2a5ff-f675-55ce-63a4-9004df332fba@oracle.com>
 <de28a7b9-5967-9241-8bea-4edcc5103deb@redhat.com>
 <068f6300-e105-79b0-26aa-087982b73d45@redhat.com>
Message-ID: <0298aa1e-7b33-0810-efb9-88d257564839@oracle.com>

On 4/7/20 11:51 PM, Martin Balao wrote:
> Hi Sean,
> 
> On 4/2/20 6:23 PM, Martin Balao wrote:
>> Webrev.02:
>>
>>   * http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.02
>>
>> On 4/2/20 5:02 PM, Sean Mullan wrote:
>>>
>>> In the java.security file might add the sentence "The default value of
>>> the property is "false"" just to avoid any confusion.
>>>
>>
>> Added.
> 
> Am I clear to push Webrev.02? CSR has been approved today [1].

Yes, go ahead.

--Sean

> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8241893
> 


From sean.mullan at oracle.com  Wed Apr  8 12:41:16 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Apr 2020 08:41:16 -0400
Subject: RFR 8240848: ArrayIndexOutOfBoundsException buf for
 TextCallbackHandler
In-Reply-To: <596C7987-F088-4E51-96D8-8085A2856D4C@oracle.com>
References: <DD2A90DB-B32E-4E90-89DB-A81EA8ADE1B5@oracle.com>
 <596C7987-F088-4E51-96D8-8085A2856D4C@oracle.com>
Message-ID: <1c754146-15c1-979e-9271-38741f768a99@oracle.com>

On 4/7/20 10:32 PM, Weijun Wang wrote:
> I'd removed the change on ConfirmationCallback. Will address it in another fix together with some other similar changes.
> 
> Webrev updated in-place. Please take a review.

Looks good.

--Sean

> 
> Thanks,
> Max
> 
>> On Mar 12, 2020, at 9:21 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Please take a review at
>>
>>    http://cr.openjdk.java.net/~weijun/8240848/webrev.00/
>>
>> The problem is that selection has a different meaning for a specified optionType (the option value) and an unspecified one (the option index).
>>
>> I also take this chance to make ConfirmationCallback more robust.
>>
>> Thanks,
>> Max
>>
> 


From david.holmes at oracle.com  Wed Apr  8 12:56:06 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 8 Apr 2020 22:56:06 +1000
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
Message-ID: <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>

Hi Pavel,

Not a review ...

On 8/04/2020 9:50 pm, Pavel Rappo wrote:
> Vipin, here you go:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8242366
>      http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
> 
> I took the liberty of additionally fixing a couple of parameters' names,
> a typo, and `@exception` tags for checked exceptions that were neither thrown
> nor imported.

While you are in there is it worth changing @exception to @throws? (I 
didn't look to see how big that change would be.)

Cheers,
David

> The bulk of the change is in Security. Some changes are in Networking. The
> appropriate mailing lists are in CC for this email. We should wait for their
> feedback.
> 
> Changes in core area look good to me and I'd be surprised if there are any
> problems with the remaining portion of the changeset.
> 
> -Pavel
> 
>> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>
>> Hi Pavel,
>>
>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>
>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
>> Yes I have signed OCA.
>>>
>>> -Pavel
>>>
>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>>> [2] changeset:   58344:65f30e209890
>>> user:        clanger
>>> date:        Wed Mar 11 13:50:13 2020 +0100
>>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>>> description:
>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>>> Reviewed-by: clanger, vtewari
>>> Contributed-by: vipinsharma85 at gmail.com
>>>
>> Yes this is my first contribution.
>>
>> Patch text:
>>
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -202,7 +202,7 @@
>>      /**
>>       * Sets the padding mechanism of this cipher.
>>       *
>> -     * @param padding the padding mechanism
>> +     * @param paddingScheme the padding mechanism
>>       *
>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>       * does not exist
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -313,10 +313,10 @@
>>       * current Cipher.engineInit(...) implementation,
>>       * IllegalStateException will always be thrown upon invocation.
>>       *
>> -     * @param in the input buffer
>> -     * @param inOffset the offset in <code>in</code> where the input
>> +     * @param input the input buffer
>> +     * @param inputOffset the offset in <code>in</code> where the input
>>       * starts
>> -     * @param inLen the input length.
>> +     * @param inputLen the input length.
>>       *
>>       * @return n/a.
>>       *
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -130,7 +130,6 @@
>>       *
>>       * @param plain the buffer with the input data to be encrypted
>>       * @param plainOffset the offset in <code>plain</code>
>> -     * @param plainLen the length of the input data
>>       * @param cipher the buffer for the result
>>       * @param cipherOffset the offset in <code>cipher</code>
>>       */
>> @@ -154,7 +153,6 @@
>>       *
>>       * @param cipher the buffer with the input data to be decrypted
>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>> -     * @param cipherLen the length of the input data
>>       * @param plain the buffer for the result
>>       * @param plainOffset the offset in <code>plain</code>
>>       */
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -552,7 +552,6 @@
>>       *
>>       * @param plain the buffer with the input data to be encrypted
>>       * @param plainOffset the offset in <code>plain</code>
>> -     * @param plainLen the length of the input data
>>       * @param cipher the buffer for the result
>>       * @param cipherOffset the offset in <code>cipher</code>
>>       *
>> @@ -579,7 +578,6 @@
>>       *
>>       * @param cipher the buffer with the input data to be decrypted
>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>> -     * @param cipherLen the length of the input data
>>       * @param plain the buffer for the result
>>       * @param plainOffset the offset in <code>plain</code>
>>       *
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -262,8 +262,6 @@
>>       * @param algorithm the algorithm name
>>       * @param key the key
>>       * @param iv the iv
>> -     * @param tagLenBytes the length of tag in bytes
>> -     *
>>       * @exception InvalidKeyException if the given key is inappropriate for
>>       * initializing this cipher
>>       */
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -225,7 +225,7 @@
>>       *
>>       * @param key the key
>>       *
>> -     * @param keySpec the requested format in which the key material shall be
>> +     * @param keySpecCl the requested format in which the key material shall be
>>       * returned
>>       *
>>       * @return the underlying key specification (key material) in the
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
>> @@ -92,7 +92,7 @@
>>       * Sets the padding mechanism of this cipher. This algorithm only uses
>>       * PKCS #5 padding.
>>       *
>> -     * @param padding the padding mechanism
>> +     * @param paddingScheme the padding mechanism
>>       *
>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>       * is invalid
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -75,7 +75,7 @@
>>       *
>>       * @param key the key
>>       *
>> -     * @param keySpec the requested format in which the key material shall be
>> +     * @param keySpecCl the requested format in which the key material shall be
>>       * returned
>>       *
>>       * @return the underlying key specification (key material) in the
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -49,7 +49,7 @@
>>       * interface.
>>       *
>>       * @param in the input buffer with the data to pad
>> -     * @param the offset in <code>in</code> where the padding bytes
>> +     * @param off the offset in <code>in</code> where the padding bytes
>>       *  are appended
>>       * @param len the number of padding bytes to add
>>       *
>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
>> @@ -1077,7 +1077,7 @@
>>       * Start a new Process using an explicit array of redirects.
>>       * See {@link #start} for details of starting each Process.
>>       *
>> -     * @param redirect array of redirects for stdin, stdout, stderr
>> +     * @param redirects array of redirects for stdin, stdout, stderr
>>       * @return the new Process
>>       * @throws IOException if an I/O error occurs
>>       */
>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
>> @@ -731,7 +731,7 @@
>>       * Constructs an empty GregorianCalendar.
>>       *
>>       * @param zone    the given time zone
>> -     * @param aLocale the given locale
>> +     * @param locale the given locale
>>       * @param flag    the flag requesting an empty instance
>>       */
>>      GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -316,7 +316,7 @@
>>       * If the address already has a scope-id or if the address is not local, ipv6
>>       * or link local, then the original address is returned.
>>       *
>> -     * @param addr
>> +     * @param address
>>       * @exception SocketException if the given ipv6 link local address is found
>>       *            on more than one local interface
>>       * @return
>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -208,7 +208,7 @@
>>       * Use New to get new HttpsClient. This constructor is meant to be
>>       * used only by New method. New properly checks for URL spoofing.
>>       *
>> -     * @param URL https URL with which a connection must be established
>> +     * @param url https URL with which a connection must be established
>>       */
>>      private HttpsClient(SSLSocketFactory sf, URL url)
>>      throws IOException
>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
>> @@ -321,7 +321,7 @@
>>          /**
>>           * Loads the provider with the specified class name.
>>           *
>> -         * @param name the name of the provider
>> +         * @param pn the name of the provider
>>           * @return the Provider, or null if it cannot be found or loaded
>>           * @throws ProviderException all other exceptions are ignored
>>           */
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -72,7 +72,7 @@
>>       * Constructor that initializes the input parameters.
>>       *
>>       * @param anchor the anchor selected to validate the target certificate
>> -     * @param testDate the time for which the validity of the certificate
>> +     * @param date the time for which the validity of the certificate
>>       *        should be determined
>>       * @param sigProvider the name of the signature provider
>>       * @param sigOnly true if only signature checking is to be done;
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -69,7 +69,7 @@
>>      /**
>>       * Initialize the builder with the input parameters.
>>       *
>> -     * @param params the parameter set used to build a certification path
>> +     * @param buildParams the parameter set used to build a certification path
>>       */
>>      Builder(BuilderParams buildParams) {
>>          this.buildParams = buildParams;
>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -111,7 +111,7 @@
>>       * @param ruleFile       the name of the rule data file
>>       * @param ruleData       the rule data loaded from the rule data file
>>       * @param dictionaryFile the name of the dictionary file
>> -     * @param dictionartData the dictionary data loaded from the dictionary file
>> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>>       * @throws MissingResourceException if rule data or dictionary initialization failed
>>       */
>>      public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
>>
>>
>>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>
>>>> Hi David,
>>>>
>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>>> Please suggest if there is any way I can create my user id to upload this patch.
>>>>
>>>> This is ~300 line patch file.
>>>>
>>>> Regards,
>>>> Vipin
>>>>
>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>
>>>>> Hi Vipin,
>>>>>
>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>>> Hi,
>>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>>> code and Javadoc, need a sponsor for this patch.
>>>>>> Webrev is available at
>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>>>
>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Regards,
>>>>>> Vipin
>>>>
>>>
>> Thanks,
>> Vipin
> 


From daniel.fuchs at oracle.com  Wed Apr  8 13:07:56 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Apr 2020 14:07:56 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
Message-ID: <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>

Hi Pavel,

On 08/04/2020 13:56, David Holmes wrote:
> and `@exception` tags for checked exceptions that were neither thrown
> nor imported

Hopefully that's only on internal classes.
It might be prudent to separate this out in a different
changeset. It's not always obvious where an exception
is thrown.

best regards,

-- daniel


From sean.mullan at oracle.com  Wed Apr  8 13:10:28 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Apr 2020 09:10:28 -0400
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
Message-ID: <d8fd78aa-3250-5a71-cc8c-6723f5cd30ba@oracle.com>

The security changes look fine to me.

--Sean

On 4/8/20 7:50 AM, Pavel Rappo wrote:
> Vipin, here you go:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8242366
>      http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
> 
> I took the liberty of additionally fixing a couple of parameters' names,
> a typo, and `@exception` tags for checked exceptions that were neither thrown
> nor imported.
> 
> The bulk of the change is in Security. Some changes are in Networking. The
> appropriate mailing lists are in CC for this email. We should wait for their
> feedback.
> 
> Changes in core area look good to me and I'd be surprised if there are any
> problems with the remaining portion of the changeset.
> 
> -Pavel
> 
>> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>
>> Hi Pavel,
>>
>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>
>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
>> Yes I have signed OCA.
>>>
>>> -Pavel
>>>
>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>>> [2] changeset:   58344:65f30e209890
>>> user:        clanger
>>> date:        Wed Mar 11 13:50:13 2020 +0100
>>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>>> description:
>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>>> Reviewed-by: clanger, vtewari
>>> Contributed-by: vipinsharma85 at gmail.com
>>>
>> Yes this is my first contribution.
>>
>> Patch text:
>>
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -202,7 +202,7 @@
>>      /**
>>       * Sets the padding mechanism of this cipher.
>>       *
>> -     * @param padding the padding mechanism
>> +     * @param paddingScheme the padding mechanism
>>       *
>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>       * does not exist
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -313,10 +313,10 @@
>>       * current Cipher.engineInit(...) implementation,
>>       * IllegalStateException will always be thrown upon invocation.
>>       *
>> -     * @param in the input buffer
>> -     * @param inOffset the offset in <code>in</code> where the input
>> +     * @param input the input buffer
>> +     * @param inputOffset the offset in <code>in</code> where the input
>>       * starts
>> -     * @param inLen the input length.
>> +     * @param inputLen the input length.
>>       *
>>       * @return n/a.
>>       *
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -130,7 +130,6 @@
>>       *
>>       * @param plain the buffer with the input data to be encrypted
>>       * @param plainOffset the offset in <code>plain</code>
>> -     * @param plainLen the length of the input data
>>       * @param cipher the buffer for the result
>>       * @param cipherOffset the offset in <code>cipher</code>
>>       */
>> @@ -154,7 +153,6 @@
>>       *
>>       * @param cipher the buffer with the input data to be decrypted
>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>> -     * @param cipherLen the length of the input data
>>       * @param plain the buffer for the result
>>       * @param plainOffset the offset in <code>plain</code>
>>       */
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -552,7 +552,6 @@
>>       *
>>       * @param plain the buffer with the input data to be encrypted
>>       * @param plainOffset the offset in <code>plain</code>
>> -     * @param plainLen the length of the input data
>>       * @param cipher the buffer for the result
>>       * @param cipherOffset the offset in <code>cipher</code>
>>       *
>> @@ -579,7 +578,6 @@
>>       *
>>       * @param cipher the buffer with the input data to be decrypted
>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>> -     * @param cipherLen the length of the input data
>>       * @param plain the buffer for the result
>>       * @param plainOffset the offset in <code>plain</code>
>>       *
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -262,8 +262,6 @@
>>       * @param algorithm the algorithm name
>>       * @param key the key
>>       * @param iv the iv
>> -     * @param tagLenBytes the length of tag in bytes
>> -     *
>>       * @exception InvalidKeyException if the given key is inappropriate for
>>       * initializing this cipher
>>       */
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -225,7 +225,7 @@
>>       *
>>       * @param key the key
>>       *
>> -     * @param keySpec the requested format in which the key material shall be
>> +     * @param keySpecCl the requested format in which the key material shall be
>>       * returned
>>       *
>>       * @return the underlying key specification (key material) in the
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
>> @@ -92,7 +92,7 @@
>>       * Sets the padding mechanism of this cipher. This algorithm only uses
>>       * PKCS #5 padding.
>>       *
>> -     * @param padding the padding mechanism
>> +     * @param paddingScheme the padding mechanism
>>       *
>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>       * is invalid
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -75,7 +75,7 @@
>>       *
>>       * @param key the key
>>       *
>> -     * @param keySpec the requested format in which the key material shall be
>> +     * @param keySpecCl the requested format in which the key material shall be
>>       * returned
>>       *
>>       * @return the underlying key specification (key material) in the
>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -49,7 +49,7 @@
>>       * interface.
>>       *
>>       * @param in the input buffer with the data to pad
>> -     * @param the offset in <code>in</code> where the padding bytes
>> +     * @param off the offset in <code>in</code> where the padding bytes
>>       *  are appended
>>       * @param len the number of padding bytes to add
>>       *
>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
>> @@ -1077,7 +1077,7 @@
>>       * Start a new Process using an explicit array of redirects.
>>       * See {@link #start} for details of starting each Process.
>>       *
>> -     * @param redirect array of redirects for stdin, stdout, stderr
>> +     * @param redirects array of redirects for stdin, stdout, stderr
>>       * @return the new Process
>>       * @throws IOException if an I/O error occurs
>>       */
>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
>> @@ -731,7 +731,7 @@
>>       * Constructs an empty GregorianCalendar.
>>       *
>>       * @param zone    the given time zone
>> -     * @param aLocale the given locale
>> +     * @param locale the given locale
>>       * @param flag    the flag requesting an empty instance
>>       */
>>      GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -316,7 +316,7 @@
>>       * If the address already has a scope-id or if the address is not local, ipv6
>>       * or link local, then the original address is returned.
>>       *
>> -     * @param addr
>> +     * @param address
>>       * @exception SocketException if the given ipv6 link local address is found
>>       *            on more than one local interface
>>       * @return
>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -208,7 +208,7 @@
>>       * Use New to get new HttpsClient. This constructor is meant to be
>>       * used only by New method. New properly checks for URL spoofing.
>>       *
>> -     * @param URL https URL with which a connection must be established
>> +     * @param url https URL with which a connection must be established
>>       */
>>      private HttpsClient(SSLSocketFactory sf, URL url)
>>      throws IOException
>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
>> @@ -321,7 +321,7 @@
>>          /**
>>           * Loads the provider with the specified class name.
>>           *
>> -         * @param name the name of the provider
>> +         * @param pn the name of the provider
>>           * @return the Provider, or null if it cannot be found or loaded
>>           * @throws ProviderException all other exceptions are ignored
>>           */
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -72,7 +72,7 @@
>>       * Constructor that initializes the input parameters.
>>       *
>>       * @param anchor the anchor selected to validate the target certificate
>> -     * @param testDate the time for which the validity of the certificate
>> +     * @param date the time for which the validity of the certificate
>>       *        should be determined
>>       * @param sigProvider the name of the signature provider
>>       * @param sigOnly true if only signature checking is to be done;
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -69,7 +69,7 @@
>>      /**
>>       * Initialize the builder with the input parameters.
>>       *
>> -     * @param params the parameter set used to build a certification path
>> +     * @param buildParams the parameter set used to build a certification path
>>       */
>>      Builder(BuilderParams buildParams) {
>>          this.buildParams = buildParams;
>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -111,7 +111,7 @@
>>       * @param ruleFile       the name of the rule data file
>>       * @param ruleData       the rule data loaded from the rule data file
>>       * @param dictionaryFile the name of the dictionary file
>> -     * @param dictionartData the dictionary data loaded from the dictionary file
>> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>>       * @throws MissingResourceException if rule data or dictionary initialization failed
>>       */
>>      public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
>>
>>
>>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>
>>>> Hi David,
>>>>
>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>>> Please suggest if there is any way I can create my user id to upload this patch.
>>>>
>>>> This is ~300 line patch file.
>>>>
>>>> Regards,
>>>> Vipin
>>>>
>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>
>>>>> Hi Vipin,
>>>>>
>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>>> Hi,
>>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>>> code and Javadoc, need a sponsor for this patch.
>>>>>> Webrev is available at
>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>>>
>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> Regards,
>>>>>> Vipin
>>>>
>>>
>> Thanks,
>> Vipin
> 


From Alan.Bateman at oracle.com  Wed Apr  8 13:14:51 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 8 Apr 2020 14:14:51 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
Message-ID: <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>

On 08/04/2020 14:07, Daniel Fuchs wrote:
> Hi Pavel,
>
> On 08/04/2020 13:56, David Holmes wrote:
>> and `@exception` tags for checked exceptions that were neither thrown
>> nor imported
>
> Hopefully that's only on internal classes.
 From a quick scan, the changes are to internal classes and a few 
non-public elements of public API classes. So I don't think anything 
should impact the javadoc. I'm guessing this patch is motivated by 
something creating that is running the javadoc tool with different 
options to what the "docs" target uses.

-Alan


From daniel.fuchs at oracle.com  Wed Apr  8 14:37:14 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Apr 2020 15:37:14 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
Message-ID: <3189b9da-c9e7-dae5-6869-b130783d7884@oracle.com>

On 08/04/2020 12:50, Pavel Rappo wrote:
> Vipin, here you go:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8242366
>      http://cr.openjdk.java.net/~prappo/8242366/webrev.00/

Hi Pavel,

That looks good to me.
WRT to the @exception changes I'll leave that responsibility
to Sean ;-)

best regards,

-- daniel


> 
> I took the liberty of additionally fixing a couple of parameters' names,
> a typo, and `@exception` tags for checked exceptions that were neither thrown
> nor imported.



From daniel.fuchs at oracle.com  Wed Apr  8 15:00:37 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 8 Apr 2020 16:00:37 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
Message-ID: <13bea5bd-9fbe-adb6-6d9a-6bd4e519a02f@oracle.com>

Good work Rahul!

I am not sure whether that deserves a CSR (probably not) but we may
want to create some release note to explain that the HttpClient is no
longer overriding the default protocols selected by the SSLContext.

So HTTP 1.1 over TLSv1.1 might now get negotiated where previously
an handshake failure would have occurred. It might be worth mentioning
in a release note.

best regards,

-- daniel

On 08/04/2020 10:13, Rahul wrote:
> Updated patch after considering the impact of returning default parameters on the http client.
> TLS versions earlier limited to 1.2 and above by client, now will support all versions(wrt the scenarios for this bug).
>      
>      Issue:https://bugs.openjdk.java.net/browse/JDK-8239595
>      Issue:https://bugs.openjdk.java.net/browse/JDK-8239594
>      
>      Webrev:http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.01/
>      
>      -- Rahul



From pavel.rappo at oracle.com  Wed Apr  8 13:23:40 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 Apr 2020 14:23:40 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
Message-ID: <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com>

Hey David,

Where exactly? In the files affected by this changeset? If so, then we will
introduce inconsistency. Otherwise it's a huge change. From what I can see there
are some 250 occurrences of `@exception` in src/java.base/share/classes/com/sun/{crypto, security}
and some 7,300 in src.

Personally, out of all tag renovations, changing `@exception` to `@throws`
probably gives the least bang for the buck. If nothing else, it gives you 3
extra characters on the same line to fill with something more useful.
I would be more inclined to change `<code>...</code>` to `{@code ...}`, but
given how error-prone that can be, I still wouldn't do it in this changeset.

-Pavel

> On 8 Apr 2020, at 13:56, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Pavel,
> 
> Not a review ...
> 
> On 8/04/2020 9:50 pm, Pavel Rappo wrote:
>> Vipin, here you go:
>>     https://bugs.openjdk.java.net/browse/JDK-8242366
>>     http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
>> I took the liberty of additionally fixing a couple of parameters' names,
>> a typo, and `@exception` tags for checked exceptions that were neither thrown
>> nor imported.
> 
> While you are in there is it worth changing @exception to @throws? (I didn't look to see how big that change would be.)
> 
> Cheers,
> David
> 
>> The bulk of the change is in Security. Some changes are in Networking. The
>> appropriate mailing lists are in CC for this email. We should wait for their
>> feedback.
>> Changes in core area look good to me and I'd be surprised if there are any
>> problems with the remaining portion of the changeset.
>> -Pavel
>>> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> Hi Pavel,
>>> 
>>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
>>> Yes I have signed OCA.
>>>> 
>>>> -Pavel
>>>> 
>>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>>>> [2] changeset:   58344:65f30e209890
>>>> user:        clanger
>>>> date:        Wed Mar 11 13:50:13 2020 +0100
>>>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>>>> description:
>>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>>>> Reviewed-by: clanger, vtewari
>>>> Contributed-by: vipinsharma85 at gmail.com
>>>> 
>>> Yes this is my first contribution.
>>> 
>>> Patch text:
>>> 
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -202,7 +202,7 @@
>>>     /**
>>>      * Sets the padding mechanism of this cipher.
>>>      *
>>> -     * @param padding the padding mechanism
>>> +     * @param paddingScheme the padding mechanism
>>>      *
>>>      * @exception NoSuchPaddingException if the requested padding mechanism
>>>      * does not exist
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -313,10 +313,10 @@
>>>      * current Cipher.engineInit(...) implementation,
>>>      * IllegalStateException will always be thrown upon invocation.
>>>      *
>>> -     * @param in the input buffer
>>> -     * @param inOffset the offset in <code>in</code> where the input
>>> +     * @param input the input buffer
>>> +     * @param inputOffset the offset in <code>in</code> where the input
>>>      * starts
>>> -     * @param inLen the input length.
>>> +     * @param inputLen the input length.
>>>      *
>>>      * @return n/a.
>>>      *
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -130,7 +130,6 @@
>>>      *
>>>      * @param plain the buffer with the input data to be encrypted
>>>      * @param plainOffset the offset in <code>plain</code>
>>> -     * @param plainLen the length of the input data
>>>      * @param cipher the buffer for the result
>>>      * @param cipherOffset the offset in <code>cipher</code>
>>>      */
>>> @@ -154,7 +153,6 @@
>>>      *
>>>      * @param cipher the buffer with the input data to be decrypted
>>>      * @param cipherOffset the offset in <code>cipherOffset</code>
>>> -     * @param cipherLen the length of the input data
>>>      * @param plain the buffer for the result
>>>      * @param plainOffset the offset in <code>plain</code>
>>>      */
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -552,7 +552,6 @@
>>>      *
>>>      * @param plain the buffer with the input data to be encrypted
>>>      * @param plainOffset the offset in <code>plain</code>
>>> -     * @param plainLen the length of the input data
>>>      * @param cipher the buffer for the result
>>>      * @param cipherOffset the offset in <code>cipher</code>
>>>      *
>>> @@ -579,7 +578,6 @@
>>>      *
>>>      * @param cipher the buffer with the input data to be decrypted
>>>      * @param cipherOffset the offset in <code>cipherOffset</code>
>>> -     * @param cipherLen the length of the input data
>>>      * @param plain the buffer for the result
>>>      * @param plainOffset the offset in <code>plain</code>
>>>      *
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -262,8 +262,6 @@
>>>      * @param algorithm the algorithm name
>>>      * @param key the key
>>>      * @param iv the iv
>>> -     * @param tagLenBytes the length of tag in bytes
>>> -     *
>>>      * @exception InvalidKeyException if the given key is inappropriate for
>>>      * initializing this cipher
>>>      */
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -225,7 +225,7 @@
>>>      *
>>>      * @param key the key
>>>      *
>>> -     * @param keySpec the requested format in which the key material shall be
>>> +     * @param keySpecCl the requested format in which the key material shall be
>>>      * returned
>>>      *
>>>      * @return the underlying key specification (key material) in the
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
>>> @@ -92,7 +92,7 @@
>>>      * Sets the padding mechanism of this cipher. This algorithm only uses
>>>      * PKCS #5 padding.
>>>      *
>>> -     * @param padding the padding mechanism
>>> +     * @param paddingScheme the padding mechanism
>>>      *
>>>      * @exception NoSuchPaddingException if the requested padding mechanism
>>>      * is invalid
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -75,7 +75,7 @@
>>>      *
>>>      * @param key the key
>>>      *
>>> -     * @param keySpec the requested format in which the key material shall be
>>> +     * @param keySpecCl the requested format in which the key material shall be
>>>      * returned
>>>      *
>>>      * @return the underlying key specification (key material) in the
>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -49,7 +49,7 @@
>>>      * interface.
>>>      *
>>>      * @param in the input buffer with the data to pad
>>> -     * @param the offset in <code>in</code> where the padding bytes
>>> +     * @param off the offset in <code>in</code> where the padding bytes
>>>      *  are appended
>>>      * @param len the number of padding bytes to add
>>>      *
>>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
>>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
>>> @@ -1077,7 +1077,7 @@
>>>      * Start a new Process using an explicit array of redirects.
>>>      * See {@link #start} for details of starting each Process.
>>>      *
>>> -     * @param redirect array of redirects for stdin, stdout, stderr
>>> +     * @param redirects array of redirects for stdin, stdout, stderr
>>>      * @return the new Process
>>>      * @throws IOException if an I/O error occurs
>>>      */
>>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
>>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
>>> @@ -731,7 +731,7 @@
>>>      * Constructs an empty GregorianCalendar.
>>>      *
>>>      * @param zone    the given time zone
>>> -     * @param aLocale the given locale
>>> +     * @param locale the given locale
>>>      * @param flag    the flag requesting an empty instance
>>>      */
>>>     GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
>>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
>>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -316,7 +316,7 @@
>>>      * If the address already has a scope-id or if the address is not local, ipv6
>>>      * or link local, then the original address is returned.
>>>      *
>>> -     * @param addr
>>> +     * @param address
>>>      * @exception SocketException if the given ipv6 link local address is found
>>>      *            on more than one local interface
>>>      * @return
>>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
>>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -208,7 +208,7 @@
>>>      * Use New to get new HttpsClient. This constructor is meant to be
>>>      * used only by New method. New properly checks for URL spoofing.
>>>      *
>>> -     * @param URL https URL with which a connection must be established
>>> +     * @param url https URL with which a connection must be established
>>>      */
>>>     private HttpsClient(SSLSocketFactory sf, URL url)
>>>     throws IOException
>>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
>>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
>>> @@ -321,7 +321,7 @@
>>>         /**
>>>          * Loads the provider with the specified class name.
>>>          *
>>> -         * @param name the name of the provider
>>> +         * @param pn the name of the provider
>>>          * @return the Provider, or null if it cannot be found or loaded
>>>          * @throws ProviderException all other exceptions are ignored
>>>          */
>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -72,7 +72,7 @@
>>>      * Constructor that initializes the input parameters.
>>>      *
>>>      * @param anchor the anchor selected to validate the target certificate
>>> -     * @param testDate the time for which the validity of the certificate
>>> +     * @param date the time for which the validity of the certificate
>>>      *        should be determined
>>>      * @param sigProvider the name of the signature provider
>>>      * @param sigOnly true if only signature checking is to be done;
>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -69,7 +69,7 @@
>>>     /**
>>>      * Initialize the builder with the input parameters.
>>>      *
>>> -     * @param params the parameter set used to build a certification path
>>> +     * @param buildParams the parameter set used to build a certification path
>>>      */
>>>     Builder(BuilderParams buildParams) {
>>>         this.buildParams = buildParams;
>>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
>>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>  *
>>>  * This code is free software; you can redistribute it and/or modify it
>>> @@ -111,7 +111,7 @@
>>>      * @param ruleFile       the name of the rule data file
>>>      * @param ruleData       the rule data loaded from the rule data file
>>>      * @param dictionaryFile the name of the dictionary file
>>> -     * @param dictionartData the dictionary data loaded from the dictionary file
>>> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>>>      * @throws MissingResourceException if rule data or dictionary initialization failed
>>>      */
>>>     public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
>>> 
>>> 
>>>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>>>> Please suggest if there is any way I can create my user id to upload this patch.
>>>>> 
>>>>> This is ~300 line patch file.
>>>>> 
>>>>> Regards,
>>>>> Vipin
>>>>> 
>>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>> 
>>>>>> Hi Vipin,
>>>>>> 
>>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>>>> Hi,
>>>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>>>> code and Javadoc, need a sponsor for this patch.
>>>>>>> Webrev is available at
>>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>>>> 
>>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>>>> 
>>>>>> Thanks,
>>>>>> David
>>>>>> 
>>>>>>> Regards,
>>>>>>> Vipin
>>>>> 
>>>> 
>>> Thanks,
>>> Vipin



From pavel.rappo at oracle.com  Wed Apr  8 11:50:33 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 Apr 2020 12:50:33 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
Message-ID: <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>

Vipin, here you go:

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

I took the liberty of additionally fixing a couple of parameters' names,
a typo, and `@exception` tags for checked exceptions that were neither thrown
nor imported.

The bulk of the change is in Security. Some changes are in Networking. The
appropriate mailing lists are in CC for this email. We should wait for their
feedback.

Changes in core area look good to me and I'd be surprised if there are any
problems with the remaining portion of the changeset.

-Pavel

> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
> 
> Hi Pavel,
> 
>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
> Yes I have signed OCA.
>> 
>> -Pavel
>> 
>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>> [2] changeset:   58344:65f30e209890
>> user:        clanger
>> date:        Wed Mar 11 13:50:13 2020 +0100
>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>> description:
>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>> Reviewed-by: clanger, vtewari
>> Contributed-by: vipinsharma85 at gmail.com
>> 
> Yes this is my first contribution.
> 
> Patch text:
> 
> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -202,7 +202,7 @@
>     /**
>      * Sets the padding mechanism of this cipher.
>      *
> -     * @param padding the padding mechanism
> +     * @param paddingScheme the padding mechanism
>      *
>      * @exception NoSuchPaddingException if the requested padding mechanism
>      * does not exist
> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -313,10 +313,10 @@
>      * current Cipher.engineInit(...) implementation,
>      * IllegalStateException will always be thrown upon invocation.
>      *
> -     * @param in the input buffer
> -     * @param inOffset the offset in <code>in</code> where the input
> +     * @param input the input buffer
> +     * @param inputOffset the offset in <code>in</code> where the input
>      * starts
> -     * @param inLen the input length.
> +     * @param inputLen the input length.
>      *
>      * @return n/a.
>      *
> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -130,7 +130,6 @@
>      *
>      * @param plain the buffer with the input data to be encrypted
>      * @param plainOffset the offset in <code>plain</code>
> -     * @param plainLen the length of the input data
>      * @param cipher the buffer for the result
>      * @param cipherOffset the offset in <code>cipher</code>
>      */
> @@ -154,7 +153,6 @@
>      *
>      * @param cipher the buffer with the input data to be decrypted
>      * @param cipherOffset the offset in <code>cipherOffset</code>
> -     * @param cipherLen the length of the input data
>      * @param plain the buffer for the result
>      * @param plainOffset the offset in <code>plain</code>
>      */
> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -552,7 +552,6 @@
>      *
>      * @param plain the buffer with the input data to be encrypted
>      * @param plainOffset the offset in <code>plain</code>
> -     * @param plainLen the length of the input data
>      * @param cipher the buffer for the result
>      * @param cipherOffset the offset in <code>cipher</code>
>      *
> @@ -579,7 +578,6 @@
>      *
>      * @param cipher the buffer with the input data to be decrypted
>      * @param cipherOffset the offset in <code>cipherOffset</code>
> -     * @param cipherLen the length of the input data
>      * @param plain the buffer for the result
>      * @param plainOffset the offset in <code>plain</code>
>      *
> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -262,8 +262,6 @@
>      * @param algorithm the algorithm name
>      * @param key the key
>      * @param iv the iv
> -     * @param tagLenBytes the length of tag in bytes
> -     *
>      * @exception InvalidKeyException if the given key is inappropriate for
>      * initializing this cipher
>      */
> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -225,7 +225,7 @@
>      *
>      * @param key the key
>      *
> -     * @param keySpec the requested format in which the key material shall be
> +     * @param keySpecCl the requested format in which the key material shall be
>      * returned
>      *
>      * @return the underlying key specification (key material) in the
> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
> @@ -92,7 +92,7 @@
>      * Sets the padding mechanism of this cipher. This algorithm only uses
>      * PKCS #5 padding.
>      *
> -     * @param padding the padding mechanism
> +     * @param paddingScheme the padding mechanism
>      *
>      * @exception NoSuchPaddingException if the requested padding mechanism
>      * is invalid
> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -75,7 +75,7 @@
>      *
>      * @param key the key
>      *
> -     * @param keySpec the requested format in which the key material shall be
> +     * @param keySpecCl the requested format in which the key material shall be
>      * returned
>      *
>      * @return the underlying key specification (key material) in the
> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -49,7 +49,7 @@
>      * interface.
>      *
>      * @param in the input buffer with the data to pad
> -     * @param the offset in <code>in</code> where the padding bytes
> +     * @param off the offset in <code>in</code> where the padding bytes
>      *  are appended
>      * @param len the number of padding bytes to add
>      *
> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
> @@ -1077,7 +1077,7 @@
>      * Start a new Process using an explicit array of redirects.
>      * See {@link #start} for details of starting each Process.
>      *
> -     * @param redirect array of redirects for stdin, stdout, stderr
> +     * @param redirects array of redirects for stdin, stdout, stderr
>      * @return the new Process
>      * @throws IOException if an I/O error occurs
>      */
> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
> @@ -731,7 +731,7 @@
>      * Constructs an empty GregorianCalendar.
>      *
>      * @param zone    the given time zone
> -     * @param aLocale the given locale
> +     * @param locale the given locale
>      * @param flag    the flag requesting an empty instance
>      */
>     GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -316,7 +316,7 @@
>      * If the address already has a scope-id or if the address is not local, ipv6
>      * or link local, then the original address is returned.
>      *
> -     * @param addr
> +     * @param address
>      * @exception SocketException if the given ipv6 link local address is found
>      *            on more than one local interface
>      * @return
> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -208,7 +208,7 @@
>      * Use New to get new HttpsClient. This constructor is meant to be
>      * used only by New method. New properly checks for URL spoofing.
>      *
> -     * @param URL https URL with which a connection must be established
> +     * @param url https URL with which a connection must be established
>      */
>     private HttpsClient(SSLSocketFactory sf, URL url)
>     throws IOException
> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
> @@ -321,7 +321,7 @@
>         /**
>          * Loads the provider with the specified class name.
>          *
> -         * @param name the name of the provider
> +         * @param pn the name of the provider
>          * @return the Provider, or null if it cannot be found or loaded
>          * @throws ProviderException all other exceptions are ignored
>          */
> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -72,7 +72,7 @@
>      * Constructor that initializes the input parameters.
>      *
>      * @param anchor the anchor selected to validate the target certificate
> -     * @param testDate the time for which the validity of the certificate
> +     * @param date the time for which the validity of the certificate
>      *        should be determined
>      * @param sigProvider the name of the signature provider
>      * @param sigOnly true if only signature checking is to be done;
> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -69,7 +69,7 @@
>     /**
>      * Initialize the builder with the input parameters.
>      *
> -     * @param params the parameter set used to build a certification path
> +     * @param buildParams the parameter set used to build a certification path
>      */
>     Builder(BuilderParams buildParams) {
>         this.buildParams = buildParams;
> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -111,7 +111,7 @@
>      * @param ruleFile       the name of the rule data file
>      * @param ruleData       the rule data loaded from the rule data file
>      * @param dictionaryFile the name of the dictionary file
> -     * @param dictionartData the dictionary data loaded from the dictionary file
> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>      * @throws MissingResourceException if rule data or dictionary initialization failed
>      */
>     public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
> 
> 
>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> Hi David,
>>> 
>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>> Please suggest if there is any way I can create my user id to upload this patch.
>>> 
>>> This is ~300 line patch file. 
>>> 
>>> Regards,
>>> Vipin
>>> 
>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>> 
>>>> Hi Vipin,
>>>> 
>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>> Hi,
>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>> code and Javadoc, need a sponsor for this patch.
>>>>> Webrev is available at
>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>> 
>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>> 
>>>> Thanks,
>>>> David
>>>> 
>>>>> Regards,
>>>>> Vipin
>>> 
>> 
> Thanks,
> Vipin



From pavel.rappo at oracle.com  Wed Apr  8 13:27:28 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 Apr 2020 14:27:28 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
Message-ID: <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>

Why assume something that sophisticated where it can be adequately explained by
a simpler thing? :) I bet it was an IDE inspection.

-Pavel

> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 08/04/2020 14:07, Daniel Fuchs wrote:
>> Hi Pavel,
>> 
>> On 08/04/2020 13:56, David Holmes wrote:
>>> and `@exception` tags for checked exceptions that were neither thrown
>>> nor imported
>> 
>> Hopefully that's only on internal classes.
> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
> 
> -Alan



From vipinsharma85 at gmail.com  Wed Apr  8 16:35:34 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Wed, 8 Apr 2020 22:05:34 +0530
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
Message-ID: <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>



> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Why assume something that sophisticated where it can be adequately explained by
> a simpler thing? :) I bet it was an IDE inspection.
> 
> -Pavel

Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?

> 
>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>> Hi Pavel,
>>> 
>>> On 08/04/2020 13:56, David Holmes wrote:
>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>> nor imported
>>> 
>>> Hopefully that's only on internal classes.
>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>> 
>> -Alan
> 

Regards,
Vipin

From sean.mullan at oracle.com  Wed Apr  8 17:58:37 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Apr 2020 13:58:37 -0400
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
Message-ID: <82cbeba4-7e85-ea1b-df90-d1abdc429b4b@oracle.com>

We never actually deprecated the com.sun.jarsigner package with a 
forRemoval=true flag, so while it may be very low-risk to remove these 
APIs, I feel that we should not remove it w/o prior notice.

I would suggest adding the forRemoval=true for this package/APIs 
instead, and plan on removing it in JDK 16 or 17.

I'm ok with removing the jarsigner options because the man page already 
warned that they may be removed.

--Sean


On 4/7/20 4:04 AM, Weijun Wang wrote:
> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
> 
>              JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
> 
> Please review everything at:
> 
>     Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>              CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>           webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
> 
> The CSR "Problem" section has more info on why it's better to remove it now.
> 
> Thanks,
> Max
> 


From sean.mullan at oracle.com  Wed Apr  8 19:46:50 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 8 Apr 2020 15:46:50 -0400
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
In-Reply-To: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
References: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
Message-ID: <556d9277-925c-aa9f-3281-327f36300977@oracle.com>

On 4/6/20 11:11 PM, Weijun Wang wrote:
> Please review the fix at
> 
>     http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
> 
> The major change is inside X509CRLImpl.java to allow params setting and reading.
> 
> I also take this chance to:
> 
> 1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".

I think you should file a CSR for that, since it is a new default, and 
the default varies based on the size of the key. You should also update 
the keytool man page section on defaults.

--Sean

> 2. Revert a former change in X509CertImpl.java, which might be a safer call.
> 
> Thanks,
> Max
> 


From anthony.scarpino at oracle.com  Wed Apr  8 20:18:22 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 8 Apr 2020 13:18:22 -0700
Subject: [RFR] 8242008: SSLSession inconsistencies
Message-ID: <045b8097-9031-0115-130b-0fcdf5f3bffb@oracle.com>

Hi,

I'd like a review of the following change.  There wre inconsistencies 
with SSLSession and session caching that needed to be fixed.  They are:
- With stateless resumption, SSLSession.getSessionContext() would return 
null.
- TLS 1.3 w/ session cache, the initial session was being added to the 
cache unnecessarily.
- With stateless resumption, SSLSession getPeerHost() could return 
corrupted.

A test is included for getSessionContext

https://cr.openjdk.java.net/~ascarpino/8242008/webrev.01/

thanks

Tony


From pavel.rappo at oracle.com  Wed Apr  8 21:15:51 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 8 Apr 2020 22:15:51 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
Message-ID: <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>

If your new patch addresses a similar type of problem, please send it in reply to this email,
so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.

> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
> 
> 
> 
>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> Why assume something that sophisticated where it can be adequately explained by
>> a simpler thing? :) I bet it was an IDE inspection.
>> 
>> -Pavel
> 
> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
> 
>> 
>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>> Hi Pavel,
>>>> 
>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>> nor imported
>>>> 
>>>> Hopefully that's only on internal classes.
>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>> 
>>> -Alan
>> 
> 
> Regards,
> Vipin



From valerie.peng at oracle.com  Wed Apr  8 23:32:25 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 8 Apr 2020 16:32:25 -0700
Subject: [15] RFR 8172680: Support SHA-3 based Hmac algorithms
In-Reply-To: <6b91c6a4-7b4d-99d8-817e-cbbe32dbad01@comcast.net>
References: <6eb43167-e530-c805-8212-007ada597ae2@oracle.com>
 <93e5a1a8-671c-2c73-2580-3f944092a229@comcast.net>
 <44c5a123-db7a-d4e5-d978-df3e089b37ba@oracle.com>
 <492f53ff-8f79-2a16-20a4-445b655f94a1@comcast.net>
 <87fadfda-a7d4-edef-6de2-7de8914dc977@oracle.com>
 <6b91c6a4-7b4d-99d8-817e-cbbe32dbad01@comcast.net>
Message-ID: <90dc8871-9a99-d3e0-4002-7df74923ec7f@oracle.com>

Hi Mike,

Thanks much for the comments and info~

I filed JDK-8242332 "Add SHA3 support to SunPKCS11 provider" 
(https://bugs.openjdk.java.net/browse/JDK-8242332) to track the SHA3 
support for PKCS11 provider. I think it's easier/cleaner to handle it 
separately and makes it more visible.

As for supporting vendor-specific mechanisms, that is probably lower 
priority than supporting standard SHA3 mechanisms.

It's true that the APIs are the same if the mechanisms are of the same 
type. It can probably be achieved by enhancing PKCS11 provider 
configuration if such support is needed. But so far, no one has 
requested about it.

Regards,

Valerie


On 4/3/2020 5:29 PM, Michael StJohns wrote:
> Hi Valerie -
>
> In line
>
> On 4/3/2020 5:32 PM, Valerie Peng wrote:
>>
>> Hi Mike,
>>
>> We can update SunPKCS11 provider when the PKCS#11 official header 
>> files are updated with SHA3 and Hmac w/ SHA3.
>>
>> I agree with you on the ideal case is to have no lagging in JCA and 
>> the SunPKCS11 provider.
>>
>> The main reason for the lagging is that we need to test and make sure 
>> the added functionality works. I checked NSS which is what existing 
>> PKCS11 regression tests use and it does not have any SHA3 support. Do 
>> you know other PKCS11 vendors which supports SHA3 and Hmac w/ SHA3? 
>> If there are many, it'll help me justifying this when the official 
>> headers are not updated yet.
>>
> I've got an include file from Utimaco dated 27 March 2017 that 
> includes the SHA3 assignments from PKCS11 - and their collateral says 
> they implement SHA3 (this is all of the message digest, hmac and 
> signature mechanisms, and key derivation mechanisms specified for 
> PKCS11 3.0.
>
> Safenet ProtectServer has it 
> https://data-protection-updates.gemalto.com/2018/04/27/product-release-safenet-protecttoolkit-5-6/
>
> I can't find anything that says nCipher has it.
>
> That's two out of three of the big ones.
>
>> I am not sure if I understand your suggestion of PKCS11 specific 
>> mechanism naming convention. Is it about duplicating the pending SHA3 
>> mechanism definitions in SunPKCS11 provider? It's trivial to add the 
>> SHA3 related mechanism definitions to SunPKCS11 provider, but the 
>> convention is to add things only after they are official as it may be 
>> hard to change due to backward compatibility concern.
>>
> Something like MessageDigest.getInstance ("SHA3_256", pkcs11provider) 
> ends up mapping to an underlying call "CK_MECHANISM m = new 
> CK_MECHANISM (CKM_SHA3_256);" where CKM_SHA3_256 is? "public static 
> long CKM_SHA3_256 = 0x000002b0L;"
>
> There are at times a number of proprietary or provider specific 
> algorithms that the underlying PKCS11 dll might support, but for which 
> the Java PKCS11 provider doesn't have the string (name) to mechanism 
> number mapping, but for which the API is the same as for any other 
> algorithm of its class.
>
> For example, the Utimaco PKCS11 definitions include
>
> #define CKM_DES3_RETAIL_MAC??????????? 0x80000135??? // Retail-MAC 
> with 0-Padding
>
> Which is unlikely to be part of any PKCS11 standard, but could be 
> accessed by
>
> Mac.getInstance ("PKCS11_MAC_16_80000135", pkcs11provider); //??? 16 
> is the mac length.
>
> So this is an escape mechanism to permit access to provider extensions 
> without having to reflect them back into the Java PKCS11 provider.
>
> (When support for EC algorithms were being kept from various software 
> - including NSS - due to nervousness about patent claims, I ended up 
> using the PKCS11 wrapper classes directly specifically because I 
> couldn't do an ECDSA via the PKCS11 provider.? That hasn't been the 
> case for a while, but it's always bothered me that the JCA got in the 
> way of the underlying provider.)
>
> I don't know that is doable given the current architecture (which 
> usually requires an OID for a mechanism to register it for SunPKCS11), 
> but something to think about.
>
>> Thanks & hope you get enough sleep during this difficult time...
>>
> *laugh* I'm doing better thanks.? I wrenched something in my shoulder 
> and it kept me awake or woke me up when I was sleeping.? Much better now.
>
> Thanks! Mike
>
>
>> Valerie
>>
>> On 3/31/2020 10:15 AM, Michael StJohns wrote:
>>> Sorry - this one got past me.
>>>
>>> For PKCS11 - the assignment of mechanism numbers can happen at any 
>>> time and doesn't necessarily result in a new version of the 
>>> specification. In this case, the API won't change, so there's no 
>>> reason - since the mechanism numbers have been assigned since last 
>>> May at least - to wait for V3.? Among other things, I would expect 
>>> that various vendors have already implemented these in their 2.xx 
>>> implementations.
>>>
>>> One of the reasons I ended up using the SunPKCS11 wrapper classes 
>>> directly quite a while ago was that the PKCS11 spec hadn't been 
>>> updated, but that my PKCS11 provider was supplying various EC 
>>> mechanisms that I needed.?? Ideally, the JCA and SunPKCS11 provider 
>>> support should *precede* any given underlying PKCS11 device support, 
>>> not trail it by 6-12 months.
>>>
>>> The assignment of mechanism numbers is exactly equivalent to the 
>>> assignment of TLS cipher suite numbers - the underlying protocol 
>>> doesn't change, so this is mostly a change to the mapping tables and 
>>> enclosed classes.
>>>
>>> In any event, any given PKCS11 implementation may or may not support 
>>> any given set of mechanisms - the provider really ought to be 
>>> calling C_GetMechanismList() and using that as the list of supported 
>>> JNA mechanisms.
>>>
>>> Sorry - I'm dealing with a bit of lack of sleep here so I may be 
>>> babbling, but I'm wondering if it might not be a bad idea to add 
>>> some sort of PKCS11 specific mechanism naming convention to allow 
>>> for the lag/lead problem??? E.g?? PKCS11_DIGEST_000002B0 would be 
>>> PKCS11's CKM_SHA3_256 hashing function given
>>>
>>>> #define CKM_SHA3_2560x000002B0
>>>>
>>> Just a thought.
>>>
>>> Thanks - Mike
>>>
>>>
>>> On 3/19/2020 5:27 PM, Valerie Peng wrote:
>>>> Hi Mike,
>>>>
>>>> Thanks for heads up. From what I can gather, SHA3 inclusion is part 
>>>> of PKCS#11 v3. Is this the next release which you are referring to? 
>>>> Or will there be an update to v2.40? Is there any schedule info for 
>>>> these update/release do you know?
>>>>
>>>> Following the convention, we normally don't add something which the 
>>>> underlying library has no support yet. With the new 6-month JDK 
>>>> release cycle, it's much faster for the added functionality to be 
>>>> available. So, I'd still prefer to update SunPKCS11 provider with 
>>>> SHA-3 once they are officially included.
>>>>
>>>> Valerie
>>>>
>>>> On 3/18/2020 4:07 PM, Michael StJohns wrote:
>>>>> On 3/18/2020 6:57 PM, Valerie Peng wrote:
>>>>>>
>>>>>> Anyone has time to help review this straight forward RFE? It's to 
>>>>>> add SHA-3 support to Hmac.
>>>>>>
>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8172680
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/
>>>>>>
>>>>>> Mach5 run is clean.
>>>>>>
>>>>>> Thanks,
>>>>>> Valerie
>>>>>
>>>>> Valerie -
>>>>>
>>>>> I know the RFE says no PKCS11 because 2.40 doesn't include those 
>>>>> items, but OASIS PKCS11 has proposed? SHA3 identifiers at 
>>>>> https://github.com/oasis-tcs/pkcs11/blob/master/working/identifier_db/sha3.result 
>>>>> - maybe reach out and ask if these have been allocated pending the 
>>>>> next release?
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>> #define CKM_SHA3_256????????????? 0x000002b0UL
>>>>> ?#define CKM_SHA3_256_HMAC???????? 0x000002b1UL
>>>>> ?#define CKM_SHA3_256_HMAC_GENERAL 0x000002b2UL
>>>>> ?#define CKM_SHA3_224????????????? 0x000002b5UL
>>>>> ?#define CKM_SHA3_224_HMAC???????? 0x000002b6UL
>>>>> ?#define CKM_SHA3_224_HMAC_GENERAL 0x000002b7UL
>>>>> ?#define CKM_SHA3_384????????????? 0x000002c0UL
>>>>> ?#define CKM_SHA3_384_HMAC???????? 0x000002c1UL
>>>>> ?#define CKM_SHA3_384_HMAC_GENERAL 0x000002c2UL
>>>>> ?#define CKM_SHA3_512????????????? 0x000002d0UL
>>>>> ?#define CKM_SHA3_512_HMAC???????? 0x000002d1UL
>>>>> ?#define CKM_SHA3_512_HMAC_GENERAL 0x000002d2UL
>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200408/e084afaf/attachment.htm>

From david.holmes at oracle.com  Thu Apr  9 00:16:45 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Apr 2020 10:16:45 +1000
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <1DBD2136-ECF2-4464-B57A-E83603891ACD@oracle.com>
Message-ID: <6111470b-2fc5-2dc0-2b67-3e93ccc03f41@oracle.com>

Hi Pavel,

On 8/04/2020 11:23 pm, Pavel Rappo wrote:
> Hey David,
> 
> Where exactly? In the files affected by this changeset? If so, then we will
> introduce inconsistency. Otherwise it's a huge change. From what I can see there
> are some 250 occurrences of `@exception` in src/java.base/share/classes/com/sun/{crypto, security}
> and some 7,300 in src.

Okay as I said I didn't examine in detail to see the size of the change 
- and its obviously too big.

> Personally, out of all tag renovations, changing `@exception` to `@throws`
> probably gives the least bang for the buck. If nothing else, it gives you 3
> extra characters on the same line to fill with something more useful.

There was an effort to do this conversion a while back, at least while 
touching affected files. It's not a big deal to me.

Cheers,
David

> I would be more inclined to change `<code>...</code>` to `{@code ...}`, but
> given how error-prone that can be, I still wouldn't do it in this changeset.
> 
> -Pavel
> 
>> On 8 Apr 2020, at 13:56, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Pavel,
>>
>> Not a review ...
>>
>> On 8/04/2020 9:50 pm, Pavel Rappo wrote:
>>> Vipin, here you go:
>>>      https://bugs.openjdk.java.net/browse/JDK-8242366
>>>      http://cr.openjdk.java.net/~prappo/8242366/webrev.00/
>>> I took the liberty of additionally fixing a couple of parameters' names,
>>> a typo, and `@exception` tags for checked exceptions that were neither thrown
>>> nor imported.
>>
>> While you are in there is it worth changing @exception to @throws? (I didn't look to see how big that change would be.)
>>
>> Cheers,
>> David
>>
>>> The bulk of the change is in Security. Some changes are in Networking. The
>>> appropriate mailing lists are in CC for this email. We should wait for their
>>> feedback.
>>> Changes in core area look good to me and I'd be surprised if there are any
>>> problems with the remaining portion of the changeset.
>>> -Pavel
>>>> On 7 Apr 2020, at 19:50, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>
>>>> Hi Pavel,
>>>>
>>>>> On Apr 7, 2020, at 11:11 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>>
>>>>> I assume you have signed the OCA [1]. If not and you want to continue, please do it. If you've already done so, which is probably the case [2], please attach your patch as text to this thread with the next email. Do not use zip or the like. I will take it from there and sponsor that for you.
>>>> Yes I have signed OCA.
>>>>>
>>>>> -Pavel
>>>>>
>>>>> [1] https://www.oracle.com/technetwork/community/oca-486395.html
>>>>> [2] changeset:   58344:65f30e209890
>>>>> user:        clanger
>>>>> date:        Wed Mar 11 13:50:13 2020 +0100
>>>>> files:       test/jdk/java/lang/Boolean/GetBoolean.java test/jdk/java/lang/Boolean/MakeBooleanComparable.java test/jdk/java/lang/Boolean/ParseBoolean.java
>>>>> description:
>>>>> 8240524: Remove explicit type argument in test jdk/java/lang/Boolean/MakeBooleanComparable.java
>>>>> Reviewed-by: clanger, vtewari
>>>>> Contributed-by: vipinsharma85 at gmail.com
>>>>>
>>>> Yes this is my first contribution.
>>>>
>>>> Patch text:
>>>>
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.546117441 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java	2020-04-06 00:19:10.130115855 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2002, 2017, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2002, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -202,7 +202,7 @@
>>>>      /**
>>>>       * Sets the padding mechanism of this cipher.
>>>>       *
>>>> -     * @param padding the padding mechanism
>>>> +     * @param paddingScheme the padding mechanism
>>>>       *
>>>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>>>       * does not exist
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.526121179 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/AESWrapCipher.java	2020-04-06 00:19:11.118119622 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2004, 2017, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -313,10 +313,10 @@
>>>>       * current Cipher.engineInit(...) implementation,
>>>>       * IllegalStateException will always be thrown upon invocation.
>>>>       *
>>>> -     * @param in the input buffer
>>>> -     * @param inOffset the offset in <code>in</code> where the input
>>>> +     * @param input the input buffer
>>>> +     * @param inputOffset the offset in <code>in</code> where the input
>>>>       * starts
>>>> -     * @param inLen the input length.
>>>> +     * @param inputLen the input length.
>>>>       *
>>>>       * @return n/a.
>>>>       *
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.462124749 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/BlowfishCrypt.java	2020-04-06 00:19:12.054123193 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1998, 2007, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1998, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -130,7 +130,6 @@
>>>>       *
>>>>       * @param plain the buffer with the input data to be encrypted
>>>>       * @param plainOffset the offset in <code>plain</code>
>>>> -     * @param plainLen the length of the input data
>>>>       * @param cipher the buffer for the result
>>>>       * @param cipherOffset the offset in <code>cipher</code>
>>>>       */
>>>> @@ -154,7 +153,6 @@
>>>>       *
>>>>       * @param cipher the buffer with the input data to be decrypted
>>>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>>>> -     * @param cipherLen the length of the input data
>>>>       * @param plain the buffer for the result
>>>>       * @param plainOffset the offset in <code>plain</code>
>>>>       */
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:13.414128382 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java	2020-04-06 00:19:12.998126795 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -552,7 +552,6 @@
>>>>       *
>>>>       * @param plain the buffer with the input data to be encrypted
>>>>       * @param plainOffset the offset in <code>plain</code>
>>>> -     * @param plainLen the length of the input data
>>>>       * @param cipher the buffer for the result
>>>>       * @param cipherOffset the offset in <code>cipher</code>
>>>>       *
>>>> @@ -579,7 +578,6 @@
>>>>       *
>>>>       * @param cipher the buffer with the input data to be decrypted
>>>>       * @param cipherOffset the offset in <code>cipherOffset</code>
>>>> -     * @param cipherLen the length of the input data
>>>>       * @param plain the buffer for the result
>>>>       * @param plainOffset the offset in <code>plain</code>
>>>>       *
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:14.374132046 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java	2020-04-06 00:19:13.958130458 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2013, 2019, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -262,8 +262,6 @@
>>>>       * @param algorithm the algorithm name
>>>>       * @param key the key
>>>>       * @param iv the iv
>>>> -     * @param tagLenBytes the length of tag in bytes
>>>> -     *
>>>>       * @exception InvalidKeyException if the given key is inappropriate for
>>>>       * initializing this cipher
>>>>       */
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:15.314135635 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java	2020-04-06 00:19:14.898134047 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -225,7 +225,7 @@
>>>>       *
>>>>       * @param key the key
>>>>       *
>>>> -     * @param keySpec the requested format in which the key material shall be
>>>> +     * @param keySpecCl the requested format in which the key material shall be
>>>>       * returned
>>>>       *
>>>>       * @return the underlying key specification (key material) in the
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:16.270139285 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java	2020-04-06 00:19:15.846137666 +0530
>>>> @@ -92,7 +92,7 @@
>>>>       * Sets the padding mechanism of this cipher. This algorithm only uses
>>>>       * PKCS #5 padding.
>>>>       *
>>>> -     * @param padding the padding mechanism
>>>> +     * @param paddingScheme the padding mechanism
>>>>       *
>>>>       * @exception NoSuchPaddingException if the requested padding mechanism
>>>>       * is invalid
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:17.206142859 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/PBKDF2Core.java	2020-04-06 00:19:16.798141302 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2005, 2012, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2005, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -75,7 +75,7 @@
>>>>       *
>>>>       * @param key the key
>>>>       *
>>>> -     * @param keySpec the requested format in which the key material shall be
>>>> +     * @param keySpecCl the requested format in which the key material shall be
>>>>       * returned
>>>>       *
>>>>       * @return the underlying key specification (key material) in the
>>>> --- old/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:18.138146421 +0530
>>>> +++ new/src/java.base/share/classes/com/sun/crypto/provider/Padding.java	2020-04-06 00:19:17.722144831 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1997, 2007, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -49,7 +49,7 @@
>>>>       * interface.
>>>>       *
>>>>       * @param in the input buffer with the data to pad
>>>> -     * @param the offset in <code>in</code> where the padding bytes
>>>> +     * @param off the offset in <code>in</code> where the padding bytes
>>>>       *  are appended
>>>>       * @param len the number of padding bytes to add
>>>>       *
>>>> --- old/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:19.086150043 +0530
>>>> +++ new/src/java.base/share/classes/java/lang/ProcessBuilder.java	2020-04-06 00:19:18.670148453 +0530
>>>> @@ -1077,7 +1077,7 @@
>>>>       * Start a new Process using an explicit array of redirects.
>>>>       * See {@link #start} for details of starting each Process.
>>>>       *
>>>> -     * @param redirect array of redirects for stdin, stdout, stderr
>>>> +     * @param redirects array of redirects for stdin, stdout, stderr
>>>>       * @return the new Process
>>>>       * @throws IOException if an I/O error occurs
>>>>       */
>>>> --- old/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:20.050153727 +0530
>>>> +++ new/src/java.base/share/classes/java/util/GregorianCalendar.java	2020-04-06 00:19:19.634152137 +0530
>>>> @@ -731,7 +731,7 @@
>>>>       * Constructs an empty GregorianCalendar.
>>>>       *
>>>>       * @param zone    the given time zone
>>>> -     * @param aLocale the given locale
>>>> +     * @param locale the given locale
>>>>       * @param flag    the flag requesting an empty instance
>>>>       */
>>>>      GregorianCalendar(TimeZone zone, Locale locale, boolean flag) {
>>>> --- old/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:21.042157520 +0530
>>>> +++ new/src/java.base/share/classes/sun/net/util/IPAddressUtil.java	2020-04-06 00:19:20.630155944 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2004, 2015, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2004, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -316,7 +316,7 @@
>>>>       * If the address already has a scope-id or if the address is not local, ipv6
>>>>       * or link local, then the original address is returned.
>>>>       *
>>>> -     * @param addr
>>>> +     * @param address
>>>>       * @exception SocketException if the given ipv6 link local address is found
>>>>       *            on more than one local interface
>>>>       * @return
>>>> --- old/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:22.266162200 +0530
>>>> +++ new/src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java	2020-04-06 00:19:21.854160624 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2001, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -208,7 +208,7 @@
>>>>       * Use New to get new HttpsClient. This constructor is meant to be
>>>>       * used only by New method. New properly checks for URL spoofing.
>>>>       *
>>>> -     * @param URL https URL with which a connection must be established
>>>> +     * @param url https URL with which a connection must be established
>>>>       */
>>>>      private HttpsClient(SSLSocketFactory sf, URL url)
>>>>      throws IOException
>>>> --- old/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.502166928 +0530
>>>> +++ new/src/java.base/share/classes/sun/security/jca/ProviderConfig.java	2020-04-06 00:19:23.082165322 +0530
>>>> @@ -321,7 +321,7 @@
>>>>          /**
>>>>           * Loads the provider with the specified class name.
>>>>           *
>>>> -         * @param name the name of the provider
>>>> +         * @param pn the name of the provider
>>>>           * @return the Provider, or null if it cannot be found or loaded
>>>>           * @throws ProviderException all other exceptions are ignored
>>>>           */
>>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.446170540 +0530
>>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/BasicChecker.java	2020-04-06 00:19:24.034168963 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -72,7 +72,7 @@
>>>>       * Constructor that initializes the input parameters.
>>>>       *
>>>>       * @param anchor the anchor selected to validate the target certificate
>>>> -     * @param testDate the time for which the validity of the certificate
>>>> +     * @param date the time for which the validity of the certificate
>>>>       *        should be determined
>>>>       * @param sigProvider the name of the signature provider
>>>>       * @param sigOnly true if only signature checking is to be done;
>>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:25.394174168 +0530
>>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/Builder.java	2020-04-06 00:19:24.982172591 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -69,7 +69,7 @@
>>>>      /**
>>>>       * Initialize the builder with the input parameters.
>>>>       *
>>>> -     * @param params the parameter set used to build a certification path
>>>> +     * @param buildParams the parameter set used to build a certification path
>>>>       */
>>>>      Builder(BuilderParams buildParams) {
>>>>          this.buildParams = buildParams;
>>>> --- old/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.618178853 +0530
>>>> +++ new/src/java.base/share/classes/sun/text/DictionaryBasedBreakIterator.java	2020-04-06 00:19:26.210177291 +0530
>>>> @@ -1,5 +1,5 @@
>>>> /*
>>>> - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved.
>>>> + * Copyright (c) 1999, 2020, Oracle and/or its affiliates. All rights reserved.
>>>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>>>   *
>>>>   * This code is free software; you can redistribute it and/or modify it
>>>> @@ -111,7 +111,7 @@
>>>>       * @param ruleFile       the name of the rule data file
>>>>       * @param ruleData       the rule data loaded from the rule data file
>>>>       * @param dictionaryFile the name of the dictionary file
>>>> -     * @param dictionartData the dictionary data loaded from the dictionary file
>>>> +     * @param dictionaryData the dictionary data loaded from the dictionary file
>>>>       * @throws MissingResourceException if rule data or dictionary initialization failed
>>>>       */
>>>>      public DictionaryBasedBreakIterator(String ruleFile, byte[] ruleData,
>>>>
>>>>
>>>>>> On 6 Apr 2020, at 17:07, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> I forgot to mention this is my second patch here. I am new to this project, as per my understanding we need to contribute 3 patches to get user id and space on cr.openjdk.java.net, for now I need sponsor who can create bug id and upload this webrev on cr.openjdk.java.net
>>>>>> Please suggest if there is any way I can create my user id to upload this patch.
>>>>>>
>>>>>> This is ~300 line patch file.
>>>>>>
>>>>>> Regards,
>>>>>> Vipin
>>>>>>
>>>>>>> On Apr 6, 2020, at 3:25 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi Vipin,
>>>>>>>
>>>>>>> On 6/04/2020 6:42 am, Vipin Sharma wrote:
>>>>>>>> Hi,
>>>>>>>> I have fixed a few warnings where the method parameter name is different in
>>>>>>>> code and Javadoc, need a sponsor for this patch.
>>>>>>>> Webrev is available at
>>>>>>>> https://drive.google.com/open?id=1EXUXKqGxzSR7sW2LShy0sgvP4z-bPL0e
>>>>>>>
>>>>>>> webrevs needs to be hosted on OpenJDK systems - either cr.openjdk.java.net, or inline in an email to the list (not an attachment) if small enough.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Vipin
>>>>>>
>>>>>
>>>> Thanks,
>>>> Vipin
> 


From weijun.wang at oracle.com  Thu Apr  9 07:13:09 2020
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 9 Apr 2020 15:13:09 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <82cbeba4-7e85-ea1b-df90-d1abdc429b4b@oracle.com>
References: <82cbeba4-7e85-ea1b-df90-d1abdc429b4b@oracle.com>
Message-ID: <80AD8D6B-B291-4E1D-9A41-13884457976A@oracle.com>

Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.

--Max

> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
> 
> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
> 
> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
> 
> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
> 
> --Sean
> 
> 
>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>             JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>> Please review everything at:
>>    Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>             CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>          webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>> The CSR "Problem" section has more info on why it's better to remove it now.
>> Thanks,
>> Max



From weijun.wang at oracle.com  Thu Apr  9 07:19:12 2020
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 9 Apr 2020 15:19:12 +0800
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
In-Reply-To: <556d9277-925c-aa9f-3281-327f36300977@oracle.com>
References: <556d9277-925c-aa9f-3281-327f36300977@oracle.com>
Message-ID: <336EC12E-87F5-4BEB-8E88-FB779E56A0F5@oracle.com>

Valerie in another reply suggested that the default parameters of the default sigAlg depends on either the size of the key (if RSA) of the params of the key (if RSASSA-PSS). I'll address all of these in another bug.

Thanks,
Max

> ? 2020?4?9??03:47?Sean Mullan <sean.mullan at oracle.com> ???
> 
> ?On 4/6/20 11:11 PM, Weijun Wang wrote:
>> Please review the fix at
>>    http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
>> The major change is inside X509CRLImpl.java to allow params setting and reading.
>> I also take this chance to:
>> 1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".
> 
> I think you should file a CSR for that, since it is a new default, and the default varies based on the size of the key. You should also update the keytool man page section on defaults.
> 
> --Sean
> 
>> 2. Revert a former change in X509CertImpl.java, which might be a safer call.
>> Thanks,
>> Max



From rahul.r.yadav at oracle.com  Thu Apr  9 13:13:14 2020
From: rahul.r.yadav at oracle.com (Rahul)
Date: Thu, 09 Apr 2020 14:13:14 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <13bea5bd-9fbe-adb6-6d9a-6bd4e519a02f@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
 <13bea5bd-9fbe-adb6-6d9a-6bd4e519a02f@oracle.com>
Message-ID: <6251FBC3-2E10-44D6-87D7-A0861B8A281A@oracle.com>

Thanks for the review Daniel.
 I have created a release note.

    RN : https://bugs.openjdk.java.net/browse/JDK-8242387

--Rahul

?On 08/04/2020, 16:00, "Daniel Fuchs" <daniel.fuchs at oracle.com> wrote:

    Good work Rahul!
    
    I am not sure whether that deserves a CSR (probably not) but we may
    want to create some release note to explain that the HttpClient is no
    longer overriding the default protocols selected by the SSLContext.
    
    So HTTP 1.1 over TLSv1.1 might now get negotiated where previously
    an handshake failure would have occurred. It might be worth mentioning
    in a release note.
    
    best regards,
    
    -- daniel
    
    On 08/04/2020 10:13, Rahul wrote:
    > Updated patch after considering the impact of returning default parameters on the http client.
    > TLS versions earlier limited to 1.2 and above by client, now will support all versions(wrt the scenarios for this bug).
    >      
    >      Issue:https://bugs.openjdk.java.net/browse/JDK-8239595
    >      Issue:https://bugs.openjdk.java.net/browse/JDK-8239594
    >      
    >      Webrev:http://cr.openjdk.java.net/~jboes/rayayada/webrevs/8239595/webrev.01/
    >      
    >      -- Rahul
    
    




From sean.mullan at oracle.com  Thu Apr  9 13:27:28 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 9 Apr 2020 09:27:28 -0400
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <80AD8D6B-B291-4E1D-9A41-13884457976A@oracle.com>
References: <82cbeba4-7e85-ea1b-df90-d1abdc429b4b@oracle.com>
 <80AD8D6B-B291-4E1D-9A41-13884457976A@oracle.com>
Message-ID: <c1e8969b-3d89-bd3e-8a47-bf9243f9672c@oracle.com>

On 4/9/20 3:13 AM, Wang Weijun wrote:
> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.

Why would you need to do that if they are deprecated?

--Sean

> 
> --Max
> 
>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>
>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>
>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>
>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>
>> --Sean
>>
>>
>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>              JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>> Please review everything at:
>>>     Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>              CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>           webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>> Thanks,
>>> Max
> 


From weijun.wang at oracle.com  Thu Apr  9 14:52:48 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 9 Apr 2020 22:52:48 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <c1e8969b-3d89-bd3e-8a47-bf9243f9672c@oracle.com>
References: <c1e8969b-3d89-bd3e-8a47-bf9243f9672c@oracle.com>
Message-ID: <D340361F-ACBC-4C0A-B9B1-1A64B19F27A0@oracle.com>

All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it. 

?Max

> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
> 
> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
> 
> Why would you need to do that if they are deprecated?
> 
> --Sean
> 
>> --Max
>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>> 
>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>> 
>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>> 
>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>> 
>>> --Sean
>>> 
>>> 
>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>             JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>> Please review everything at:
>>>>    Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>             CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>          webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>> Thanks,
>>>> Max



From sean.mullan at oracle.com  Thu Apr  9 14:58:19 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 9 Apr 2020 10:58:19 -0400
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <D340361F-ACBC-4C0A-B9B1-1A64B19F27A0@oracle.com>
References: <c1e8969b-3d89-bd3e-8a47-bf9243f9672c@oracle.com>
 <D340361F-ACBC-4C0A-B9B1-1A64B19F27A0@oracle.com>
Message-ID: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>

On 4/9/20 10:52 AM, Weijun Wang wrote:
> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.

But you can just use your solution in JarSigner in the webrev below 
where you are calling PKCS7.generateSignedData instead of ContentSigner. 
Just because the ContentSigner APIs are still there doesn't mean you 
have to use it in jarsigner (unless I am missing something).

--Sean

> 
> ?Max
> 
>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>
>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>
>> Why would you need to do that if they are deprecated?
>>
>> --Sean
>>
>>> --Max
>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>
>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>
>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>
>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>
>>>> --Sean
>>>>
>>>>
>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>              JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>> Please review everything at:
>>>>>     Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>              CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>           webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>> Thanks,
>>>>> Max
> 


From daniel.fuchs at oracle.com  Thu Apr  9 16:16:40 2020
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 9 Apr 2020 17:16:40 +0100
Subject: RFR JDK-8239595/JDK-8239594 : ssl context version is not
 respected/jdk.tls.client.protocols is not respected
In-Reply-To: <6251FBC3-2E10-44D6-87D7-A0861B8A281A@oracle.com>
References: <5f04da31-64ad-929d-2a80-c77d43e45bff@oracle.com>
 <07cc1080-7201-8303-b4b8-6912a4a71ac3@oracle.com>
 <78e9fd8e-71e3-a010-0657-021795158dba@oracle.com>
 <14bc9086-fce7-4972-dd18-45f52f93bde2@oracle.com>
 <318B981A-5C2D-4C6B-A3CA-F6D73EFC5C6A@oracle.com>
 <303a2309-c6b3-e69f-ca3a-a86088fcb414@oracle.com>
 <49DA8D56-5B1D-4406-9911-EE497790160F@oracle.com>
 <13bea5bd-9fbe-adb6-6d9a-6bd4e519a02f@oracle.com>
 <6251FBC3-2E10-44D6-87D7-A0861B8A281A@oracle.com>
Message-ID: <ea179f0b-47b7-f35a-273d-34406e2e251f@oracle.com>

Thanks Rahul. I believe you can mark it as Delivered now.

On 09/04/2020 14:13, Rahul wrote:
> Thanks for the review Daniel.
>   I have created a release note.
> 
>      RN :https://bugs.openjdk.java.net/browse/JDK-8242387



From weijun.wang at oracle.com  Fri Apr 10 01:58:27 2020
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 10 Apr 2020 09:58:27 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
Message-ID: <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>

So the classes will be useless but at least old program still compiles. I'll modify the CSR and see how Joe thinks of this.

Thanks,
Max

> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
> 
> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.
> 
> But you can just use your solution in JarSigner in the webrev below where you are calling PKCS7.generateSignedData instead of ContentSigner. Just because the ContentSigner APIs are still there doesn't mean you have to use it in jarsigner (unless I am missing something).
> 
> --Sean
> 
>> ?Max
>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>> 
>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>> 
>>> Why would you need to do that if they are deprecated?
>>> 
>>> --Sean
>>> 
>>>> --Max
>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>> 
>>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>> 
>>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>> 
>>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>> 
>>>>> --Sean
>>>>> 
>>>>> 
>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>>             JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>> Please review everything at:
>>>>>>    Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>             CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>          webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>>> Thanks,
>>>>>> Max



From weijun.wang at oracle.com  Fri Apr 10 09:03:39 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 10 Apr 2020 17:03:39 +0800
Subject: RFR 8153005: Upgrade the default PKCS12 encryption/MAC algorithms
Message-ID: <907C5852-0A7B-493F-8A8D-A8EB4B57D67B@oracle.com>

Please take a review at

           CSR : 8228481: Upgrade the default PKCS12 encryption/MAC algorithms
  Release note : https://bugs.openjdk.java.net/browse/JDK-8242069
        webrev : http://cr.openjdk.java.net/~weijun/8153005/webrev.00/

The default pkcs12 algorithms are bumped into PBE and HMAC based on SHA-256 and AES-256.

Thanks,
Max



From peter.levart at gmail.com  Fri Apr 10 09:07:10 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 10 Apr 2020 11:07:10 +0200
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
Message-ID: <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>

What's the use of allowing compiling some classes if those classes can't 
be used anywhere? They would be unusable in the new release of 
jarsigner. Ok, they could be used in some older jarsigner if the classes 
were compiled with appropriate -release option. So the usecase for not 
removing the classes would be in a project that builds an implementation 
of ContentSigner and then publishes it to be used in a project that 
still uses an old jarsigner. Such ContentSigner project could then be 
upgraded to use the new JDK/javac with appropriate -release option for 
compiling ContentSigner implementation classes.

Peter

On 4/10/20 3:58 AM, Wang Weijun wrote:
> So the classes will be useless but at least old program still compiles. I'll modify the CSR and see how Joe thinks of this.
>
> Thanks,
> Max
>
>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>
>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.
>> But you can just use your solution in JarSigner in the webrev below where you are calling PKCS7.generateSignedData instead of ContentSigner. Just because the ContentSigner APIs are still there doesn't mean you have to use it in jarsigner (unless I am missing something).
>>
>> --Sean
>>
>>> ?Max
>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>>> Why would you need to do that if they are deprecated?
>>>>
>>>> --Sean
>>>>
>>>>> --Max
>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>>>
>>>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>>>
>>>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>>
>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>>>              JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>> Please review everything at:
>>>>>>>     Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>              CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>           webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>>>> Thanks,
>>>>>>> Max



From peter.levart at gmail.com  Fri Apr 10 09:22:01 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 10 Apr 2020 11:22:01 +0200
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
Message-ID: <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>

Which brings me to this...

If it is a requirement to use -release option to compile ContentSigner 
implementation class in order for them to be usable (with some older 
release of jarsigner), then ContentSigner classes could as well be 
removed from the JDK 15 API because their signature will still be 
available to the javac with appropriate -release 14 or older option. So 
compilation would still succeed.

Peter

On 4/10/20 11:07 AM, Peter Levart wrote:
> What's the use of allowing compiling some classes if those classes 
> can't be used anywhere? They would be unusable in the new release of 
> jarsigner. Ok, they could be used in some older jarsigner if the 
> classes were compiled with appropriate -release option. So the usecase 
> for not removing the classes would be in a project that builds an 
> implementation of ContentSigner and then publishes it to be used in a 
> project that still uses an old jarsigner. Such ContentSigner project 
> could then be upgraded to use the new JDK/javac with appropriate 
> -release option for compiling ContentSigner implementation classes.
>
> Peter
>
> On 4/10/20 3:58 AM, Wang Weijun wrote:
>> So the classes will be useless but at least old program still 
>> compiles. I'll modify the CSR and see how Joe thinks of this.
>>
>> Thanks,
>> Max
>>
>>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>
>>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>> All info for signing are passed into a ContentSigner through a 
>>>> ContentSignerParameters object. In order to pass more info, I?ll 
>>>> need to create new interface methods for it.
>>> But you can just use your solution in JarSigner in the webrev below 
>>> where you are calling PKCS7.generateSignedData instead of 
>>> ContentSigner. Just because the ContentSigner APIs are still there 
>>> doesn't mean you have to use it in jarsigner (unless I am missing 
>>> something).
>>>
>>> --Sean
>>>
>>>> ?Max
>>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS 
>>>>>> and EdDSA. Sigh.
>>>>> Why would you need to do that if they are deprecated?
>>>>>
>>>>> --Sean
>>>>>
>>>>>> --Max
>>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ??? 
>>>>>>>>
>>>>>>> ?We never actually deprecated the com.sun.jarsigner package with 
>>>>>>> a forRemoval=true flag, so while it may be very low-risk to 
>>>>>>> remove these APIs, I feel that we should not remove it w/o prior 
>>>>>>> notice.
>>>>>>>
>>>>>>> I would suggest adding the forRemoval=true for this package/APIs 
>>>>>>> instead, and plan on removing it in JDK 16 or 17.
>>>>>>>
>>>>>>> I'm ok with removing the jarsigner options because the man page 
>>>>>>> already warned that they may be removed.
>>>>>>>
>>>>>>> --Sean
>>>>>>>
>>>>>>>
>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>> I am thinking about removing the `jarsigner -altsigner 
>>>>>>>> -altsignerpath` options and underlying classes:
>>>>>>>> ???????????? JBS : 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>> Please review everything at:
>>>>>>>> ??? Release note : 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>> ???????????? CSR : 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>> ????????? webrev : 
>>>>>>>> http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>> The CSR "Problem" section has more info on why it's better to 
>>>>>>>> remove it now.
>>>>>>>> Thanks,
>>>>>>>> Max
>



From weijun.wang at oracle.com  Fri Apr 10 09:45:35 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 10 Apr 2020 17:45:35 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
Message-ID: <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>

Hi Peter,

This is awkward but I've seen method that is marked deprecated for removal which simply throws an UnsupportedOperationException.

Suppose someone has an "enhanced" jarsigner that is also calling the JarSigner API. It might also support customized ContentSigner but is also used by no one. If the classes were removed the tool will not compile. If the classes remain but JarSigner no longer uses it, it will simply throws an UOE which is harmless to most people.

Maybe the tool maintainer has already added "@SuppressWarnings("deprecated")", but this time they will see a new warning on "[removal]", and they will know they need to remove it within a year.

--Max

> On Apr 10, 2020, at 5:22 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Which brings me to this...
> 
> If it is a requirement to use -release option to compile ContentSigner implementation class in order for them to be usable (with some older release of jarsigner), then ContentSigner classes could as well be removed from the JDK 15 API because their signature will still be available to the javac with appropriate -release 14 or older option. So compilation would still succeed.
> 
> Peter
> 
> On 4/10/20 11:07 AM, Peter Levart wrote:
>> What's the use of allowing compiling some classes if those classes can't be used anywhere? They would be unusable in the new release of jarsigner. Ok, they could be used in some older jarsigner if the classes were compiled with appropriate -release option. So the usecase for not removing the classes would be in a project that builds an implementation of ContentSigner and then publishes it to be used in a project that still uses an old jarsigner. Such ContentSigner project could then be upgraded to use the new JDK/javac with appropriate -release option for compiling ContentSigner implementation classes.
>> 
>> Peter
>> 
>> On 4/10/20 3:58 AM, Wang Weijun wrote:
>>> So the classes will be useless but at least old program still compiles. I'll modify the CSR and see how Joe thinks of this.
>>> 
>>> Thanks,
>>> Max
>>> 
>>>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>> 
>>>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>>> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.
>>>> But you can just use your solution in JarSigner in the webrev below where you are calling PKCS7.generateSignedData instead of ContentSigner. Just because the ContentSigner APIs are still there doesn't mean you have to use it in jarsigner (unless I am missing something).
>>>> 
>>>> --Sean
>>>> 
>>>>> ?Max
>>>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>>>>> Why would you need to do that if they are deprecated?
>>>>>> 
>>>>>> --Sean
>>>>>> 
>>>>>>> --Max
>>>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ??? 
>>>>>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>>>>> 
>>>>>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>>>>> 
>>>>>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>>>>> 
>>>>>>>> --Sean
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>>>>>              JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>>> Please review everything at:
>>>>>>>>>     Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>>>              CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>>>           webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>>>>>> Thanks,
>>>>>>>>> Max
>> 
> 



From weijun.wang at oracle.com  Fri Apr 10 12:40:35 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 10 Apr 2020 20:40:35 +0800
Subject: RFR 8242330: Arrays should be cloned in several JAAS Callback classes
Message-ID: <835479B2-89ED-4BD5-8C7A-FF58043B4C9C@oracle.com>

Please take a review at

      CSR : https://bugs.openjdk.java.net/browse/JDK-8242488
   webrev : http://cr.openjdk.java.net/~weijun/8242330/webrev.00/

Thanks,
Max



From sean.mullan at oracle.com  Fri Apr 10 12:52:53 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 10 Apr 2020 08:52:53 -0400
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
Message-ID: <be39da70-09e9-4c4b-5a72-216c5e619238@oracle.com>

Fair point, these two features are tightly coupled together so it 
probably doesn't make sense to remove (or keep) one w/o the other.

So, I recommend marking the ContentSigner APIs deprecated for removal in 
15, and delaying the removal of the APIs *and* the jarsigner -altsigner 
and -altsignerpath options until 16.

Whether we remove these in 15 or 16 is not going to make much of a 
difference in the long run.

--Sean

On 4/10/20 5:07 AM, Peter Levart wrote:
> What's the use of allowing compiling some classes if those classes can't 
> be used anywhere? They would be unusable in the new release of 
> jarsigner. Ok, they could be used in some older jarsigner if the classes 
> were compiled with appropriate -release option. So the usecase for not 
> removing the classes would be in a project that builds an implementation 
> of ContentSigner and then publishes it to be used in a project that 
> still uses an old jarsigner. Such ContentSigner project could then be 
> upgraded to use the new JDK/javac with appropriate -release option for 
> compiling ContentSigner implementation classes.
> 
> Peter
> 
> On 4/10/20 3:58 AM, Wang Weijun wrote:
>> So the classes will be useless but at least old program still 
>> compiles. I'll modify the CSR and see how Joe thinks of this.
>>
>> Thanks,
>> Max
>>
>>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>
>>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>> All info for signing are passed into a ContentSigner through a 
>>>> ContentSignerParameters object. In order to pass more info, I?ll 
>>>> need to create new interface methods for it.
>>> But you can just use your solution in JarSigner in the webrev below 
>>> where you are calling PKCS7.generateSignedData instead of 
>>> ContentSigner. Just because the ContentSigner APIs are still there 
>>> doesn't mean you have to use it in jarsigner (unless I am missing 
>>> something).
>>>
>>> --Sean
>>>
>>>> ?Max
>>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS 
>>>>>> and EdDSA. Sigh.
>>>>> Why would you need to do that if they are deprecated?
>>>>>
>>>>> --Sean
>>>>>
>>>>>> --Max
>>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>> ?We never actually deprecated the com.sun.jarsigner package with 
>>>>>>> a forRemoval=true flag, so while it may be very low-risk to 
>>>>>>> remove these APIs, I feel that we should not remove it w/o prior 
>>>>>>> notice.
>>>>>>>
>>>>>>> I would suggest adding the forRemoval=true for this package/APIs 
>>>>>>> instead, and plan on removing it in JDK 16 or 17.
>>>>>>>
>>>>>>> I'm ok with removing the jarsigner options because the man page 
>>>>>>> already warned that they may be removed.
>>>>>>>
>>>>>>> --Sean
>>>>>>>
>>>>>>>
>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>> I am thinking about removing the `jarsigner -altsigner 
>>>>>>>> -altsignerpath` options and underlying classes:
>>>>>>>> ???????????? JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>> Please review everything at:
>>>>>>>> ??? Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>> ???????????? CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>> ????????? webrev : 
>>>>>>>> http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>> The CSR "Problem" section has more info on why it's better to 
>>>>>>>> remove it now.
>>>>>>>> Thanks,
>>>>>>>> Max
> 


From weijun.wang at oracle.com  Fri Apr 10 14:02:08 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 10 Apr 2020 22:02:08 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <be39da70-09e9-4c4b-5a72-216c5e619238@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <be39da70-09e9-4c4b-5a72-216c5e619238@oracle.com>
Message-ID: <1380A892-093A-4D27-A44A-1FE8070105B7@oracle.com>

Currently, ContentSignerParameters has an interface method getSignatureAlgorithm(), the return value (Ex: SHA1withRSA) is then used by the ContentSigner to extract the digest algorithm (SHA1) to be put into a PKCS7 SignerInfo [1].

But the new algorithms are not named this way. For RSASSA-PSS, the digest algorithm is inside its PSSParameters. For EdDSA, in the private key (which tells if it's Ed25519 or Ed448).

So, we'll need a new interface method getDigestAlgorithm().

It's awkward to add a new method to a deprecated interface.

--Max

[1] https://tools.ietf.org/html/rfc5652#section-5.3

> On Apr 10, 2020, at 8:52 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Fair point, these two features are tightly coupled together so it probably doesn't make sense to remove (or keep) one w/o the other.
> 
> So, I recommend marking the ContentSigner APIs deprecated for removal in 15, and delaying the removal of the APIs *and* the jarsigner -altsigner and -altsignerpath options until 16.
> 
> Whether we remove these in 15 or 16 is not going to make much of a difference in the long run.
> 
> --Sean
> 
> On 4/10/20 5:07 AM, Peter Levart wrote:
>> What's the use of allowing compiling some classes if those classes can't be used anywhere? They would be unusable in the new release of jarsigner. Ok, they could be used in some older jarsigner if the classes were compiled with appropriate -release option. So the usecase for not removing the classes would be in a project that builds an implementation of ContentSigner and then publishes it to be used in a project that still uses an old jarsigner. Such ContentSigner project could then be upgraded to use the new JDK/javac with appropriate -release option for compiling ContentSigner implementation classes.
>> Peter
>> On 4/10/20 3:58 AM, Wang Weijun wrote:
>>> So the classes will be useless but at least old program still compiles. I'll modify the CSR and see how Joe thinks of this.
>>> 
>>> Thanks,
>>> Max
>>> 
>>>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>> 
>>>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>>> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.
>>>> But you can just use your solution in JarSigner in the webrev below where you are calling PKCS7.generateSignedData instead of ContentSigner. Just because the ContentSigner APIs are still there doesn't mean you have to use it in jarsigner (unless I am missing something).
>>>> 
>>>> --Sean
>>>> 
>>>>> ?Max
>>>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>>>>> Why would you need to do that if they are deprecated?
>>>>>> 
>>>>>> --Sean
>>>>>> 
>>>>>>> --Max
>>>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>>>>> 
>>>>>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>>>>> 
>>>>>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>>>>> 
>>>>>>>> --Sean
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>>>>>              JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>>> Please review everything at:
>>>>>>>>>     Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>>>              CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>>>           webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>>>>>> Thanks,
>>>>>>>>> Max



From weijun.wang at oracle.com  Fri Apr 10 14:17:29 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 10 Apr 2020 22:17:29 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <1380A892-093A-4D27-A44A-1FE8070105B7@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <be39da70-09e9-4c4b-5a72-216c5e619238@oracle.com>
 <1380A892-093A-4D27-A44A-1FE8070105B7@oracle.com>
Message-ID: <3D92ADD1-34F5-4658-90F9-FEF7D367DB72@oracle.com>

I simplified the issue. In fact, for RSASSA-PSS, we also need to pass the PSSParameters itself to the ContentSigner because it also needs to be encoded in SignerInfo. So another method getSignatureAlgorithmParameters() is needed. Or, to make things general, we can deprecate getSignatureAlgorithm() and add 2 new methods

   getSignatureAlgorithmIdentifiers() and getDigestAlgorithmIdentifiers()

--Max

> On Apr 10, 2020, at 10:02 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Currently, ContentSignerParameters has an interface method getSignatureAlgorithm(), the return value (Ex: SHA1withRSA) is then used by the ContentSigner to extract the digest algorithm (SHA1) to be put into a PKCS7 SignerInfo [1].
> 
> But the new algorithms are not named this way. For RSASSA-PSS, the digest algorithm is inside its PSSParameters. For EdDSA, in the private key (which tells if it's Ed25519 or Ed448).
> 
> So, we'll need a new interface method getDigestAlgorithm().
> 
> It's awkward to add a new method to a deprecated interface.
> 
> --Max
> 
> [1] https://tools.ietf.org/html/rfc5652#section-5.3
> 
>> On Apr 10, 2020, at 8:52 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>> 
>> Fair point, these two features are tightly coupled together so it probably doesn't make sense to remove (or keep) one w/o the other.
>> 
>> So, I recommend marking the ContentSigner APIs deprecated for removal in 15, and delaying the removal of the APIs *and* the jarsigner -altsigner and -altsignerpath options until 16.
>> 
>> Whether we remove these in 15 or 16 is not going to make much of a difference in the long run.
>> 
>> --Sean
>> 
>> On 4/10/20 5:07 AM, Peter Levart wrote:
>>> What's the use of allowing compiling some classes if those classes can't be used anywhere? They would be unusable in the new release of jarsigner. Ok, they could be used in some older jarsigner if the classes were compiled with appropriate -release option. So the usecase for not removing the classes would be in a project that builds an implementation of ContentSigner and then publishes it to be used in a project that still uses an old jarsigner. Such ContentSigner project could then be upgraded to use the new JDK/javac with appropriate -release option for compiling ContentSigner implementation classes.
>>> Peter
>>> On 4/10/20 3:58 AM, Wang Weijun wrote:
>>>> So the classes will be useless but at least old program still compiles. I'll modify the CSR and see how Joe thinks of this.
>>>> 
>>>> Thanks,
>>>> Max
>>>> 
>>>>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>> 
>>>>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>>>> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.
>>>>> But you can just use your solution in JarSigner in the webrev below where you are calling PKCS7.generateSignedData instead of ContentSigner. Just because the ContentSigner APIs are still there doesn't mean you have to use it in jarsigner (unless I am missing something).
>>>>> 
>>>>> --Sean
>>>>> 
>>>>>> ?Max
>>>>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>>>>>> Why would you need to do that if they are deprecated?
>>>>>>> 
>>>>>>> --Sean
>>>>>>> 
>>>>>>>> --Max
>>>>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>>>>>> 
>>>>>>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>>>>>> 
>>>>>>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>>>>>> 
>>>>>>>>> --Sean
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>>>>>>             JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>>>> Please review everything at:
>>>>>>>>>>    Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>>>>             CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>>>>          webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>>>>>>> Thanks,
>>>>>>>>>> Max
> 



From sean.mullan at oracle.com  Fri Apr 10 22:11:20 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 10 Apr 2020 18:11:20 -0400
Subject: RFR 8242330: Arrays should be cloned in several JAAS Callback
 classes
In-Reply-To: <835479B2-89ED-4BD5-8C7A-FF58043B4C9C@oracle.com>
References: <835479B2-89ED-4BD5-8C7A-FF58043B4C9C@oracle.com>
Message-ID: <525ff12c-74df-af71-aff3-24732a95a0f0@oracle.com>

Looks good.

--Sean

On 4/10/20 8:40 AM, Weijun Wang wrote:
> Please take a review at
> 
>        CSR : https://bugs.openjdk.java.net/browse/JDK-8242488
>     webrev : http://cr.openjdk.java.net/~weijun/8242330/webrev.00/
> 
> Thanks,
> Max
> 


From peter.levart at gmail.com  Sat Apr 11 09:44:08 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 11 Apr 2020 11:44:08 +0200
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
Message-ID: <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>



On 4/10/20 11:45 AM, Weijun Wang wrote:
> Hi Peter,
>
> This is awkward but I've seen method that is marked deprecated for removal which simply throws an UnsupportedOperationException.
>
> Suppose someone has an "enhanced" jarsigner that is also calling the JarSigner API. It might also support customized ContentSigner but is also used by no one. If the classes were removed the tool will not compile. If the classes remain but JarSigner no longer uses it, it will simply throws an UOE which is harmless to most people.
>
> Maybe the tool maintainer has already added "@SuppressWarnings("deprecated")", but this time they will see a new warning on "[removal]", and they will know they need to remove it within a year.
>
> --Max

Hi Max,

What I was trying to say is that even if you remove ContentSigner 
class(es) from JDK 15, users will still be able to compile either the 
special "enhanced" jarsigner or the ContentSigner implementations if 
they use -release 14 option.? They will just not be able to run the 
"enhanced" jarsigner with JDK 15. So removing a class from JDK 15 is not 
so bad as it was before the -release option was available. At least from 
the standpoint of compilation. So it makes a little difference if you 
remove the classes or not when you also remove the options to use/run 
the classes with jarsigner. What you choose is of course up to you. I 
see Sean is suggesting that you keep the options in the jarsigner for 
JDK 15.

Regards, Peter

>
>> On Apr 10, 2020, at 5:22 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> Which brings me to this...
>>
>> If it is a requirement to use -release option to compile ContentSigner implementation class in order for them to be usable (with some older release of jarsigner), then ContentSigner classes could as well be removed from the JDK 15 API because their signature will still be available to the javac with appropriate -release 14 or older option. So compilation would still succeed.
>>
>> Peter
>>
>> On 4/10/20 11:07 AM, Peter Levart wrote:
>>> What's the use of allowing compiling some classes if those classes can't be used anywhere? They would be unusable in the new release of jarsigner. Ok, they could be used in some older jarsigner if the classes were compiled with appropriate -release option. So the usecase for not removing the classes would be in a project that builds an implementation of ContentSigner and then publishes it to be used in a project that still uses an old jarsigner. Such ContentSigner project could then be upgraded to use the new JDK/javac with appropriate -release option for compiling ContentSigner implementation classes.
>>>
>>> Peter
>>>
>>> On 4/10/20 3:58 AM, Wang Weijun wrote:
>>>> So the classes will be useless but at least old program still compiles. I'll modify the CSR and see how Joe thinks of this.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>
>>>>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>>>> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.
>>>>> But you can just use your solution in JarSigner in the webrev below where you are calling PKCS7.generateSignedData instead of ContentSigner. Just because the ContentSigner APIs are still there doesn't mean you have to use it in jarsigner (unless I am missing something).
>>>>>
>>>>> --Sean
>>>>>
>>>>>> ?Max
>>>>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>>>>>> Why would you need to do that if they are deprecated?
>>>>>>>
>>>>>>> --Sean
>>>>>>>
>>>>>>>> --Max
>>>>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>>>>>>
>>>>>>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>>>>>>
>>>>>>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>>>>>>
>>>>>>>>> --Sean
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>>>>>>               JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>>>> Please review everything at:
>>>>>>>>>>      Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>>>>               CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>>>>            webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>>>>>>> Thanks,
>>>>>>>>>> Max



From weijun.wang at oracle.com  Sat Apr 11 10:31:42 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 11 Apr 2020 18:31:42 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
 <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
Message-ID: <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>

If the rule is that an API must be labeled forRemoval=true before it's really removed, then I cannot remove them in JDK 15.

--Max

> On Apr 11, 2020, at 5:44 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> 
> On 4/10/20 11:45 AM, Weijun Wang wrote:
>> Hi Peter,
>> 
>> This is awkward but I've seen method that is marked deprecated for removal which simply throws an UnsupportedOperationException.
>> 
>> Suppose someone has an "enhanced" jarsigner that is also calling the JarSigner API. It might also support customized ContentSigner but is also used by no one. If the classes were removed the tool will not compile. If the classes remain but JarSigner no longer uses it, it will simply throws an UOE which is harmless to most people.
>> 
>> Maybe the tool maintainer has already added "@SuppressWarnings("deprecated")", but this time they will see a new warning on "[removal]", and they will know they need to remove it within a year.
>> 
>> --Max
> 
> Hi Max,
> 
> What I was trying to say is that even if you remove ContentSigner class(es) from JDK 15, users will still be able to compile either the special "enhanced" jarsigner or the ContentSigner implementations if they use -release 14 option.  They will just not be able to run the "enhanced" jarsigner with JDK 15. So removing a class from JDK 15 is not so bad as it was before the -release option was available. At least from the standpoint of compilation. So it makes a little difference if you remove the classes or not when you also remove the options to use/run the classes with jarsigner. What you choose is of course up to you. I see Sean is suggesting that you keep the options in the jarsigner for JDK 15.
> 
> Regards, Peter
> 
>> 
>>> On Apr 10, 2020, at 5:22 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>> 
>>> Which brings me to this...
>>> 
>>> If it is a requirement to use -release option to compile ContentSigner implementation class in order for them to be usable (with some older release of jarsigner), then ContentSigner classes could as well be removed from the JDK 15 API because their signature will still be available to the javac with appropriate -release 14 or older option. So compilation would still succeed.
>>> 
>>> Peter
>>> 
>>> On 4/10/20 11:07 AM, Peter Levart wrote:
>>>> What's the use of allowing compiling some classes if those classes can't be used anywhere? They would be unusable in the new release of jarsigner. Ok, they could be used in some older jarsigner if the classes were compiled with appropriate -release option. So the usecase for not removing the classes would be in a project that builds an implementation of ContentSigner and then publishes it to be used in a project that still uses an old jarsigner. Such ContentSigner project could then be upgraded to use the new JDK/javac with appropriate -release option for compiling ContentSigner implementation classes.
>>>> 
>>>> Peter
>>>> 
>>>> On 4/10/20 3:58 AM, Wang Weijun wrote:
>>>>> So the classes will be useless but at least old program still compiles. I'll modify the CSR and see how Joe thinks of this.
>>>>> 
>>>>> Thanks,
>>>>> Max
>>>>> 
>>>>>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>> 
>>>>>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>>>>> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.
>>>>>> But you can just use your solution in JarSigner in the webrev below where you are calling PKCS7.generateSignedData instead of ContentSigner. Just because the ContentSigner APIs are still there doesn't mean you have to use it in jarsigner (unless I am missing something).
>>>>>> 
>>>>>> --Sean
>>>>>> 
>>>>>>> ?Max
>>>>>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>>>>>>> Why would you need to do that if they are deprecated?
>>>>>>>> 
>>>>>>>> --Sean
>>>>>>>> 
>>>>>>>>> --Max
>>>>>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>>>>>>> 
>>>>>>>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>>>>>>> 
>>>>>>>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>>>>>>> 
>>>>>>>>>> --Sean
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>>>>>>>              JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>>>>> Please review everything at:
>>>>>>>>>>>     Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>>>>>              CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>>>>>           webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Max
> 



From sean.mullan at oracle.com  Sat Apr 11 13:20:51 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Sat, 11 Apr 2020 09:20:51 -0400
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
 <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
 <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>
Message-ID: <03367944-cac1-11be-dee3-883294bc7131@oracle.com>

On 4/11/20 6:31 AM, Weijun Wang wrote:
> If the rule is that an API must be labeled forRemoval=true before it's really removed, then I cannot remove them in JDK 15.

Here is what JEP 277 [1] says:

    The following elements are to be added to the java.lang.Deprecated annotation type:

    A method forRemoval() returning a boolean. If true, it means that this
    API element is earmarked for removal in a future release. If false, the
    API element is deprecated, but there is currently no intention to remove
    it in a future release. The default value of this element is false.

Since these are JDK and not standard SE APIs, maybe we don't have to 
abide by that, but I think as a best practice we probably should. You 
could check with Joe Darcy and Stuart Marks if you want to be more sure.

--Sean

[1] https://openjdk.java.net/jeps/277

>
> --Max
>
>> On Apr 11, 2020, at 5:44 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>>
>>
>> On 4/10/20 11:45 AM, Weijun Wang wrote:
>>> Hi Peter,
>>>
>>> This is awkward but I've seen method that is marked deprecated for removal which simply throws an UnsupportedOperationException.
>>>
>>> Suppose someone has an "enhanced" jarsigner that is also calling the JarSigner API. It might also support customized ContentSigner but is also used by no one. If the classes were removed the tool will not compile. If the classes remain but JarSigner no longer uses it, it will simply throws an UOE which is harmless to most people.
>>>
>>> Maybe the tool maintainer has already added "@SuppressWarnings("deprecated")", but this time they will see a new warning on "[removal]", and they will know they need to remove it within a year.
>>>
>>> --Max
>> Hi Max,
>>
>> What I was trying to say is that even if you remove ContentSigner class(es) from JDK 15, users will still be able to compile either the special "enhanced" jarsigner or the ContentSigner implementations if they use -release 14 option.  They will just not be able to run the "enhanced" jarsigner with JDK 15. So removing a class from JDK 15 is not so bad as it was before the -release option was available. At least from the standpoint of compilation. So it makes a little difference if you remove the classes or not when you also remove the options to use/run the classes with jarsigner. What you choose is of course up to you. I see Sean is suggesting that you keep the options in the jarsigner for JDK 15.
>>
>> Regards, Peter
>>
>>>> On Apr 10, 2020, at 5:22 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>>>
>>>> Which brings me to this...
>>>>
>>>> If it is a requirement to use -release option to compile ContentSigner implementation class in order for them to be usable (with some older release of jarsigner), then ContentSigner classes could as well be removed from the JDK 15 API because their signature will still be available to the javac with appropriate -release 14 or older option. So compilation would still succeed.
>>>>
>>>> Peter
>>>>
>>>> On 4/10/20 11:07 AM, Peter Levart wrote:
>>>>> What's the use of allowing compiling some classes if those classes can't be used anywhere? They would be unusable in the new release of jarsigner. Ok, they could be used in some older jarsigner if the classes were compiled with appropriate -release option. So the usecase for not removing the classes would be in a project that builds an implementation of ContentSigner and then publishes it to be used in a project that still uses an old jarsigner. Such ContentSigner project could then be upgraded to use the new JDK/javac with appropriate -release option for compiling ContentSigner implementation classes.
>>>>>
>>>>> Peter
>>>>>
>>>>> On 4/10/20 3:58 AM, Wang Weijun wrote:
>>>>>> So the classes will be useless but at least old program still compiles. I'll modify the CSR and see how Joe thinks of this.
>>>>>>
>>>>>> Thanks,
>>>>>> Max
>>>>>>
>>>>>>> ? 2020?4?9??22:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>>
>>>>>>> ?On 4/9/20 10:52 AM, Weijun Wang wrote:
>>>>>>>> All info for signing are passed into a ContentSigner through a ContentSignerParameters object. In order to pass more info, I?ll need to create new interface methods for it.
>>>>>>> But you can just use your solution in JarSigner in the webrev below where you are calling PKCS7.generateSignedData instead of ContentSigner. Just because the ContentSigner APIs are still there doesn't mean you have to use it in jarsigner (unless I am missing something).
>>>>>>>
>>>>>>> --Sean
>>>>>>>
>>>>>>>> ?Max
>>>>>>>>>> ? 2020?4?9??21:27?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>>>> ?On 4/9/20 3:13 AM, Wang Weijun wrote:
>>>>>>>>>> Oh, I'll then need to add new fields to it to support RSASSA-PSS and EdDSA. Sigh.
>>>>>>>>> Why would you need to do that if they are deprecated?
>>>>>>>>>
>>>>>>>>> --Sean
>>>>>>>>>
>>>>>>>>>> --Max
>>>>>>>>>>>> ? 2020?4?9??01:58?Sean Mullan <sean.mullan at oracle.com> ???
>>>>>>>>>>> ?We never actually deprecated the com.sun.jarsigner package with a forRemoval=true flag, so while it may be very low-risk to remove these APIs, I feel that we should not remove it w/o prior notice.
>>>>>>>>>>>
>>>>>>>>>>> I would suggest adding the forRemoval=true for this package/APIs instead, and plan on removing it in JDK 16 or 17.
>>>>>>>>>>>
>>>>>>>>>>> I'm ok with removing the jarsigner options because the man page already warned that they may be removed.
>>>>>>>>>>>
>>>>>>>>>>> --Sean
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/20 4:04 AM, Weijun Wang wrote:
>>>>>>>>>>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>>>>>>>>>>>               JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>>>>>>>>>>> Please review everything at:
>>>>>>>>>>>>      Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>>>>>>>>>>               CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>>>>>>>>>>            webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>>>>>>>>>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200411/4537cf58/attachment.htm>

From Alan.Bateman at oracle.com  Sat Apr 11 14:20:05 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 11 Apr 2020 15:20:05 +0100
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <03367944-cac1-11be-dee3-883294bc7131@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
 <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
 <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>
 <03367944-cac1-11be-dee3-883294bc7131@oracle.com>
Message-ID: <5a2dc475-b804-e66f-e25f-1aa3a98c12c0@oracle.com>

On 11/04/2020 14:20, Sean Mullan wrote:
> On 4/11/20 6:31 AM, Weijun Wang wrote:
>> If the rule is that an API must be labeled forRemoval=true before it's really removed, then I cannot remove them in JDK 15.
>
> Here is what JEP 277 [1] says:
>
>     The following elements are to be added to the java.lang.Deprecated annotation type:
>
>     A method forRemoval() returning a boolean. If true, it means that this
>     API element is earmarked for removal in a future release. If false, the
>     API element is deprecated, but there is currently no intention to remove
>     it in a future release. The default value of this element is false.
>
> Since these are JDK and not standard SE APIs, maybe we don't have to 
> abide by that, but I think as a best practice we probably should. You 
> could check with Joe Darcy and Stuart Marks if you want to be more sure.
>
There is a JDK-specific API and command line options on the table here. 
Removing these without notice may surprise some. For the APIs then you 
could terminally deprecate them in JDK 15 and remove them in a future 
release. I don't think JEP 277 has been updated to provide guidance in 
the context of the new release cadence so use your best judgement (JDK 
16 might be too soon to remove). As regards the CLI options then you 
could add a warning to jarsigner so that anyone using this tool with 
existing content signers (compiled for JDK 8 for example) has some 
chance of seeing that the options will be going away in the future.

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200411/10f01449/attachment.htm>

From weijun.wang at oracle.com  Sat Apr 11 14:41:24 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 11 Apr 2020 22:41:24 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <5a2dc475-b804-e66f-e25f-1aa3a98c12c0@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
 <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
 <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>
 <03367944-cac1-11be-dee3-883294bc7131@oracle.com>
 <5a2dc475-b804-e66f-e25f-1aa3a98c12c0@oracle.com>
Message-ID: <87303478-D791-45CE-A94F-A87807F806E1@oracle.com>

The options were already deprecated long ago:

$ $J14/bin/jarsigner
Usage: jarsigner [options] jar-file alias
       jarsigner -verify [options] jar-file [alias...]
...

[-altsigner <class>]        class name of an alternative signing mechanism
                            (This option has been deprecated.)

[-altsignerpath <pathlist>] location of an alternative signing mechanism
                            (This option has been deprecated.)
...

and they are listed in a "Deprecated Options" section in the tooldoc with "might be removed in a future JDK release".

The only problem is I forgot to add a forRemoval=true argument to the @Deprecated annotation of the classes.

--Max

> On Apr 11, 2020, at 10:20 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 11/04/2020 14:20, Sean Mullan wrote:
>> On 4/11/20 6:31 AM, Weijun Wang wrote:
>>> If the rule is that an API must be labeled forRemoval=true before it's really removed, then I cannot remove them in JDK 15.
>> Here is what JEP 277 [1] says:
>> 
>> The following elements are to be added to the java.lang.Deprecated annotation type:
>> A method forRemoval() returning a boolean. If true, it means that this 
>> API element is earmarked for removal in a future release. If false, the 
>> API element is deprecated, but there is currently no intention to remove
>> it in a future release. The default value of this element is false.
>> 
>> Since these are JDK and not standard SE APIs, maybe we don't have to abide by that, but I think as a best practice we probably should. You could check with Joe Darcy and Stuart Marks if you want to be more sure.
>> 
> There is a JDK-specific API and command line options on the table here. Removing these without notice may surprise some. For the APIs then you could terminally deprecate them in JDK 15 and remove them in a future release. I don't think JEP 277 has been updated to provide guidance in the context of the new release cadence so use your best judgement (JDK 16 might be too soon to remove). As regards the CLI options then you could add a warning to jarsigner so that anyone using this tool with existing content signers (compiled for JDK 8 for example) has some chance of seeing that the options will be going away in the future.
> 
> -Alan.



From Alan.Bateman at oracle.com  Sat Apr 11 14:56:36 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 11 Apr 2020 15:56:36 +0100
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <87303478-D791-45CE-A94F-A87807F806E1@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
 <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
 <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>
 <03367944-cac1-11be-dee3-883294bc7131@oracle.com>
 <5a2dc475-b804-e66f-e25f-1aa3a98c12c0@oracle.com>
 <87303478-D791-45CE-A94F-A87807F806E1@oracle.com>
Message-ID: <a906a157-398f-c316-3a89-b3ffcd0f41c1@oracle.com>

On 11/04/2020 15:41, Weijun Wang wrote:
> The options were already deprecated long ago:
>
> $ $J14/bin/jarsigner
> Usage: jarsigner [options] jar-file alias
>         jarsigner -verify [options] jar-file [alias...]
> ...
>
> [-altsigner <class>]        class name of an alternative signing mechanism
>                              (This option has been deprecated.)
>
> [-altsignerpath <pathlist>] location of an alternative signing mechanism
>                              (This option has been deprecated.)
> ...
>
> and they are listed in a "Deprecated Options" section in the tooldoc with "might be removed in a future JDK release".
>
> The only problem is I forgot to add a forRemoval=true argument to the @Deprecated annotation of the classes.
>
I think the next step is to terminally deprecate the API, this means 
adding forRemoval=true to create awareness at compile-time.? You can 
then remove in some future release. You can use the opportunity to add a 
warning to the jarsigner tool so that someone using these options gets a 
warning and knows it will be removed in the future (they might not see 
deprecation notice in the usage/help output).

-Alan


From weijun.wang at oracle.com  Sat Apr 11 15:04:45 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 11 Apr 2020 23:04:45 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <a906a157-398f-c316-3a89-b3ffcd0f41c1@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
 <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
 <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>
 <03367944-cac1-11be-dee3-883294bc7131@oracle.com>
 <5a2dc475-b804-e66f-e25f-1aa3a98c12c0@oracle.com>
 <87303478-D791-45CE-A94F-A87807F806E1@oracle.com>
 <a906a157-398f-c316-3a89-b3ffcd0f41c1@oracle.com>
Message-ID: <B895DFD9-60FB-45BA-9EC0-519C04A4E273@oracle.com>

Today if you call "jarsigner -altsigner", it works but shows a warning:

   This option is deprecated: -altsigner

I think we have several solutions now:

1. Remove the options. The deprecated classes become useless.

2. Keep the options and update the deprecated classes to work with new signature algorithms. The update will likely to be 2 new methods and deprecating one existing.

Anyway, we will add a forRemoval=true to the classes.

Of course, if we can remove all of them, that will be very clean. I'll write a mail asking Joe and Stuart tomorrow. It's 11pm here.

--Max

> On Apr 11, 2020, at 10:56 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 11/04/2020 15:41, Weijun Wang wrote:
>> The options were already deprecated long ago:
>> 
>> $ $J14/bin/jarsigner
>> Usage: jarsigner [options] jar-file alias
>>        jarsigner -verify [options] jar-file [alias...]
>> ...
>> 
>> [-altsigner <class>]        class name of an alternative signing mechanism
>>                             (This option has been deprecated.)
>> 
>> [-altsignerpath <pathlist>] location of an alternative signing mechanism
>>                             (This option has been deprecated.)
>> ...
>> 
>> and they are listed in a "Deprecated Options" section in the tooldoc with "might be removed in a future JDK release".
>> 
>> The only problem is I forgot to add a forRemoval=true argument to the @Deprecated annotation of the classes.
>> 
> I think the next step is to terminally deprecate the API, this means adding forRemoval=true to create awareness at compile-time.  You can then remove in some future release. You can use the opportunity to add a warning to the jarsigner tool so that someone using these options gets a warning and knows it will be removed in the future (they might not see deprecation notice in the usage/help output).
> 
> -Alan



From sean.mullan at oracle.com  Sat Apr 11 15:53:01 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Sat, 11 Apr 2020 11:53:01 -0400
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <B895DFD9-60FB-45BA-9EC0-519C04A4E273@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
 <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
 <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>
 <03367944-cac1-11be-dee3-883294bc7131@oracle.com>
 <5a2dc475-b804-e66f-e25f-1aa3a98c12c0@oracle.com>
 <87303478-D791-45CE-A94F-A87807F806E1@oracle.com>
 <a906a157-398f-c316-3a89-b3ffcd0f41c1@oracle.com>
 <B895DFD9-60FB-45BA-9EC0-519C04A4E273@oracle.com>
Message-ID: <561fe4d4-c109-c362-896c-c18c4ed55a9c@oracle.com>

On 4/11/20 11:04 AM, Weijun Wang wrote:
> 2. Keep the options and update the deprecated classes to work with new signature algorithms. The update will likely to be 2 new methods and deprecating one existing.

Not sure if I understand this option, but I assume this is about adding 
RSASSA-PSS support to jarsigner. Perhaps we just delay that until JDK 16 
when you can remove the ContentSigner APIs, as it would be strange to 
add new methods to a deprecated class that will be marked forRemoval.

Also, why do we have to use the ContentSigner APIs for RSASSA-PSS? 
Couldn't you just use internal APIs as in your webrev?

--Sean


From weijun.wang at oracle.com  Sun Apr 12 02:11:55 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sun, 12 Apr 2020 10:11:55 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <561fe4d4-c109-c362-896c-c18c4ed55a9c@oracle.com>
References: <d56ffad7-c55e-4637-c5d9-6b47194ac507@oracle.com>
 <10E3F12D-B165-4C91-8F9A-0DAD8CE3FF71@oracle.com>
 <93a17b1a-0d0d-5f3e-6352-171e03fd5f24@gmail.com>
 <beb9a3ed-8ba0-616e-5f25-6d1310693e30@gmail.com>
 <CF64767B-BBA4-4F1A-9AD6-CAE848CBE55A@oracle.com>
 <af2aa276-9c3b-fe8b-00de-2674875c9c60@gmail.com>
 <6333B5C5-1426-4A92-AD83-7E9F4147EFEA@oracle.com>
 <03367944-cac1-11be-dee3-883294bc7131@oracle.com>
 <5a2dc475-b804-e66f-e25f-1aa3a98c12c0@oracle.com>
 <87303478-D791-45CE-A94F-A87807F806E1@oracle.com>
 <a906a157-398f-c316-3a89-b3ffcd0f41c1@oracle.com>
 <B895DFD9-60FB-45BA-9EC0-519C04A4E273@oracle.com>
 <561fe4d4-c109-c362-896c-c18c4ed55a9c@oracle.com>
Message-ID: <9902A434-A671-43A6-9294-B4F4E0A0ED57@oracle.com>



> On Apr 11, 2020, at 11:53 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 4/11/20 11:04 AM, Weijun Wang wrote:
>> 2. Keep the options and update the deprecated classes to work with new signature algorithms. The update will likely to be 2 new methods and deprecating one existing.
> 
> Not sure if I understand this option, but I assume this is about adding RSASSA-PSS support to jarsigner. Perhaps we just delay that until JDK 16 when you can remove the ContentSigner APIs, as it would be strange to add new methods to a deprecated class that will be marked forRemoval.

This is for both RSASSA-PSS and EdDSA, where you cannot derive the digest algorithm and signature algorithm parameters from the signature algorithm name.

> 
> Also, why do we have to use the ContentSigner APIs for RSASSA-PSS? Couldn't you just use internal APIs as in your webrev?

That's option 1: "Remove the options. The deprecated classes become useless."

--Max

> 
> --Sean



From vipinsharma85 at gmail.com  Sat Apr 11 19:23:57 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Sun, 12 Apr 2020 00:53:57 +0530
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
Message-ID: <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>

Hi Pavel,

> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> If your new patch addresses a similar type of problem, please send it in reply to this email,
> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
> 
This is additional patch:

--- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
+++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
@@ -142,7 +142,7 @@
        /**
         * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
         * data the index array offset of the indexes for that lead surrogate.
-        * @param property data value for a surrogate from the trie, including
+        * @param value data value for a surrogate from the trie, including
         *        the folding offset
         * @return data offset or 0 if there is no data for the lead surrogate
         */
--- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
+++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -39,7 +39,7 @@
 
     /**
      * Calls FilterInputStream's constructor.
-     * @param an InputStream
+     * @param is an InputStream
      */
     PlainTextInputStream(InputStream is) {
         super(is);
--- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
+++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -881,7 +881,7 @@
      * only CRLs signed with a different key (but the same issuer
      * name) as the certificate being checked.
      *
-     * @param currCert the <code>X509Certificate</code> to be checked
+     * @param cert the <code>X509Certificate</code> to be checked
      * @param prevKey the <code>PublicKey</code> that failed
      * @param signFlag <code>true</code> if that key was trusted to sign CRLs
      * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
--- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
+++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -166,7 +166,7 @@
     /**
      * Creates a URICertStore.
      *
-     * @param parameters specifying the URI
+     * @param params parameters specifying the URI
      */
     URICertStore(CertStoreParameters params)
         throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
--- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
+++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -483,7 +483,7 @@
          * and its corresponding CertId.
          *
          * @param subjectCert the certificate to be checked for revocation
-         * @param cid the CertId for {@code subjectCert}
+         * @param certId the CertId for {@code subjectCert}
          */
         StatusInfo(X509Certificate subjectCert, CertId certId) {
             cert = subjectCert;
--- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
+++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -193,7 +193,7 @@
     /**
      * Constructs an object to store the response to a timestamp request.
      *
-     * @param status A buffer containing the ASN.1 BER encoded response.
+     * @param tsReply A buffer containing the ASN.1 BER encoded response.
      * @throws IOException The exception is thrown if a problem is encountered
      *         parsing the timestamp response.
      */


>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>> 
>> 
>> 
>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>> 
>>> Why assume something that sophisticated where it can be adequately explained by
>>> a simpler thing? :) I bet it was an IDE inspection.
>>> 
>>> -Pavel
>> 
>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>> 
>>> 
>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> 
>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>> Hi Pavel,
>>>>> 
>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>> nor imported
>>>>> 
>>>>> Hopefully that's only on internal classes.
>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>> 
>>>> -Alan
>>> 
>> 
>> Regards,
>> Vipin
> 
Regards,
Vipin



From weijun.wang at oracle.com  Mon Apr 13 08:53:12 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 13 Apr 2020 16:53:12 +0800
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
 <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
Message-ID: <BD44C2EF-3417-4863-9A77-00D6A4F8B42A@oracle.com>

The additional patch looks fine to me.

Thanks,
Max

> On Apr 12, 2020, at 3:23 AM, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
> 
> Hi Pavel,
> 
>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> If your new patch addresses a similar type of problem, please send it in reply to this email,
>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>> 
> This is additional patch:
> 
> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
> @@ -142,7 +142,7 @@
>        /**
>         * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>         * data the index array offset of the indexes for that lead surrogate.
> -        * @param property data value for a surrogate from the trie, including
> +        * @param value data value for a surrogate from the trie, including
>         *        the folding offset
>         * @return data offset or 0 if there is no data for the lead surrogate
>         */
> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -39,7 +39,7 @@
> 
>     /**
>      * Calls FilterInputStream's constructor.
> -     * @param an InputStream
> +     * @param is an InputStream
>      */
>     PlainTextInputStream(InputStream is) {
>         super(is);
> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -881,7 +881,7 @@
>      * only CRLs signed with a different key (but the same issuer
>      * name) as the certificate being checked.
>      *
> -     * @param currCert the <code>X509Certificate</code> to be checked
> +     * @param cert the <code>X509Certificate</code> to be checked
>      * @param prevKey the <code>PublicKey</code> that failed
>      * @param signFlag <code>true</code> if that key was trusted to sign CRLs
>      * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -166,7 +166,7 @@
>     /**
>      * Creates a URICertStore.
>      *
> -     * @param parameters specifying the URI
> +     * @param params parameters specifying the URI
>      */
>     URICertStore(CertStoreParameters params)
>         throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -483,7 +483,7 @@
>          * and its corresponding CertId.
>          *
>          * @param subjectCert the certificate to be checked for revocation
> -         * @param cid the CertId for {@code subjectCert}
> +         * @param certId the CertId for {@code subjectCert}
>          */
>         StatusInfo(X509Certificate subjectCert, CertId certId) {
>             cert = subjectCert;
> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -193,7 +193,7 @@
>     /**
>      * Constructs an object to store the response to a timestamp request.
>      *
> -     * @param status A buffer containing the ASN.1 BER encoded response.
> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>      * @throws IOException The exception is thrown if a problem is encountered
>      *         parsing the timestamp response.
>      */
> 
> 
>>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> Why assume something that sophisticated where it can be adequately explained by
>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>> 
>>>> -Pavel
>>> 
>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>> 
>>>> 
>>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>> 
>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>> Hi Pavel,
>>>>>> 
>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>> nor imported
>>>>>> 
>>>>>> Hopefully that's only on internal classes.
>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>> 
>>>>> -Alan
>>>> 
>>> 
>>> Regards,
>>> Vipin
>> 
> Regards,
> Vipin



From sean.mullan at oracle.com  Mon Apr 13 17:00:14 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 13 Apr 2020 13:00:14 -0400
Subject: RFR: 8242565: Policy initialization issues when the denyAfter
 constraint is enabled
Message-ID: <35ed690e-7b2a-c3f1-e940-f3f782cdf3af@oracle.com>

When a SecurityManager is enabled, early code paths that involve 
ServiceLoader (SL) can trigger permission checks that cause parsing of a 
custom policy file to fail due to recursive processing of the policy file.

I have fixed two of these issues which can occur under the following 
conditions:

1. SecurityManager enabled
2. Signed JAR on the classpath
3. Policy file granting permission based on who signed jar and a 
keystore entry containing the alias/key
4. Code triggering a permission check based on that grant
5. A SHA-1 denyAfter constraint set in the jdk.jar.disabledAlgorithms 
property in the java.security file

Parsing of the denyAfter constraint is required to verify the signed 
JAR, which happens very early. This causes SL to search for a 
LocaleProvider to parse the denyAfter date field which triggers a 
permission check, causes the policy machinery to bootstrap, and which 
triggers further permission checks, etc.

The first issue is that PKCS12KeyStore is unable to verify the integrity 
of the keystore entry in the custom policy file because it cannot find a 
"PBE" AlgorithmParameters implementation. I fixed this by adding 
"SunJCE" to the list of providers that are automatically installed 
during signed JAR verification.

The second issue is also in PKCS12 KeyStore where it tries to 
instantiate a java.text.Collator which also uses SL and thus triggers a 
recursive permission check. This was fixed by using a lazy 
initialization Holder pattern.

webrev: https://cr.openjdk.java.net/~mullan/webrevs/8242565/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8242565

More details and stack traces can be found in the bug.

Thanks,
Sean


From weijun.wang at oracle.com  Tue Apr 14 07:27:09 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 14 Apr 2020 15:27:09 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
Message-ID: <71D8C1A1-AB3A-49D4-A7D4-C4C282864804@oracle.com>

After some discussion, we decide to keep the classes in JDK 15 but add a `forRemoval=true` argument. Related jarsigner help screen and warning message are also updated.

Please review everything updated at:

  Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
           CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
        webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.01/ (a new URL!)

Thanks,
Max

> On Apr 7, 2020, at 4:04 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
> 
>            JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
> 
> Please review everything at:
> 
>   Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>            CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>         webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
> 
> The CSR "Problem" section has more info on why it's better to remove it now.
> 
> Thanks,
> Max
> 



From weijun.wang at oracle.com  Tue Apr 14 12:12:09 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 14 Apr 2020 20:12:09 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <71D8C1A1-AB3A-49D4-A7D4-C4C282864804@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
 <71D8C1A1-AB3A-49D4-A7D4-C4C282864804@oracle.com>
Message-ID: <D8A429C0-DE9B-4675-B093-88AE85053B4D@oracle.com>

mach5 passed.

> On Apr 14, 2020, at 3:27 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> After some discussion, we decide to keep the classes in JDK 15 but add a `forRemoval=true` argument. Related jarsigner help screen and warning message are also updated.
> 
> Please review everything updated at:
> 
>  Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>           CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>        webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.01/ (a new URL!)
> 
> Thanks,
> Max
> 
>> On Apr 7, 2020, at 4:04 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>> 
>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>> 
>>           JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>> 
>> Please review everything at:
>> 
>>  Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>           CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>        webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>> 
>> The CSR "Problem" section has more info on why it's better to remove it now.
>> 
>> Thanks,
>> Max
>> 
> 



From valerie.peng at oracle.com  Tue Apr 14 18:33:58 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 14 Apr 2020 11:33:58 -0700
Subject: [15] RFR JDK-8242556 "Cannot load RSASSA-PSS public key with non-null
 params from byte array"
Message-ID: <489f60c6-672e-cb0b-41dd-742bee049f1d@oracle.com>


Can someone help reviewing this trivial fix? The fix is to change 
AlgorithmId.java to use the algorithm name over the object identifier 
string when looking up impls for DER encoding parsing.

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

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

Mach5 test result is clean.

Thanks,
Valerie


From sean.mullan at oracle.com  Tue Apr 14 19:58:38 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 14 Apr 2020 15:58:38 -0400
Subject: [15] RFR JDK-8242556 "Cannot load RSASSA-PSS public key with
 non-null params from byte array"
In-Reply-To: <489f60c6-672e-cb0b-41dd-742bee049f1d@oracle.com>
References: <489f60c6-672e-cb0b-41dd-742bee049f1d@oracle.com>
Message-ID: <b9ac58ed-7032-2dd4-34a4-cc64dc893f8b@oracle.com>

Looks fine to me.

--Sean

On 4/14/20 2:33 PM, Valerie Peng wrote:
> 
> Can someone help reviewing this trivial fix? The fix is to change 
> AlgorithmId.java to use the algorithm name over the object identifier 
> string when looking up impls for DER encoding parsing.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8242556
> 
> Webrev: http://cr.openjdk.java.net/~valeriep/8242556/webrev.00/
> 
> Mach5 test result is clean.
> 
> Thanks,
> Valerie


From michael.osipov at siemens.com  Tue Apr 14 21:09:03 2020
From: michael.osipov at siemens.com (Osipov, Michael)
Date: Tue, 14 Apr 2020 23:09:03 +0200
Subject: sun.security.spnego.msinterop does not work anymore/disable by
 default for 15
Message-ID: <c6a7624f-e31f-1aca-f4c0-0dc0264de2e4@siemens.com>

Hi Max,

I have just wasted an entire day to make the following observation:

Running Java 8u242, SPNEGO acceptor via HTTP. SSPI clients constantly 
report: SEC_E_INVALID_TOKEN. Tried with Java via JNA, Java via new SSPI 
Bridge, Python SSPI Negotiate module. Regardless of what I do the token 
generated by Java is invalid for the initiator.
I am running a Windows 10 client on my desktop.
A MIT Kerberos acceptor reponds:
 > 
oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuixaQG7nwXC0uiguOl256srmAhgjVD9A5OgHQ+fXdJ03zNMQhLu2ly93WzHfUxaDOKZPS5Wkfz1NHVyRMiYcS7EwzYg+c97Q0aYOLqcQG+0j3pGVHFWzEyMZW4OoWOD6avnX9dI+oDE

An ASN.1 sequence with three members. Java, SSPI, MIT Kerberos accept 
this one.

JGSS responds:
 > 
oYHzMIHwoAMKAQChCwYJKoZIgvcSAQICom0Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQT2FosuhMJoIXpAw4GyGADOfD7bsyPGfNAvUV1kKJGqR/0X+2rzby4XU5qWYypCT4asVvlw6LkWbK79P6vaT5vCQo20Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQT2FosuhMJoIXpAw4GyGADOfD7bsyPGfNAvUV1kKJGqR/0X+2rzby4XU5qWYypCT4asVvlw6LkWbK79P6vaT5vCQ

Sequence has four members. The last two members are the encrypted 
response token twice(!). Java and MIT Kerberos accept this, SSPI rejects.

After poking around for hours I have found 
sun.security.spnego.msinterop. As soon as this one is set to false 
(default: true). Following token is genereated:
 > 
oYGEMIGBoAMKAQChCwYJKoZIgvcSAQICom0Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQRS9XZ5wjfA5wj832Zs9pufcP6IRArfBgG6/2XiU/vv2++i1vK/kmhc3UIa9X4nb2e7+CgCXV7X1rK30vCHKTeIv

Three members, but the token is almost as twice as small as the one from 
MIT Kerberos.

A SSPI acceptor returns:
 > 
oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuuhFIL4c9Nzov6g93sh5Q81AB2c5nK5ZyQQXcN1TmNaCDjsdn9irTnui7NO3ogemrrUO6sRT2A7hB01mwvY23ZVetNaQ/DCmnI8q2ATppcFf9yUPRNDZ8Gqg2FlKSTeusK5fcFQOjZmmxXB1vbRo=

three members and 110 bytes just like MIT Kerberos.

Decoded with: https://lapo.it/asn1js

Two important points arise here:
* As far as I remember MIT Kerberos never returned anything else. This 
hack does not work for SSPI initiators anymore, at least here on Windows 
10. File an issue with JBS? Request to set to false for 15, reqeust 
backport and document it?
* Why is the token as twice as small?

Michael


From valerie.peng at oracle.com  Tue Apr 14 22:52:40 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 14 Apr 2020 15:52:40 -0700
Subject: RFR Release Note for JDK-8172680 "Support SHA-3 based Hmac algorithms"
Message-ID: <5af9f491-eb27-8898-4b7e-e8aa5006fc5a@oracle.com>

The changes have been integrated. This is a sub-task for the 
release-note update.

Could someone help review the release note wording?

It's at https://bugs.openjdk.java.net/browse/JDK-8241326

Thanks,
Valerie




From xuelei.fan at oracle.com  Wed Apr 15 03:42:17 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 14 Apr 2020 20:42:17 -0700
Subject: RFR [15] JDK-8242145, New System Properties to configure the TLS
 signature schemes
In-Reply-To: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
References: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
Message-ID: <b9140dc0-f380-f971-7ee6-1682ac7a6036@oracle.com>

ping ...

On 4/3/2020 4:13 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed?
> 
> Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
> CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
> Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147
> 
> A third party's TLS implementation may not be able to handle a certain 
> signature schemes, and cannot interop with JDK.? Although the 
> implementation does not comply to TLS specifications, the impact could 
> be significant if an application that uses the implementation is popular.
> 
> Thanks,
> Xuelei


From jamil.j.nimeh at oracle.com  Wed Apr 15 05:03:45 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 14 Apr 2020 22:03:45 -0700
Subject: RFR [15] JDK-8242145, New System Properties to configure the TLS
 signature schemes
In-Reply-To: <b9140dc0-f380-f971-7ee6-1682ac7a6036@oracle.com>
References: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
 <b9140dc0-f380-f971-7ee6-1682ac7a6036@oracle.com>
Message-ID: <adb35d96-5bc8-93f5-c7c3-54d55214da3b@oracle.com>

Looks pretty good, a couple questions/comments:

  * SSLConfiguration.java
      o Line 471-473: Does the call to SignatureScheme.nameOf(String)
        ever throw IAE?? I don't see anything in the for-each loop in
        that method that would.
  * CustomizedClientSchemes and CustomizedServerSchemes
      o Line 44 (both): Just a nit, but the comment looks like it was
        lifted from a different test and should be changed to reflect
        that your forcing a single signature scheme.

--Jamil

On 4/14/2020 8:42 PM, Xuelei Fan wrote:
> ping ...
>
> On 4/3/2020 4:13 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the following update reviewed?
>>
>> Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147
>>
>> A third party's TLS implementation may not be able to handle a 
>> certain signature schemes, and cannot interop with JDK. Although the 
>> implementation does not comply to TLS specifications, the impact 
>> could be significant if an application that uses the implementation 
>> is popular.
>>
>> Thanks,
>> Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200414/692d4419/attachment.htm>

From jamil.j.nimeh at oracle.com  Wed Apr 15 05:38:43 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 14 Apr 2020 22:38:43 -0700
Subject: [RFR] 8242008: SSLSession inconsistencies
In-Reply-To: <045b8097-9031-0115-130b-0fcdf5f3bffb@oracle.com>
References: <045b8097-9031-0115-130b-0fcdf5f3bffb@oracle.com>
Message-ID: <88315223-fe14-af71-7e6e-75b9af49defd@oracle.com>

Hi Tony, this looks good to me.

--Jamil

On 4/8/2020 1:18 PM, Anthony Scarpino wrote:
> Hi,
>
> I'd like a review of the following change.? There wre inconsistencies 
> with SSLSession and session caching that needed to be fixed.? They are:
> - With stateless resumption, SSLSession.getSessionContext() would 
> return null.
> - TLS 1.3 w/ session cache, the initial session was being added to the 
> cache unnecessarily.
> - With stateless resumption, SSLSession getPeerHost() could return 
> corrupted.
>
> A test is included for getSessionContext
>
> https://cr.openjdk.java.net/~ascarpino/8242008/webrev.01/
>
> thanks
>
> Tony


From xuelei.fan at oracle.com  Wed Apr 15 05:41:03 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 14 Apr 2020 22:41:03 -0700
Subject: [RFR] 8242008: SSLSession inconsistencies
In-Reply-To: <045b8097-9031-0115-130b-0fcdf5f3bffb@oracle.com>
References: <045b8097-9031-0115-130b-0fcdf5f3bffb@oracle.com>
Message-ID: <67a85b81-3c7f-1959-0a57-1d13f2a21800@oracle.com>

It looks good to me.

Nice to see a a new template!

Thanks,
Xuelei

On 4/8/2020 1:18 PM, Anthony Scarpino wrote:
> Hi,
> 
> I'd like a review of the following change.? There wre inconsistencies 
> with SSLSession and session caching that needed to be fixed.? They are:
> - With stateless resumption, SSLSession.getSessionContext() would return 
> null.
> - TLS 1.3 w/ session cache, the initial session was being added to the 
> cache unnecessarily.
> - With stateless resumption, SSLSession getPeerHost() could return 
> corrupted.
> 
> A test is included for getSessionContext
> 
> https://cr.openjdk.java.net/~ascarpino/8242008/webrev.01/
> 
> thanks
> 
> Tony


From weijun.wang at oracle.com  Wed Apr 15 07:30:23 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 15 Apr 2020 15:30:23 +0800
Subject: RFR: 8242565: Policy initialization issues when the denyAfter
 constraint is enabled
In-Reply-To: <35ed690e-7b2a-c3f1-e940-f3f782cdf3af@oracle.com>
References: <35ed690e-7b2a-c3f1-e940-f3f782cdf3af@oracle.com>
Message-ID: <83CC4665-0E5F-48A5-B353-7E06231D39E7@oracle.com>



> On Apr 14, 2020, at 1:00 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> When a SecurityManager is enabled, early code paths that involve ServiceLoader (SL) can trigger permission checks that cause parsing of a custom policy file to fail due to recursive processing of the policy file.
> 
> I have fixed two of these issues which can occur under the following conditions:
> 
> 1. SecurityManager enabled
> 2. Signed JAR on the classpath
> 3. Policy file granting permission based on who signed jar and a keystore entry containing the alias/key
> 4. Code triggering a permission check based on that grant
> 5. A SHA-1 denyAfter constraint set in the jdk.jar.disabledAlgorithms property in the java.security file
> 
> Parsing of the denyAfter constraint is required to verify the signed JAR, which happens very early. This causes SL to search for a LocaleProvider to parse the denyAfter date field which triggers a permission check, causes the policy machinery to bootstrap, and which triggers further permission checks, etc.
> 
> The first issue is that PKCS12KeyStore is unable to verify the integrity of the keystore entry in the custom policy file because it cannot find a "PBE" AlgorithmParameters implementation. I fixed this by adding "SunJCE" to the list of providers that are automatically installed during signed JAR verification.
> 
> The second issue is also in PKCS12 KeyStore where it tries to instantiate a java.text.Collator which also uses SL and thus triggers a recursive permission check. This was fixed by using a lazy initialization Holder pattern.

Can we just add a "collator" argument to the getPassWithModifier() method? This looks ugly but we already have "rb".

Thanks,
Max

> 
> webrev: https://cr.openjdk.java.net/~mullan/webrevs/8242565/webrev.00/
> bug: https://bugs.openjdk.java.net/browse/JDK-8242565
> 
> More details and stack traces can be found in the bug.
> 
> Thanks,
> Sean



From weijun.wang at oracle.com  Wed Apr 15 10:34:44 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 15 Apr 2020 18:34:44 +0800
Subject: RFR 8242811: AlgorithmId::getDefaultAlgorithmParameterSpec returns
 incompatible PSSParameterSpec for an RSASSA-PSS key
Message-ID: <3717A440-6386-4D8E-B88A-957C7F6480FD@oracle.com>

Please take a review at

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

The AlgorithmId::getDefaultAlgorithmParameterSpec method is used internally to retrieve a default AlgorithmParameterSpec to initialize a Signature, mainly be keytool.

The test shows a case where it can be called.

Thanks,
Max



From weijun.wang at oracle.com  Wed Apr 15 12:28:34 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 15 Apr 2020 20:28:34 +0800
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
In-Reply-To: <556d9277-925c-aa9f-3281-327f36300977@oracle.com>
References: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
 <556d9277-925c-aa9f-3281-327f36300977@oracle.com>
Message-ID: <65EFCF37-164B-4008-8DF9-8C43E4C94977@oracle.com>


> On Apr 9, 2020, at 3:46 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 4/6/20 11:11 PM, Weijun Wang wrote:
>> Please review the fix at
>>    http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
>> The major change is inside X509CRLImpl.java to allow params setting and reading.
>> I also take this chance to:
>> 1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".
> 
> I think you should file a CSR for that, since it is a new default, and the default varies based on the size of the key. You should also update the keytool man page section on defaults.

I've filed a CSR at https://bugs.openjdk.java.net/browse/JDK-8242812. Please take a review.

Here, actually when the key is RSASSA-PSS, the default signature is simply RSASSA-PSS, and its parameters will take the same from the key itself, and not related to the key size.

Thanks,
Max

> 
> --Sean
> 
>> 2. Revert a former change in X509CertImpl.java, which might be a safer call.
>> Thanks,
>> Max



From sean.mullan at oracle.com  Wed Apr 15 13:31:30 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 15 Apr 2020 09:31:30 -0400
Subject: RFR Release Note for JDK-8172680 "Support SHA-3 based Hmac
 algorithms"
In-Reply-To: <5af9f491-eb27-8898-4b7e-e8aa5006fc5a@oracle.com>
References: <5af9f491-eb27-8898-4b7e-e8aa5006fc5a@oracle.com>
Message-ID: <95e27f39-da85-04d5-160d-1ab97141f85e@oracle.com>

Looks good to me.

--Sean

On 4/14/20 6:52 PM, Valerie Peng wrote:
> The changes have been integrated. This is a sub-task for the 
> release-note update.
> 
> Could someone help review the release note wording?
> 
> It's at https://bugs.openjdk.java.net/browse/JDK-8241326
> 
> Thanks,
> Valerie
> 
> 


From weijun.wang at oracle.com  Wed Apr 15 13:41:16 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 15 Apr 2020 21:41:16 +0800
Subject: sun.security.spnego.msinterop does not work anymore/disable by
 default for 15
In-Reply-To: <c6a7624f-e31f-1aca-f4c0-0dc0264de2e4@siemens.com>
References: <c6a7624f-e31f-1aca-f4c0-0dc0264de2e4@siemens.com>
Message-ID: <5B294418-DBEF-451B-8EDF-45D4A3A5B5C7@oracle.com>

I don't know about the history, but it looks like the original author believes that for MS interop a NegTokenTarg should have the same bytes in reponseToken and mechListMIC (this is weird of course). It has been working before, maybe because the client never looks into the mechListMIC or maybe it does like it being this style.

So the extra size is the mechListMIC token.

Since JDK 13, we don't duplicate the reponseToken into mechListMIC anymore. But we still use this system property to determine whether to fill in that field. By default, no; when set to false, add and verify it. If I understand SPNEGO correctly, the field can be missing if the acceptor only understand one mechanism, which is the case with JDK.

Have you tried JDK 13 or newer to see if the default works?

Thanks,
Max

> On Apr 15, 2020, at 5:09 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
> 
> Hi Max,
> 
> I have just wasted an entire day to make the following observation:
> 
> Running Java 8u242, SPNEGO acceptor via HTTP. SSPI clients constantly report: SEC_E_INVALID_TOKEN. Tried with Java via JNA, Java via new SSPI Bridge, Python SSPI Negotiate module. Regardless of what I do the token generated by Java is invalid for the initiator.
> I am running a Windows 10 client on my desktop.
> A MIT Kerberos acceptor reponds:
> > oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuixaQG7nwXC0uiguOl256srmAhgjVD9A5OgHQ+fXdJ03zNMQhLu2ly93WzHfUxaDOKZPS5Wkfz1NHVyRMiYcS7EwzYg+c97Q0aYOLqcQG+0j3pGVHFWzEyMZW4OoWOD6avnX9dI+oDE
> 
> An ASN.1 sequence with three members. Java, SSPI, MIT Kerberos accept this one.
> 
> JGSS responds:
> > oYHzMIHwoAMKAQChCwYJKoZIgvcSAQICom0Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQT2FosuhMJoIXpAw4GyGADOfD7bsyPGfNAvUV1kKJGqR/0X+2rzby4XU5qWYypCT4asVvlw6LkWbK79P6vaT5vCQo20Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQT2FosuhMJoIXpAw4GyGADOfD7bsyPGfNAvUV1kKJGqR/0X+2rzby4XU5qWYypCT4asVvlw6LkWbK79P6vaT5vCQ
> 
> Sequence has four members. The last two members are the encrypted response token twice(!). Java and MIT Kerberos accept this, SSPI rejects.
> 
> After poking around for hours I have found sun.security.spnego.msinterop. As soon as this one is set to false (default: true). Following token is genereated:
> > oYGEMIGBoAMKAQChCwYJKoZIgvcSAQICom0Ea2BpBgkqhkiG9xIBAgICAG9aMFigAwIBBaEDAgEPokwwSqADAgESokMEQRS9XZ5wjfA5wj832Zs9pufcP6IRArfBgG6/2XiU/vv2++i1vK/kmhc3UIa9X4nb2e7+CgCXV7X1rK30vCHKTeIv
> 
> Three members, but the token is almost as twice as small as the one from MIT Kerberos.
> 
> A SSPI acceptor returns:
> > oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuuhFIL4c9Nzov6g93sh5Q81AB2c5nK5ZyQQXcN1TmNaCDjsdn9irTnui7NO3ogemrrUO6sRT2A7hB01mwvY23ZVetNaQ/DCmnI8q2ATppcFf9yUPRNDZ8Gqg2FlKSTeusK5fcFQOjZmmxXB1vbRo=
> 
> three members and 110 bytes just like MIT Kerberos.
> 
> Decoded with: https://lapo.it/asn1js
> 
> Two important points arise here:
> * As far as I remember MIT Kerberos never returned anything else. This hack does not work for SSPI initiators anymore, at least here on Windows 10. File an issue with JBS? Request to set to false for 15, reqeust backport and document it?
> * Why is the token as twice as small?
> 
> Michael



From sean.mullan at oracle.com  Wed Apr 15 15:29:12 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 15 Apr 2020 11:29:12 -0400
Subject: RFR: 8242565: Policy initialization issues when the denyAfter
 constraint is enabled
In-Reply-To: <83CC4665-0E5F-48A5-B353-7E06231D39E7@oracle.com>
References: <35ed690e-7b2a-c3f1-e940-f3f782cdf3af@oracle.com>
 <83CC4665-0E5F-48A5-B353-7E06231D39E7@oracle.com>
Message-ID: <9f3d92b2-c85e-a26e-b8d2-aacdcd15cf3d@oracle.com>

On 4/15/20 3:30 AM, Weijun Wang wrote:
> 
> 
>> On Apr 14, 2020, at 1:00 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> When a SecurityManager is enabled, early code paths that involve ServiceLoader (SL) can trigger permission checks that cause parsing of a custom policy file to fail due to recursive processing of the policy file.
>>
>> I have fixed two of these issues which can occur under the following conditions:
>>
>> 1. SecurityManager enabled
>> 2. Signed JAR on the classpath
>> 3. Policy file granting permission based on who signed jar and a keystore entry containing the alias/key
>> 4. Code triggering a permission check based on that grant
>> 5. A SHA-1 denyAfter constraint set in the jdk.jar.disabledAlgorithms property in the java.security file
>>
>> Parsing of the denyAfter constraint is required to verify the signed JAR, which happens very early. This causes SL to search for a LocaleProvider to parse the denyAfter date field which triggers a permission check, causes the policy machinery to bootstrap, and which triggers further permission checks, etc.
>>
>> The first issue is that PKCS12KeyStore is unable to verify the integrity of the keystore entry in the custom policy file because it cannot find a "PBE" AlgorithmParameters implementation. I fixed this by adding "SunJCE" to the list of providers that are automatically installed during signed JAR verification.
>>
>> The second issue is also in PKCS12 KeyStore where it tries to instantiate a java.text.Collator which also uses SL and thus triggers a recursive permission check. This was fixed by using a lazy initialization Holder pattern.
> 
> Can we just add a "collator" argument to the getPassWithModifier() method? This looks ugly but we already have "rb".

I think that is a fine suggestion, especially since keytool and 
jarsigner (the only code that calls KeyStoreUtil.getPassWithModifier()) 
already cache a static Collator instance. New webrev:

https://cr.openjdk.java.net/~mullan/webrevs/8242565/webrev.01/

--Sean





From pavel.rappo at oracle.com  Wed Apr 15 11:06:46 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 15 Apr 2020 12:06:46 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
 <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
Message-ID: <CC6D3DE3-DEB3-44B1-8C5A-7E89ECE19880@oracle.com>

Vipin,

I saw that Max had already reviewed that incremental patch. That's good.

I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu
(International Components for Unicode) package. Once this has been cleared by
experts in that area, we are good to go.

Here's the cumulative webrev:

    http://cr.openjdk.java.net/~prappo/8242366/webrev.01/

-Pavel

> On 11 Apr 2020, at 20:23, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
> 
> Hi Pavel,
> 
>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> If your new patch addresses a similar type of problem, please send it in reply to this email,
>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>> 
> This is additional patch:
> 
> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
> @@ -142,7 +142,7 @@
>        /**
>         * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>         * data the index array offset of the indexes for that lead surrogate.
> -        * @param property data value for a surrogate from the trie, including
> +        * @param value data value for a surrogate from the trie, including
>         *        the folding offset
>         * @return data offset or 0 if there is no data for the lead surrogate
>         */
> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -39,7 +39,7 @@
> 
>     /**
>      * Calls FilterInputStream's constructor.
> -     * @param an InputStream
> +     * @param is an InputStream
>      */
>     PlainTextInputStream(InputStream is) {
>         super(is);
> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -881,7 +881,7 @@
>      * only CRLs signed with a different key (but the same issuer
>      * name) as the certificate being checked.
>      *
> -     * @param currCert the <code>X509Certificate</code> to be checked
> +     * @param cert the <code>X509Certificate</code> to be checked
>      * @param prevKey the <code>PublicKey</code> that failed
>      * @param signFlag <code>true</code> if that key was trusted to sign CRLs
>      * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -166,7 +166,7 @@
>     /**
>      * Creates a URICertStore.
>      *
> -     * @param parameters specifying the URI
> +     * @param params parameters specifying the URI
>      */
>     URICertStore(CertStoreParameters params)
>         throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -483,7 +483,7 @@
>          * and its corresponding CertId.
>          *
>          * @param subjectCert the certificate to be checked for revocation
> -         * @param cid the CertId for {@code subjectCert}
> +         * @param certId the CertId for {@code subjectCert}
>          */
>         StatusInfo(X509Certificate subjectCert, CertId certId) {
>             cert = subjectCert;
> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -193,7 +193,7 @@
>     /**
>      * Constructs an object to store the response to a timestamp request.
>      *
> -     * @param status A buffer containing the ASN.1 BER encoded response.
> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>      * @throws IOException The exception is thrown if a problem is encountered
>      *         parsing the timestamp response.
>      */
> 
> 
>>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> Why assume something that sophisticated where it can be adequately explained by
>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>> 
>>>> -Pavel
>>> 
>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>> 
>>>> 
>>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>> 
>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>> Hi Pavel,
>>>>>> 
>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>> nor imported
>>>>>> 
>>>>>> Hopefully that's only on internal classes.
>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>> 
>>>>> -Alan
>>>> 
>>> 
>>> Regards,
>>> Vipin
>> 
> Regards,
> Vipin
> 



From anthony.scarpino at oracle.com  Wed Apr 15 16:24:51 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 15 Apr 2020 09:24:51 -0700
Subject: RFR [15] JDK-8242145, New System Properties to configure the TLS
 signature schemes
In-Reply-To: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
References: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
Message-ID: <f913d4e1-72ab-0fbf-54e8-2b93a113d21f@oracle.com>

On 4/3/20 4:13 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed?
> 
> Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
> CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
> Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147
> 
> A third party's TLS implementation may not be able to handle a certain 
> signature schemes, and cannot interop with JDK.? Although the 
> implementation does not comply to TLS specifications, the impact could 
> be significant if an application that uses the implementation is popular.
> 
> Thanks,
> Xuelei

The CSR looks fine to me.

Tony



From xuelei.fan at oracle.com  Wed Apr 15 16:41:30 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 15 Apr 2020 09:41:30 -0700
Subject: RFR [15] JDK-8242145, New System Properties to configure the TLS
 signature schemes
In-Reply-To: <adb35d96-5bc8-93f5-c7c3-54d55214da3b@oracle.com>
References: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
 <b9140dc0-f380-f971-7ee6-1682ac7a6036@oracle.com>
 <adb35d96-5bc8-93f5-c7c3-54d55214da3b@oracle.com>
Message-ID: <0f417421-3c40-40be-4661-a04480a6ffbe@oracle.com>

All good catches.  The webrev was updated accordingly:
   Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/

Xuelei

On 4/14/2020 10:03 PM, Jamil Nimeh wrote:
> Looks pretty good, a couple questions/comments:
> 
>   * SSLConfiguration.java
>       o Line 471-473: Does the call to SignatureScheme.nameOf(String)
>         ever throw IAE?? I don't see anything in the for-each loop in
>         that method that would.
>   * CustomizedClientSchemes and CustomizedServerSchemes
>       o Line 44 (both): Just a nit, but the comment looks like it was
>         lifted from a different test and should be changed to reflect
>         that your forcing a single signature scheme.
> 
> --Jamil
> 
> On 4/14/2020 8:42 PM, Xuelei Fan wrote:
>> ping ...
>>
>> On 4/3/2020 4:13 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the following update reviewed?
>>>
>>> Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
>>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147
>>>
>>> A third party's TLS implementation may not be able to handle a 
>>> certain signature schemes, and cannot interop with JDK. Although the 
>>> implementation does not comply to TLS specifications, the impact 
>>> could be significant if an application that uses the implementation 
>>> is popular.
>>>
>>> Thanks,
>>> Xuelei


From jamil.j.nimeh at oracle.com  Wed Apr 15 17:02:10 2020
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 15 Apr 2020 10:02:10 -0700
Subject: RFR [15] JDK-8242145, New System Properties to configure the TLS
 signature schemes
In-Reply-To: <0f417421-3c40-40be-4661-a04480a6ffbe@oracle.com>
References: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
 <b9140dc0-f380-f971-7ee6-1682ac7a6036@oracle.com>
 <adb35d96-5bc8-93f5-c7c3-54d55214da3b@oracle.com>
 <0f417421-3c40-40be-4661-a04480a6ffbe@oracle.com>
Message-ID: <ba37da56-1ecb-c7a0-e6a6-27a7451432b5@oracle.com>

Looks good!

--Jamil

On 4/15/2020 9:41 AM, Xuelei Fan wrote:
> All good catches.? The webrev was updated accordingly:
> ? Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
>
> Xuelei
>
> On 4/14/2020 10:03 PM, Jamil Nimeh wrote:
>> Looks pretty good, a couple questions/comments:
>>
>> ? * SSLConfiguration.java
>> ????? o Line 471-473: Does the call to SignatureScheme.nameOf(String)
>> ??????? ever throw IAE?? I don't see anything in the for-each loop in
>> ??????? that method that would.
>> ? * CustomizedClientSchemes and CustomizedServerSchemes
>> ????? o Line 44 (both): Just a nit, but the comment looks like it was
>> ??????? lifted from a different test and should be changed to reflect
>> ??????? that your forcing a single signature scheme.
>>
>> --Jamil
>>
>> On 4/14/2020 8:42 PM, Xuelei Fan wrote:
>>> ping ...
>>>
>>> On 4/3/2020 4:13 PM, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Could I get the following update reviewed?
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
>>>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147
>>>>
>>>> A third party's TLS implementation may not be able to handle a 
>>>> certain signature schemes, and cannot interop with JDK. Although 
>>>> the implementation does not comply to TLS specifications, the 
>>>> impact could be significant if an application that uses the 
>>>> implementation is popular.
>>>>
>>>> Thanks,
>>>> Xuelei


From sean.mullan at oracle.com  Wed Apr 15 18:40:30 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 15 Apr 2020 14:40:30 -0400
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <71D8C1A1-AB3A-49D4-A7D4-C4C282864804@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
 <71D8C1A1-AB3A-49D4-A7D4-C4C282864804@oracle.com>
Message-ID: <7f09ad12-7c89-5027-beb4-d955ca4ed469@oracle.com>

On 4/14/20 3:27 AM, Weijun Wang wrote:
> After some discussion, we decide to keep the classes in JDK 15 but add a `forRemoval=true` argument. Related jarsigner help screen and warning message are also updated.
> 
> Please review everything updated at:
> 
>    Release note : https://bugs.openjdk.java.net/browse/JDK-8242261

Reviewed. I think it is probably better to flag this with an 
RN-Deprecated label since this is about marking it for removal and will 
show up in a section of the release notes about deprecation. You could 
check with others on this though.

>             CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>          webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.01/ (a new URL!)

- add 2020 date to copyright in package-info.java

- Resources.java:

  94 
{".altsigner.class.class.name.of.an.alternative.signing.mechanism",
   95                 "[-altsigner <class>]        class name of an 
alternative signing mechanism\n" +
   96                 "                            (This option has been 
deprecated and will be removed in a future release.)"},
   97 
{".altsignerpath.pathlist.location.of.an.alternative.signing.mechanism",
   98                 "[-altsignerpath <pathlist>] location of an 
alternative signing mechanism\n" +
   99                 "                            (This option has been 
deprecated and will be removed in a future release.)"},

I would change "has been deprecated" to "is deprecated" which is 
consistent with the "This.option.is.forremoval" message and seems a bit 
clearer.

--Sean

> 
> Thanks,
> Max
> 
>> On Apr 7, 2020, at 4:04 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>
>>             JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>
>> Please review everything at:
>>
>>    Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>             CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>          webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>
>> The CSR "Problem" section has more info on why it's better to remove it now.
>>
>> Thanks,
>> Max
>>
> 


From sean.mullan at oracle.com  Wed Apr 15 19:44:28 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 15 Apr 2020 15:44:28 -0400
Subject: RFR [15] JDK-8242145, New System Properties to configure the TLS
 signature schemes
In-Reply-To: <b9140dc0-f380-f971-7ee6-1682ac7a6036@oracle.com>
References: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
 <b9140dc0-f380-f971-7ee6-1682ac7a6036@oracle.com>
Message-ID: <6e00f6be-0c91-a9bc-d53b-550c7442850b@oracle.com>

Should the CSR say what the default schemes are if the properties are 
not set? Also, are the schemes case-insensitive? Also, what is the 
behavior if there are syntax errors (ex: not using a comma) in the format?

--Sean

On 4/14/20 11:42 PM, Xuelei Fan wrote:
> ping ...
> 
> On 4/3/2020 4:13 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the following update reviewed?
>>
>> Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147
>>
>> A third party's TLS implementation may not be able to handle a certain 
>> signature schemes, and cannot interop with JDK.? Although the 
>> implementation does not comply to TLS specifications, the impact could 
>> be significant if an application that uses the implementation is popular.
>>
>> Thanks,
>> Xuelei


From xuelei.fan at oracle.com  Wed Apr 15 20:56:03 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 15 Apr 2020 13:56:03 -0700
Subject: RFR [15] JDK-8242145, New System Properties to configure the TLS
 signature schemes
In-Reply-To: <6e00f6be-0c91-a9bc-d53b-550c7442850b@oracle.com>
References: <7bb28663-a1db-52eb-0570-35f900a71fcf@oracle.com>
 <b9140dc0-f380-f971-7ee6-1682ac7a6036@oracle.com>
 <6e00f6be-0c91-a9bc-d53b-550c7442850b@oracle.com>
Message-ID: <71ac6a59-c195-2d78-f75a-52e0ecf3bf0a@oracle.com>

On 4/15/2020 12:44 PM, Sean Mullan wrote:
> Should the CSR say what the default schemes are if the properties are 
> not set?
I added the default value sections.

> Also, are the schemes case-insensitive?
Standard names are not case-sensitive, per the Standard Algorithm Names 
Specification.  I added notes in the CSR.

> Also, what is the 
> behavior if there are syntax errors (ex: not using a comma) in the format?
> 
It was stated that "Unrecognized or unsupported signature scheme names 
specified in the property are ignored".

Thanks,
Xuelei

> --Sean
> 
> On 4/14/20 11:42 PM, Xuelei Fan wrote:
>> ping ...
>>
>> On 4/3/2020 4:13 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the following update reviewed?
>>>
>>> Webrev: http://cr.openjdk.java.net/~xuelei/8242145/webrev.00/
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242141
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8242145
>>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8242147
>>>
>>> A third party's TLS implementation may not be able to handle a 
>>> certain signature schemes, and cannot interop with JDK.? Although the 
>>> implementation does not comply to TLS specifications, the impact 
>>> could be significant if an application that uses the implementation 
>>> is popular.
>>>
>>> Thanks,
>>> Xuelei


From michael.osipov at siemens.com  Wed Apr 15 21:10:15 2020
From: michael.osipov at siemens.com (Osipov, Michael)
Date: Wed, 15 Apr 2020 23:10:15 +0200
Subject: sun.security.spnego.msinterop does not work anymore/disable by
 default for 15
In-Reply-To: <5B294418-DBEF-451B-8EDF-45D4A3A5B5C7@oracle.com>
References: <c6a7624f-e31f-1aca-f4c0-0dc0264de2e4@siemens.com>
 <5B294418-DBEF-451B-8EDF-45D4A3A5B5C7@oracle.com>
Message-ID: <39457c93-9343-fa19-dd37-f87613e73ccf@siemens.com>

Max,

Am 2020-04-15 um 15:41 schrieb Weijun Wang:
> I don't know about the history, but it looks like the original author believes that for MS interop a NegTokenTarg should have the same bytes in reponseToken and mechListMIC (this is weird of course). It has been working before, maybe because the client never looks into the mechListMIC or maybe it does like it being this style.
> 
> So the extra size is the mechListMIC token.
> 
> Since JDK 13, we don't duplicate the reponseToken into mechListMIC anymore. But we still use this system property to determine whether to fill in that field. By default, no; when set to false, add and verify it. If I understand SPNEGO correctly, the field can be missing if the acceptor only understand one mechanism, which is the case with JDK.
> 
> Have you tried JDK 13 or newer to see if the default works?

Can you point to the JBS causing that change? Going through log on 
AdoptOpenJDK 13u doesn't show any change in that area.

I have tried

> # /usr/local/openjdk13/bin/java -version
> openjdk version "13.0.2" 2020-01-14
> OpenJDK Runtime Environment (build 13.0.2+8-1)
> OpenJDK 64-Bit Server VM (build 13.0.2+8-1, mixed mode)

and

> # /usr/local/openjdk14/bin/java -version
> openjdk version "14" 2020-03-17
> OpenJDK Runtime Environment (build 14+36-1)
> OpenJDK 64-Bit Server VM (build 14+36-1, mixed mode, sharing)

the tweak is not necessary anymore. Funny thing is, regardless of true 
or false, I never get the duplicate token now. I wonder wether the 
property has still any effect. I have tried curl with SSPI on Windows 10 
and curl on FreeBSD with MIT Kerberos.

So since JDK only understands Kerberos where is the point in still 
having this property since you always omit the mechListMIC?

Can you also answer why the new token (sans mechListMIC) is still 
smaller than the one from MIT Kerberos or SSPI?

Michael


From michael.osipov at siemens.com  Wed Apr 15 21:17:09 2020
From: michael.osipov at siemens.com (Osipov, Michael)
Date: Wed, 15 Apr 2020 23:17:09 +0200
Subject: Evaluation part 1 of JDK-6722928: Provide a default native
 GSS-API library on Windows
In-Reply-To: <DB39658A-1B0E-456A-8A1D-34D95F29B9E4@oracle.com>
References: <8e63c57f-68d0-0294-3741-784492b51de1@siemens.com>
 <DB39658A-1B0E-456A-8A1D-34D95F29B9E4@oracle.com>
Message-ID: <fd043267-ad0e-7417-3a0a-3f44eec37022@siemens.com>

Max,

did you get a chance to go through the comments? I'd like to start 
review 2 (interaction) somewhere next week, but would like to sort this 
one out first.

Michael

Am 2020-04-02 um 03:47 schrieb Weijun Wang:
> I'll read this carefully, thanks a lot for the comments.
> 
> --Max
> 
>> On Apr 2, 2020, at 12:21 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
>>
>> Hi Max,
>>
>> at last I took some time to evaluate you SSPI bridge. This is part one. Interaction evaluation will follow in a second email.
>>
>> Assumptions:
>> * All methods, objects behave the same as with JGSS
>> * AcceptSecurityContext is not implemented so should everything associated with it fail (GSSException)
>> * Code analysis happens based on https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/master/src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
>> and zulu13.29.9-ca-jdk13.0.2-win_x64
>>
>> Findings C:
>> * sspi.cpp: Would it make sense to replace "__declspec(dllexport)" with JNIEXPORT?
>> * GSSManager#createCredential(): I'd expect an exception when *not* GSSCredential.INITIATE_ONLY is requested/passed
>> * sspi.cpp#L67-L68: Feels a bit awkward to permit SSPI_BRIDGE_TRACE="". Why not have "if (trace && *trace)"?
>> * sspi.cpp#L233: The function name says "show_oid", but I see no OID printed. Simply symbolic names.
>> * sspi.cpp#L290: Empty string check? like (realm && *realm)
>> * Usage of %p: If you don't know that %p is used it is hard to tell why this output is there. May turn to "at 0x%p" in general?
>> * sspi.cpp#L359: -2!= reads awkward. Reformat?
>> * sspi.cpp#L482-L483: This is highly questionable. While it is true for Windows, it does not stick to gss_compare_name behavior. Don't know what the correct approach would be here.
>> * sspi.cpp#L595: That's weird. A string leads to a length? Should it read: PP("Name found: %ls -> %s [%d]", names, buffer, len)
>> * sspi.cpp#L618: You are resetting cred_usage passed with the function. This looks like a bug to me.
>> * sspi.cpp#L619: Reads very bad, maybe turn into "PP("AcquireCredentialsHandle with usage: %d, creds: 0x%p", cred_usage, desired_mechs)"
>> * sspi.cpp#L627-L633: Trace message could be more expressive, e.g., "Requesting Kerberos mech"
>> * sspi.cpp#L657-L658 and sspi.cpp#L687-L688: They look wrong and do not correspond to GSSCredentialImpl.java#L628-L640. default value should be INITIATE_AND_ACCEPT.
>>   Same as in GSS-API:
>> $ sudo python3
>>> Python 3.7.7 (default, Mar 19 2020, 21:26:00)
>>> [Clang 9.0.1 (git at github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b31 on freebsd12
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> import gssapi
>>>>>> cred = gssapi.Credentials(usage='nonsense')
>>>>>> cred.usage
>>> 'both'
>> This also may be a bug in py-gssapi/MIT Kerberos
>> * sspi.cpp#L149
>> ** Can you apply a better output like ISO 8601? In strftime(3) that would be "%FT%T, ..."
>> ** "%uld" does not seem to work here: 4294967295ld. Shouldn't that read "%"PRIu32" seconds" or "%lu seconds"?
>> * sspi.cpp#L744: "Comparison result: %d". You are not comparing the result, but print comparsion result.
>> * sspi.cpp#L841: man 3 gss_import_sec_context says: GSS_S_UNAVAILABLE
>> * sspi.cpp#L977-L979: Not helpful when the SEC_E_* not mapped to major/minor. This likely applies to most mapping functions.
>> * sspi.cpp#L1012: Maybe: "Names: client: %s, server: %s"?
>> * sspi.cpp#L1046: Maybe like gss_export_sec_context?
>> * sspi.cpp#L1169: Remove word "IMPLEMENTED"
>> * sspi.cpp#L1169: Maybe like gss_export_sec_context?
>> * sspi.cpp#L1480: Includes a trailing, redundant newline
>> * sspi.cpp#L729-L748: Why do you do this? The documentation for parameter 1 says: If the process that requests the handle does not have access to the credentials, the function returns an error. I have verified this with py-win32: win32security.AcquireCredentialsHandle(). Infact, it accepts any principal and always returns the default one. I found these:
>> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
>> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
>>>>>> cred, time = win32security.AcquireCredentialsHandle("Administrator at ORACLE.COM", "Kerberos", win32security.SECPKG_CRED_OUTBOUND, None, None)
>>>>>> cred.QueryCredentialsAttributes(1)
>>> 'osipovmi at AD001.SIEMENS.NET'
>>
>>
>> Findings Java:
>> * GssManager#createCredential() with ACCEPT_ONLY or INITIATE_AND_ACCEPT gives me weird credentials with partial null nembers. I'd expect an exception here.
>> * This is one fails, but shall work:
>>> GSSManager manager = GSSManager.getInstance();
>>> GSSName userName = manager.createName("osipovmi", GSSName.NT_USER_NAME);
>>> GSSCredential cred = manager.createCredential(userName, GSSCredential.DEFAULT_LIFETIME, krb5Oid, GSSCredential.INITIATE_ONLY);
>>> [SSPI:1627] >>>> Calling gss_create_empty_oid_set...
>>> [SSPI:1542] >>>> Calling gss_add_oid_set_member...
>>> [SSPI:612] >>>> Calling gss_acquire_cred...
>>> [SSPI:619] AcquireCredentialsHandle with 0 00000257FFB199B0
>>> [SSPI:262] gss_OID_set.count is 1
>>> [SSPI:237] Kerberos mech
>>> [SSPI:628] reqKerberos
>>> [SSPI:152] cred expiration: 09/13/30828  04:48 4294967295ld
>>> [SSPI:732] Acquiring cred with a name. Check if it's me.
>>> [SSPI:791] >>>> Calling gss_inquire_cred...
>>> [SSPI:811] Allocate new name at 00000257FFB2BC40
>>> [SSPI:428] >>>> Calling gss_compare_name...
>>> [SSPI:437] Comparing osipovmi at AD001.SIEMENS.NET and osipovmi
>>> [SSPI:325] >>>> Calling gss_release_name 00000257FFB17830...
>>> [SSPI:744] Comparing result: 0
>>> [SSPI:767] >>>> Calling gss_release_cred...
>>> [SSPI:1641] >>>> Calling gss_release_oid_set...
>>> Exception in thread "main" GSSException: Failure unspecified at GSS-API level
>>> 	at java.security.jgss/sun.security.jgss.wrapper.GSSLibStub.acquireCred(Native Method)
>>
>> The problem is that I provide a local name and expect the default realm to be used. It seems like #createCredential() does not take that into account. It also has no avail when the canonicalized form is used. See sspi.cpp#L729-L748.
>> * GssManager#createContext(GSSCredential) still works although this should be a acceptor context. I expect an expception. Does not fail with JGSS either. MIT Kerberos with py-gssapi properly fails:
>>>>>> cred = gssapi.Credentials(usage='accept')                                   >>> cred
>>> <gssapi.creds.Credentials object at 0x80164bbb0>
>>>>>> context = gssapi.SecurityContext(usage='initiate', creds=cred, name=canon_name, mech=gssapi.MechType.kerberos)
>>>>>> context.step(None)
>>> Traceback (most recent call last):
>>>    File "<stdin>", line 1, in <module>
>>>    File "<decorator-gen-15>", line 2, in step
>>>    File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", line 167, in check_last_err
>>>      return func(self, *args, **kwargs)
>>>    File "<decorator-gen-5>", line 2, in step
>>>    File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", line 127, in catch_and_return_token
>>>      return func(self, *args, **kwargs)
>>>    File "/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 521, in step
>>>      return self._initiator_step(token=token)
>>>    File "/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 542, in _initiator_step
>>>      token)
>>>    File "gssapi/raw/sec_contexts.pyx", line 245, in gssapi.raw.sec_contexts.init_sec_context
>>> gssapi.raw.exceptions.MissingCredentialsError: Major (458752): Es wurden keine Anmeldedaten ?bergeben oder die Anmeldedaten waren nicht verf?gbar bzw. ein Zugriff darauf nicht m?glich., Minor (100001): Unknown code 0
>>
>> That's it for now.
>>
>> Michael
> 


From pavel.rappo at oracle.com  Wed Apr 15 16:52:47 2020
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 15 Apr 2020 17:52:47 +0100
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <CC6D3DE3-DEB3-44B1-8C5A-7E89ECE19880@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
 <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
 <CC6D3DE3-DEB3-44B1-8C5A-7E89ECE19880@oracle.com>
Message-ID: <C341347A-C35B-4AC5-94DE-B98490600800@oracle.com>

Vipin,

After a private exchange with Naoto Sato, who is fluent in that area, I decided
to leave out all the changes to the jdk.internal.icu package from the changeset.

The reason is quite simple. A significant portion of code in jdk.internal.icu
comes from an upstream project, ICU4J. Making OpenJDK-local changes to it makes
it harder to merge when updating from upstream. 

Before I created that latter webrev I found that there were OpenJDK-local
changes to that package. Still, the argument holds and we should not aggravate
already existing difficulties.

-Pavel

P.S. If you care about those changes, you may want to ask ICU4J [^1] folk to
incorporate them. If they agree, one day those changes may show up in the OpenJDK.

----------
[^1]: https://github.com/unicode-org/icu/tree/master/icu4j

> On 15 Apr 2020, at 12:06, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Vipin,
> 
> I saw that Max had already reviewed that incremental patch. That's good.
> 
> I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu
> (International Components for Unicode) package. Once this has been cleared by
> experts in that area, we are good to go.
> 
> Here's the cumulative webrev:
> 
>    http://cr.openjdk.java.net/~prappo/8242366/webrev.01/
> 
> -Pavel
> 
>> On 11 Apr 2020, at 20:23, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>> 
>> Hi Pavel,
>> 
>>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>> 
>>> If your new patch addresses a similar type of problem, please send it in reply to this email,
>>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>>> 
>> This is additional patch:
>> 
>> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
>> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
>> @@ -142,7 +142,7 @@
>>       /**
>>        * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>>        * data the index array offset of the indexes for that lead surrogate.
>> -        * @param property data value for a surrogate from the trie, including
>> +        * @param value data value for a surrogate from the trie, including
>>        *        the folding offset
>>        * @return data offset or 0 if there is no data for the lead surrogate
>>        */
>> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
>> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -39,7 +39,7 @@
>> 
>>    /**
>>     * Calls FilterInputStream's constructor.
>> -     * @param an InputStream
>> +     * @param is an InputStream
>>     */
>>    PlainTextInputStream(InputStream is) {
>>        super(is);
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -881,7 +881,7 @@
>>     * only CRLs signed with a different key (but the same issuer
>>     * name) as the certificate being checked.
>>     *
>> -     * @param currCert the <code>X509Certificate</code> to be checked
>> +     * @param cert the <code>X509Certificate</code> to be checked
>>     * @param prevKey the <code>PublicKey</code> that failed
>>     * @param signFlag <code>true</code> if that key was trusted to sign CRLs
>>     * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
>> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -166,7 +166,7 @@
>>    /**
>>     * Creates a URICertStore.
>>     *
>> -     * @param parameters specifying the URI
>> +     * @param params parameters specifying the URI
>>     */
>>    URICertStore(CertStoreParameters params)
>>        throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
>> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
>> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -483,7 +483,7 @@
>>         * and its corresponding CertId.
>>         *
>>         * @param subjectCert the certificate to be checked for revocation
>> -         * @param cid the CertId for {@code subjectCert}
>> +         * @param certId the CertId for {@code subjectCert}
>>         */
>>        StatusInfo(X509Certificate subjectCert, CertId certId) {
>>            cert = subjectCert;
>> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
>> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>> *
>> * This code is free software; you can redistribute it and/or modify it
>> @@ -193,7 +193,7 @@
>>    /**
>>     * Constructs an object to store the response to a timestamp request.
>>     *
>> -     * @param status A buffer containing the ASN.1 BER encoded response.
>> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>>     * @throws IOException The exception is thrown if a problem is encountered
>>     *         parsing the timestamp response.
>>     */
>> 
>> 
>>>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>> 
>>>>> Why assume something that sophisticated where it can be adequately explained by
>>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>>> 
>>>>> -Pavel
>>>> 
>>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>>> 
>>>>> 
>>>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>>> 
>>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>>> Hi Pavel,
>>>>>>> 
>>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>>> nor imported
>>>>>>> 
>>>>>>> Hopefully that's only on internal classes.
>>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>>> 
>>>>>> -Alan
>>>>> 
>>>> 
>>>> Regards,
>>>> Vipin
>>> 
>> Regards,
>> Vipin
>> 
> 



From vipinsharma85 at gmail.com  Wed Apr 15 18:23:10 2020
From: vipinsharma85 at gmail.com (Vipin Sharma)
Date: Wed, 15 Apr 2020 23:53:10 +0530
Subject: Need sponsor to fix Javadoc warnings
In-Reply-To: <C341347A-C35B-4AC5-94DE-B98490600800@oracle.com>
References: <CAGRQqB4KL+FCyNAbBUC+pZtbFjM3VQfkGrQJ2xKq5mWkCOQLbg@mail.gmail.com>
 <53c7b3ad-f754-be3d-ee65-dd5378f94d0e@oracle.com>
 <C0FC0D1D-C004-46A0-9BCE-EE561D688A6B@gmail.com>
 <9F43EC7B-3564-4174-839F-985A1FADB5D4@oracle.com>
 <98B58470-C8F3-418B-9F58-A88EC710615A@gmail.com>
 <DE5746F7-7D14-458D-AC8A-5230A8E87661@oracle.com>
 <c957d24a-6318-50df-d067-bc22c0642c2f@oracle.com>
 <eaacb1ea-63fe-bea4-4a75-8519478d7b7f@oracle.com>
 <da49471c-c688-f5c5-c4c3-d46977a61887@oracle.com>
 <912A428C-804F-4DD3-B41F-D427985A5A6D@oracle.com>
 <9ACC9739-39F1-466F-9814-668F963F5DB9@gmail.com>
 <C027F720-08C7-4FAA-95E3-E6E23BD7D48F@oracle.com>
 <5BF67917-D092-4FF6-B584-1FEFD89872BC@gmail.com>
 <CC6D3DE3-DEB3-44B1-8C5A-7E89ECE19880@oracle.com>
 <C341347A-C35B-4AC5-94DE-B98490600800@oracle.com>
Message-ID: <7E379657-3069-4A46-ACBD-C1AB19AE259D@gmail.com>

Thanks Pavel, I will keep this in mind for future patches.

> On Apr 15, 2020, at 10:22 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> Vipin,
> 
> After a private exchange with Naoto Sato, who is fluent in that area, I decided
> to leave out all the changes to the jdk.internal.icu package from the changeset.
> 
> The reason is quite simple. A significant portion of code in jdk.internal.icu
> comes from an upstream project, ICU4J. Making OpenJDK-local changes to it makes
> it harder to merge when updating from upstream. 
> 
> Before I created that latter webrev I found that there were OpenJDK-local
> changes to that package. Still, the argument holds and we should not aggravate
> already existing difficulties.
> 
> -Pavel
> 
> P.S. If you care about those changes, you may want to ask ICU4J [^1] folk to
> incorporate them. If they agree, one day those changes may show up in the OpenJDK.
> 
> ----------
> [^1]: https://github.com/unicode-org/icu/tree/master/icu4j
> 
>> On 15 Apr 2020, at 12:06, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> Vipin,
>> 
>> I saw that Max had already reviewed that incremental patch. That's good.
>> 
>> I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu
>> (International Components for Unicode) package. Once this has been cleared by
>> experts in that area, we are good to go.
>> 
>> Here's the cumulative webrev:
>> 
>>   http://cr.openjdk.java.net/~prappo/8242366/webrev.01/
>> 
>> -Pavel
>> 
>>> On 11 Apr 2020, at 20:23, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>> 
>>> Hi Pavel,
>>> 
>>>> On Apr 9, 2020, at 2:45 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>> 
>>>> If your new patch addresses a similar type of problem, please send it in reply to this email,
>>>> so that I could merge it with the existing patch. Let's try to minimize process overhead if possible.
>>>> 
>>> This is additional patch:
>>> 
>>> --- old/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.818724363 +0530
>>> +++ new/src/java.base/share/classes/jdk/internal/icu/text/StringPrep.java	2020-04-12 00:33:54.398714466 +0530
>>> @@ -142,7 +142,7 @@
>>>      /**
>>>       * Called by com.ibm.icu.util.Trie to extract from a lead surrogate's
>>>       * data the index array offset of the indexes for that lead surrogate.
>>> -        * @param property data value for a surrogate from the trie, including
>>> +        * @param value data value for a surrogate from the trie, including
>>>       *        the folding offset
>>>       * @return data offset or 0 if there is no data for the lead surrogate
>>>       */
>>> --- old/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.778746974 +0530
>>> +++ new/src/java.base/share/classes/sun/net/www/content/text/PlainTextInputStream.java	2020-04-12 00:33:55.346736801 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 1996, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -39,7 +39,7 @@
>>> 
>>>   /**
>>>    * Calls FilterInputStream's constructor.
>>> -     * @param an InputStream
>>> +     * @param is an InputStream
>>>    */
>>>   PlainTextInputStream(InputStream is) {
>>>       super(is);
>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.726769287 +0530
>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java	2020-04-12 00:33:56.306759403 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2012, 2017, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -881,7 +881,7 @@
>>>    * only CRLs signed with a different key (but the same issuer
>>>    * name) as the certificate being checked.
>>>    *
>>> -     * @param currCert the <code>X509Certificate</code> to be checked
>>> +     * @param cert the <code>X509Certificate</code> to be checked
>>>    * @param prevKey the <code>PublicKey</code> that failed
>>>    * @param signFlag <code>true</code> if that key was trusted to sign CRLs
>>>    * @param stackedCerts a <code>Set</code> of <code>X509Certificate</code>s>
>>> --- old/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.658791207 +0530
>>> +++ new/src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java	2020-04-12 00:33:57.250781612 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2006, 2019, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2006, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -166,7 +166,7 @@
>>>   /**
>>>    * Creates a URICertStore.
>>>    *
>>> -     * @param parameters specifying the URI
>>> +     * @param params parameters specifying the URI
>>>    */
>>>   URICertStore(CertStoreParameters params)
>>>       throws InvalidAlgorithmParameterException, NoSuchAlgorithmException {
>>> --- old/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.602813394 +0530
>>> +++ new/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java	2020-04-12 00:33:58.178803431 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -483,7 +483,7 @@
>>>        * and its corresponding CertId.
>>>        *
>>>        * @param subjectCert the certificate to be checked for revocation
>>> -         * @param cid the CertId for {@code subjectCert}
>>> +         * @param certId the CertId for {@code subjectCert}
>>>        */
>>>       StatusInfo(X509Certificate subjectCert, CertId certId) {
>>>           cert = subjectCert;
>>> --- old/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.542835473 +0530
>>> +++ new/src/java.base/share/classes/sun/security/timestamp/TSResponse.java	2020-04-12 00:33:59.126825705 +0530
>>> @@ -1,5 +1,5 @@
>>> /*
>>> - * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
>>> + * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>> *
>>> * This code is free software; you can redistribute it and/or modify it
>>> @@ -193,7 +193,7 @@
>>>   /**
>>>    * Constructs an object to store the response to a timestamp request.
>>>    *
>>> -     * @param status A buffer containing the ASN.1 BER encoded response.
>>> +     * @param tsReply A buffer containing the ASN.1 BER encoded response.
>>>    * @throws IOException The exception is thrown if a problem is encountered
>>>    *         parsing the timestamp response.
>>>    */
>>> 
>>> 
>>>>> On 8 Apr 2020, at 17:35, Vipin Sharma <vipinsharma85 at gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Apr 8, 2020, at 6:57 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>>>>> 
>>>>>> Why assume something that sophisticated where it can be adequately explained by
>>>>>> a simpler thing? :) I bet it was an IDE inspection.
>>>>>> 
>>>>>> -Pavel
>>>>> 
>>>>> Yes, it was IDE inspection in java.base, it looked like the best way to start contributing and understand the process.
>>>>> If it helps and not creating noise for you all, I see an opportunity for one more such patch. What do you think?
>>>>> 
>>>>>> 
>>>>>>> On 8 Apr 2020, at 14:14, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>>>> 
>>>>>>> On 08/04/2020 14:07, Daniel Fuchs wrote:
>>>>>>>> Hi Pavel,
>>>>>>>> 
>>>>>>>> On 08/04/2020 13:56, David Holmes wrote:
>>>>>>>>> and `@exception` tags for checked exceptions that were neither thrown
>>>>>>>>> nor imported
>>>>>>>> 
>>>>>>>> Hopefully that's only on internal classes.
>>>>>>> From a quick scan, the changes are to internal classes and a few non-public elements of public API classes. So I don't think anything should impact the javadoc. I'm guessing this patch is motivated by something creating that is running the javadoc tool with different options to what the "docs" target uses.
>>>>>>> 
>>>>>>> -Alan
>>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Vipin
>>>> 
>>> Regards,
>>> Vipin
>>> 
>> 
> 



From weijun.wang at oracle.com  Thu Apr 16 00:50:32 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 16 Apr 2020 08:50:32 +0800
Subject: sun.security.spnego.msinterop does not work anymore/disable by
 default for 15
In-Reply-To: <39457c93-9343-fa19-dd37-f87613e73ccf@siemens.com>
References: <c6a7624f-e31f-1aca-f4c0-0dc0264de2e4@siemens.com>
 <5B294418-DBEF-451B-8EDF-45D4A3A5B5C7@oracle.com>
 <39457c93-9343-fa19-dd37-f87613e73ccf@siemens.com>
Message-ID: <2A7BA77C-EE02-439F-AE57-9E2B931A24C2@oracle.com>



> On Apr 16, 2020, at 5:10 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
> 
> Max,
> 
> Am 2020-04-15 um 15:41 schrieb Weijun Wang:
>> I don't know about the history, but it looks like the original author believes that for MS interop a NegTokenTarg should have the same bytes in reponseToken and mechListMIC (this is weird of course). It has been working before, maybe because the client never looks into the mechListMIC or maybe it does like it being this style.
>> So the extra size is the mechListMIC token.
>> Since JDK 13, we don't duplicate the reponseToken into mechListMIC anymore. But we still use this system property to determine whether to fill in that field. By default, no; when set to false, add and verify it. If I understand SPNEGO correctly, the field can be missing if the acceptor only understand one mechanism, which is the case with JDK.
>> Have you tried JDK 13 or newer to see if the default works?
> 
> Can you point to the JBS causing that change? Going through log on AdoptOpenJDK 13u doesn't show any change in that area.

http://hg.openjdk.java.net/jdk/jdk/diff/74f0622db875/src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java

> 
> I have tried
> 
>> # /usr/local/openjdk13/bin/java -version
>> openjdk version "13.0.2" 2020-01-14
>> OpenJDK Runtime Environment (build 13.0.2+8-1)
>> OpenJDK 64-Bit Server VM (build 13.0.2+8-1, mixed mode)
> 
> and
> 
>> # /usr/local/openjdk14/bin/java -version
>> openjdk version "14" 2020-03-17
>> OpenJDK Runtime Environment (build 14+36-1)
>> OpenJDK 64-Bit Server VM (build 14+36-1, mixed mode, sharing)
> 
> the tweak is not necessary anymore. Funny thing is, regardless of true or false, I never get the duplicate token now. I wonder wether the property has still any effect. I have tried curl with SSPI on Windows 10 and curl on FreeBSD with MIT Kerberos.

It is still used. When not set (or true), mechListMIC field is ignored and not generated.

> 
> So since JDK only understands Kerberos where is the point in still having this property since you always omit the mechListMIC?

Set it to false and you get the mechListMIC. It is not useful now.

I remember there is a part in the Microsoft SPNEGO doc (MS-SPNG) on which versions of Windows use this field. It's quite complicated. I think leaving this system property there might help with interop issue in some cases (when the MS peer insists the field should be present).

> 
> Can you also answer why the new token (sans mechListMIC) is still smaller than the one from MIT Kerberos or SSPI?

The AP-REP inside contains a 

   EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
           ctime           [0] KerberosTime,
           cusec           [1] Microseconds,
           subkey          [2] EncryptionKey OPTIONAL,
           seq-number      [3] UInt32 OPTIONAL

So I guess it's because Java has no subkey set. Try "-Dsun.security.krb5.acceptor.subkey=true" to see if it's bigger.

Thanks,
Max

> 
> Michael



From weijun.wang at oracle.com  Thu Apr 16 00:53:44 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 16 Apr 2020 08:53:44 +0800
Subject: Evaluation part 1 of JDK-6722928: Provide a default native
 GSS-API library on Windows
In-Reply-To: <fd043267-ad0e-7417-3a0a-3f44eec37022@siemens.com>
References: <8e63c57f-68d0-0294-3741-784492b51de1@siemens.com>
 <DB39658A-1B0E-456A-8A1D-34D95F29B9E4@oracle.com>
 <fd043267-ad0e-7417-3a0a-3f44eec37022@siemens.com>
Message-ID: <2E0D90F5-0A97-4DFA-B3C0-0F2FD18812DF@oracle.com>

Sorry, not yet. Still busy on something else.

I'll look into it today and tomorrow.

Thanks,
Max

> On Apr 16, 2020, at 5:17 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
> 
> Max,
> 
> did you get a chance to go through the comments? I'd like to start review 2 (interaction) somewhere next week, but would like to sort this one out first.
> 
> Michael
> 
> Am 2020-04-02 um 03:47 schrieb Weijun Wang:
>> I'll read this carefully, thanks a lot for the comments.
>> --Max
>>> On Apr 2, 2020, at 12:21 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
>>> 
>>> Hi Max,
>>> 
>>> at last I took some time to evaluate you SSPI bridge. This is part one. Interaction evaluation will follow in a second email.
>>> 
>>> Assumptions:
>>> * All methods, objects behave the same as with JGSS
>>> * AcceptSecurityContext is not implemented so should everything associated with it fail (GSSException)
>>> * Code analysis happens based on https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/master/src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
>>> and zulu13.29.9-ca-jdk13.0.2-win_x64
>>> 
>>> Findings C:
>>> * sspi.cpp: Would it make sense to replace "__declspec(dllexport)" with JNIEXPORT?
>>> * GSSManager#createCredential(): I'd expect an exception when *not* GSSCredential.INITIATE_ONLY is requested/passed
>>> * sspi.cpp#L67-L68: Feels a bit awkward to permit SSPI_BRIDGE_TRACE="". Why not have "if (trace && *trace)"?
>>> * sspi.cpp#L233: The function name says "show_oid", but I see no OID printed. Simply symbolic names.
>>> * sspi.cpp#L290: Empty string check? like (realm && *realm)
>>> * Usage of %p: If you don't know that %p is used it is hard to tell why this output is there. May turn to "at 0x%p" in general?
>>> * sspi.cpp#L359: -2!= reads awkward. Reformat?
>>> * sspi.cpp#L482-L483: This is highly questionable. While it is true for Windows, it does not stick to gss_compare_name behavior. Don't know what the correct approach would be here.
>>> * sspi.cpp#L595: That's weird. A string leads to a length? Should it read: PP("Name found: %ls -> %s [%d]", names, buffer, len)
>>> * sspi.cpp#L618: You are resetting cred_usage passed with the function. This looks like a bug to me.
>>> * sspi.cpp#L619: Reads very bad, maybe turn into "PP("AcquireCredentialsHandle with usage: %d, creds: 0x%p", cred_usage, desired_mechs)"
>>> * sspi.cpp#L627-L633: Trace message could be more expressive, e.g., "Requesting Kerberos mech"
>>> * sspi.cpp#L657-L658 and sspi.cpp#L687-L688: They look wrong and do not correspond to GSSCredentialImpl.java#L628-L640. default value should be INITIATE_AND_ACCEPT.
>>>  Same as in GSS-API:
>>> $ sudo python3
>>>> Python 3.7.7 (default, Mar 19 2020, 21:26:00)
>>>> [Clang 9.0.1 (git at github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b31 on freebsd12
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>>> import gssapi
>>>>>>> cred = gssapi.Credentials(usage='nonsense')
>>>>>>> cred.usage
>>>> 'both'
>>> This also may be a bug in py-gssapi/MIT Kerberos
>>> * sspi.cpp#L149
>>> ** Can you apply a better output like ISO 8601? In strftime(3) that would be "%FT%T, ..."
>>> ** "%uld" does not seem to work here: 4294967295ld. Shouldn't that read "%"PRIu32" seconds" or "%lu seconds"?
>>> * sspi.cpp#L744: "Comparison result: %d". You are not comparing the result, but print comparsion result.
>>> * sspi.cpp#L841: man 3 gss_import_sec_context says: GSS_S_UNAVAILABLE
>>> * sspi.cpp#L977-L979: Not helpful when the SEC_E_* not mapped to major/minor. This likely applies to most mapping functions.
>>> * sspi.cpp#L1012: Maybe: "Names: client: %s, server: %s"?
>>> * sspi.cpp#L1046: Maybe like gss_export_sec_context?
>>> * sspi.cpp#L1169: Remove word "IMPLEMENTED"
>>> * sspi.cpp#L1169: Maybe like gss_export_sec_context?
>>> * sspi.cpp#L1480: Includes a trailing, redundant newline
>>> * sspi.cpp#L729-L748: Why do you do this? The documentation for parameter 1 says: If the process that requests the handle does not have access to the credentials, the function returns an error. I have verified this with py-win32: win32security.AcquireCredentialsHandle(). Infact, it accepts any principal and always returns the default one. I found these:
>>> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
>>> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
>>>>>>> cred, time = win32security.AcquireCredentialsHandle("Administrator at ORACLE.COM", "Kerberos", win32security.SECPKG_CRED_OUTBOUND, None, None)
>>>>>>> cred.QueryCredentialsAttributes(1)
>>>> 'osipovmi at AD001.SIEMENS.NET'
>>> 
>>> 
>>> Findings Java:
>>> * GssManager#createCredential() with ACCEPT_ONLY or INITIATE_AND_ACCEPT gives me weird credentials with partial null nembers. I'd expect an exception here.
>>> * This is one fails, but shall work:
>>>> GSSManager manager = GSSManager.getInstance();
>>>> GSSName userName = manager.createName("osipovmi", GSSName.NT_USER_NAME);
>>>> GSSCredential cred = manager.createCredential(userName, GSSCredential.DEFAULT_LIFETIME, krb5Oid, GSSCredential.INITIATE_ONLY);
>>>> [SSPI:1627] >>>> Calling gss_create_empty_oid_set...
>>>> [SSPI:1542] >>>> Calling gss_add_oid_set_member...
>>>> [SSPI:612] >>>> Calling gss_acquire_cred...
>>>> [SSPI:619] AcquireCredentialsHandle with 0 00000257FFB199B0
>>>> [SSPI:262] gss_OID_set.count is 1
>>>> [SSPI:237] Kerberos mech
>>>> [SSPI:628] reqKerberos
>>>> [SSPI:152] cred expiration: 09/13/30828  04:48 4294967295ld
>>>> [SSPI:732] Acquiring cred with a name. Check if it's me.
>>>> [SSPI:791] >>>> Calling gss_inquire_cred...
>>>> [SSPI:811] Allocate new name at 00000257FFB2BC40
>>>> [SSPI:428] >>>> Calling gss_compare_name...
>>>> [SSPI:437] Comparing osipovmi at AD001.SIEMENS.NET and osipovmi
>>>> [SSPI:325] >>>> Calling gss_release_name 00000257FFB17830...
>>>> [SSPI:744] Comparing result: 0
>>>> [SSPI:767] >>>> Calling gss_release_cred...
>>>> [SSPI:1641] >>>> Calling gss_release_oid_set...
>>>> Exception in thread "main" GSSException: Failure unspecified at GSS-API level
>>>> 	at java.security.jgss/sun.security.jgss.wrapper.GSSLibStub.acquireCred(Native Method)
>>> 
>>> The problem is that I provide a local name and expect the default realm to be used. It seems like #createCredential() does not take that into account. It also has no avail when the canonicalized form is used. See sspi.cpp#L729-L748.
>>> * GssManager#createContext(GSSCredential) still works although this should be a acceptor context. I expect an expception. Does not fail with JGSS either. MIT Kerberos with py-gssapi properly fails:
>>>>>>> cred = gssapi.Credentials(usage='accept')                                   >>> cred
>>>> <gssapi.creds.Credentials object at 0x80164bbb0>
>>>>>>> context = gssapi.SecurityContext(usage='initiate', creds=cred, name=canon_name, mech=gssapi.MechType.kerberos)
>>>>>>> context.step(None)
>>>> Traceback (most recent call last):
>>>>   File "<stdin>", line 1, in <module>
>>>>   File "<decorator-gen-15>", line 2, in step
>>>>   File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", line 167, in check_last_err
>>>>     return func(self, *args, **kwargs)
>>>>   File "<decorator-gen-5>", line 2, in step
>>>>   File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", line 127, in catch_and_return_token
>>>>     return func(self, *args, **kwargs)
>>>>   File "/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 521, in step
>>>>     return self._initiator_step(token=token)
>>>>   File "/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 542, in _initiator_step
>>>>     token)
>>>>   File "gssapi/raw/sec_contexts.pyx", line 245, in gssapi.raw.sec_contexts.init_sec_context
>>>> gssapi.raw.exceptions.MissingCredentialsError: Major (458752): Es wurden keine Anmeldedaten ?bergeben oder die Anmeldedaten waren nicht verf?gbar bzw. ein Zugriff darauf nicht m?glich., Minor (100001): Unknown code 0
>>> 
>>> That's it for now.
>>> 
>>> Michael



From weijun.wang at oracle.com  Thu Apr 16 01:19:05 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 16 Apr 2020 09:19:05 +0800
Subject: RFR: 8242565: Policy initialization issues when the denyAfter
 constraint is enabled
In-Reply-To: <9f3d92b2-c85e-a26e-b8d2-aacdcd15cf3d@oracle.com>
References: <35ed690e-7b2a-c3f1-e940-f3f782cdf3af@oracle.com>
 <83CC4665-0E5F-48A5-B353-7E06231D39E7@oracle.com>
 <9f3d92b2-c85e-a26e-b8d2-aacdcd15cf3d@oracle.com>
Message-ID: <8D1A89A2-4C28-4D3C-9189-5C289661BA70@oracle.com>



> On Apr 15, 2020, at 11:29 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 4/15/20 3:30 AM, Weijun Wang wrote:
>>> On Apr 14, 2020, at 1:00 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> When a SecurityManager is enabled, early code paths that involve ServiceLoader (SL) can trigger permission checks that cause parsing of a custom policy file to fail due to recursive processing of the policy file.
>>> 
>>> I have fixed two of these issues which can occur under the following conditions:
>>> 
>>> 1. SecurityManager enabled
>>> 2. Signed JAR on the classpath
>>> 3. Policy file granting permission based on who signed jar and a keystore entry containing the alias/key
>>> 4. Code triggering a permission check based on that grant
>>> 5. A SHA-1 denyAfter constraint set in the jdk.jar.disabledAlgorithms property in the java.security file
>>> 
>>> Parsing of the denyAfter constraint is required to verify the signed JAR, which happens very early. This causes SL to search for a LocaleProvider to parse the denyAfter date field which triggers a permission check, causes the policy machinery to bootstrap, and which triggers further permission checks, etc.

Do we really need a LocaleProvider here? Or, is the grammar really locale-dependent? This does not look user-friendly to me.

--Max

>>> 
>>> The first issue is that PKCS12KeyStore is unable to verify the integrity of the keystore entry in the custom policy file because it cannot find a "PBE" AlgorithmParameters implementation. I fixed this by adding "SunJCE" to the list of providers that are automatically installed during signed JAR verification.
>>> 
>>> The second issue is also in PKCS12 KeyStore where it tries to instantiate a java.text.Collator which also uses SL and thus triggers a recursive permission check. This was fixed by using a lazy initialization Holder pattern.
>> Can we just add a "collator" argument to the getPassWithModifier() method? This looks ugly but we already have "rb".
> 
> I think that is a fine suggestion, especially since keytool and jarsigner (the only code that calls KeyStoreUtil.getPassWithModifier()) already cache a static Collator instance. New webrev:
> 
> https://cr.openjdk.java.net/~mullan/webrevs/8242565/webrev.01/
> 
> --Sean



From weijun.wang at oracle.com  Thu Apr 16 01:58:06 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 16 Apr 2020 09:58:06 +0800
Subject: RFR: 8242565: Policy initialization issues when the denyAfter
 constraint is enabled
In-Reply-To: <8D1A89A2-4C28-4D3C-9189-5C289661BA70@oracle.com>
References: <35ed690e-7b2a-c3f1-e940-f3f782cdf3af@oracle.com>
 <83CC4665-0E5F-48A5-B353-7E06231D39E7@oracle.com>
 <9f3d92b2-c85e-a26e-b8d2-aacdcd15cf3d@oracle.com>
 <8D1A89A2-4C28-4D3C-9189-5C289661BA70@oracle.com>
Message-ID: <BF9707CF-AA7E-4D4A-A1C4-9F27D87705C5@oracle.com>



> On Apr 16, 2020, at 9:19 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> 
> 
>> On Apr 15, 2020, at 11:29 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>> 
>> On 4/15/20 3:30 AM, Weijun Wang wrote:
>>>> On Apr 14, 2020, at 1:00 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>> 
>>>> When a SecurityManager is enabled, early code paths that involve ServiceLoader (SL) can trigger permission checks that cause parsing of a custom policy file to fail due to recursive processing of the policy file.
>>>> 
>>>> I have fixed two of these issues which can occur under the following conditions:
>>>> 
>>>> 1. SecurityManager enabled
>>>> 2. Signed JAR on the classpath
>>>> 3. Policy file granting permission based on who signed jar and a keystore entry containing the alias/key
>>>> 4. Code triggering a permission check based on that grant
>>>> 5. A SHA-1 denyAfter constraint set in the jdk.jar.disabledAlgorithms property in the java.security file
>>>> 
>>>> Parsing of the denyAfter constraint is required to verify the signed JAR, which happens very early. This causes SL to search for a LocaleProvider to parse the denyAfter date field which triggers a permission check, causes the policy machinery to bootstrap, and which triggers further permission checks, etc.
> 
> Do we really need a LocaleProvider here? Or, is the grammar really locale-dependent? This does not look user-friendly to me.

Just take a look. The grammar is simple but we use SimpleDateFormat for debugging messages and Calendar to validate the input.

Maybe we can use 

   LocalDateTime.of(year, month, day, 0, 0).atOffset(ZoneOffset.UTC).toInstant()

to load the date. It takes care of validation and very easy to compare to Instant.now().

I don't have any other comment on the code change.

Thanks,
Max

> 
> --Max
> 
>>>> 
>>>> The first issue is that PKCS12KeyStore is unable to verify the integrity of the keystore entry in the custom policy file because it cannot find a "PBE" AlgorithmParameters implementation. I fixed this by adding "SunJCE" to the list of providers that are automatically installed during signed JAR verification.
>>>> 
>>>> The second issue is also in PKCS12 KeyStore where it tries to instantiate a java.text.Collator which also uses SL and thus triggers a recursive permission check. This was fixed by using a lazy initialization Holder pattern.
>>> Can we just add a "collator" argument to the getPassWithModifier() method? This looks ugly but we already have "rb".
>> 
>> I think that is a fine suggestion, especially since keytool and jarsigner (the only code that calls KeyStoreUtil.getPassWithModifier()) already cache a static Collator instance. New webrev:
>> 
>> https://cr.openjdk.java.net/~mullan/webrevs/8242565/webrev.01/
>> 
>> --Sean



From weijun.wang at oracle.com  Thu Apr 16 05:46:08 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 16 Apr 2020 13:46:08 +0800
Subject: RFR 8242260: Remove customizable ContentSigner from jarsigner
In-Reply-To: <7f09ad12-7c89-5027-beb4-d955ca4ed469@oracle.com>
References: <240EEA50-3A79-4E62-A96F-7A4C1DC32D48@oracle.com>
 <71D8C1A1-AB3A-49D4-A7D4-C4C282864804@oracle.com>
 <7f09ad12-7c89-5027-beb4-d955ca4ed469@oracle.com>
Message-ID: <0DA0ACFF-532C-4D9C-82B8-3575D83F0B8E@oracle.com>

Thanks. All suggestions accepted.

--Max

> On Apr 16, 2020, at 2:40 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 4/14/20 3:27 AM, Weijun Wang wrote:
>> After some discussion, we decide to keep the classes in JDK 15 but add a `forRemoval=true` argument. Related jarsigner help screen and warning message are also updated.
>> Please review everything updated at:
>>   Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
> 
> Reviewed. I think it is probably better to flag this with an RN-Deprecated label since this is about marking it for removal and will show up in a section of the release notes about deprecation. You could check with others on this though.
> 
>>            CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>         webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.01/ (a new URL!)
> 
> - add 2020 date to copyright in package-info.java
> 
> - Resources.java:
> 
> 94 {".altsigner.class.class.name.of.an.alternative.signing.mechanism",
>  95                 "[-altsigner <class>]        class name of an alternative signing mechanism\n" +
>  96                 "                            (This option has been deprecated and will be removed in a future release.)"},
>  97 {".altsignerpath.pathlist.location.of.an.alternative.signing.mechanism",
>  98                 "[-altsignerpath <pathlist>] location of an alternative signing mechanism\n" +
>  99                 "                            (This option has been deprecated and will be removed in a future release.)"},
> 
> I would change "has been deprecated" to "is deprecated" which is consistent with the "This.option.is.forremoval" message and seems a bit clearer.
> 
> --Sean
> 
>> Thanks,
>> Max
>>> On Apr 7, 2020, at 4:04 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> I am thinking about removing the `jarsigner -altsigner -altsignerpath` options and underlying classes:
>>> 
>>>            JBS : https://bugs.openjdk.java.net/browse/JDK-8242260
>>> 
>>> Please review everything at:
>>> 
>>>   Release note : https://bugs.openjdk.java.net/browse/JDK-8242261
>>>            CSR : https://bugs.openjdk.java.net/browse/JDK-8242262
>>>         webrev : http://cr.openjdk.java.net/~weijun/8242260/webrev.00/
>>> 
>>> The CSR "Problem" section has more info on why it's better to remove it now.
>>> 
>>> Thanks,
>>> Max
>>> 



From michael.osipov at siemens.com  Thu Apr 16 08:16:27 2020
From: michael.osipov at siemens.com (Osipov, Michael)
Date: Thu, 16 Apr 2020 10:16:27 +0200
Subject: Evaluation part 1 of JDK-6722928: Provide a default native
 GSS-API library on Windows
In-Reply-To: <2E0D90F5-0A97-4DFA-B3C0-0F2FD18812DF@oracle.com>
References: <8e63c57f-68d0-0294-3741-784492b51de1@siemens.com>
 <DB39658A-1B0E-456A-8A1D-34D95F29B9E4@oracle.com>
 <fd043267-ad0e-7417-3a0a-3f44eec37022@siemens.com>
 <2E0D90F5-0A97-4DFA-B3C0-0F2FD18812DF@oracle.com>
Message-ID: <1aee7d51-e28a-9b3a-8fa8-021aa1a72431@siemens.com>

Thanks, no need to hurry. Take your time. I just don't want it to be 
forgotten.

Michael

Am 2020-04-16 um 02:53 schrieb Weijun Wang:
> Sorry, not yet. Still busy on something else.
> 
> I'll look into it today and tomorrow.
> 
> Thanks,
> Max
> 
>> On Apr 16, 2020, at 5:17 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
>>
>> Max,
>>
>> did you get a chance to go through the comments? I'd like to start review 2 (interaction) somewhere next week, but would like to sort this one out first.
>>
>> Michael
>>
>> Am 2020-04-02 um 03:47 schrieb Weijun Wang:
>>> I'll read this carefully, thanks a lot for the comments.
>>> --Max
>>>> On Apr 2, 2020, at 12:21 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
>>>>
>>>> Hi Max,
>>>>
>>>> at last I took some time to evaluate you SSPI bridge. This is part one. Interaction evaluation will follow in a second email.
>>>>
>>>> Assumptions:
>>>> * All methods, objects behave the same as with JGSS
>>>> * AcceptSecurityContext is not implemented so should everything associated with it fail (GSSException)
>>>> * Code analysis happens based on https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/master/src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
>>>> and zulu13.29.9-ca-jdk13.0.2-win_x64
>>>>
>>>> Findings C:
>>>> * sspi.cpp: Would it make sense to replace "__declspec(dllexport)" with JNIEXPORT?
>>>> * GSSManager#createCredential(): I'd expect an exception when *not* GSSCredential.INITIATE_ONLY is requested/passed
>>>> * sspi.cpp#L67-L68: Feels a bit awkward to permit SSPI_BRIDGE_TRACE="". Why not have "if (trace && *trace)"?
>>>> * sspi.cpp#L233: The function name says "show_oid", but I see no OID printed. Simply symbolic names.
>>>> * sspi.cpp#L290: Empty string check? like (realm && *realm)
>>>> * Usage of %p: If you don't know that %p is used it is hard to tell why this output is there. May turn to "at 0x%p" in general?
>>>> * sspi.cpp#L359: -2!= reads awkward. Reformat?
>>>> * sspi.cpp#L482-L483: This is highly questionable. While it is true for Windows, it does not stick to gss_compare_name behavior. Don't know what the correct approach would be here.
>>>> * sspi.cpp#L595: That's weird. A string leads to a length? Should it read: PP("Name found: %ls -> %s [%d]", names, buffer, len)
>>>> * sspi.cpp#L618: You are resetting cred_usage passed with the function. This looks like a bug to me.
>>>> * sspi.cpp#L619: Reads very bad, maybe turn into "PP("AcquireCredentialsHandle with usage: %d, creds: 0x%p", cred_usage, desired_mechs)"
>>>> * sspi.cpp#L627-L633: Trace message could be more expressive, e.g., "Requesting Kerberos mech"
>>>> * sspi.cpp#L657-L658 and sspi.cpp#L687-L688: They look wrong and do not correspond to GSSCredentialImpl.java#L628-L640. default value should be INITIATE_AND_ACCEPT.
>>>>   Same as in GSS-API:
>>>> $ sudo python3
>>>>> Python 3.7.7 (default, Mar 19 2020, 21:26:00)
>>>>> [Clang 9.0.1 (git at github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b31 on freebsd12
>>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>>>> import gssapi
>>>>>>>> cred = gssapi.Credentials(usage='nonsense')
>>>>>>>> cred.usage
>>>>> 'both'
>>>> This also may be a bug in py-gssapi/MIT Kerberos
>>>> * sspi.cpp#L149
>>>> ** Can you apply a better output like ISO 8601? In strftime(3) that would be "%FT%T, ..."
>>>> ** "%uld" does not seem to work here: 4294967295ld. Shouldn't that read "%"PRIu32" seconds" or "%lu seconds"?
>>>> * sspi.cpp#L744: "Comparison result: %d". You are not comparing the result, but print comparsion result.
>>>> * sspi.cpp#L841: man 3 gss_import_sec_context says: GSS_S_UNAVAILABLE
>>>> * sspi.cpp#L977-L979: Not helpful when the SEC_E_* not mapped to major/minor. This likely applies to most mapping functions.
>>>> * sspi.cpp#L1012: Maybe: "Names: client: %s, server: %s"?
>>>> * sspi.cpp#L1046: Maybe like gss_export_sec_context?
>>>> * sspi.cpp#L1169: Remove word "IMPLEMENTED"
>>>> * sspi.cpp#L1169: Maybe like gss_export_sec_context?
>>>> * sspi.cpp#L1480: Includes a trailing, redundant newline
>>>> * sspi.cpp#L729-L748: Why do you do this? The documentation for parameter 1 says: If the process that requests the handle does not have access to the credentials, the function returns an error. I have verified this with py-win32: win32security.AcquireCredentialsHandle(). Infact, it accepts any principal and always returns the default one. I found these:
>>>> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
>>>> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
>>>>>>>> cred, time = win32security.AcquireCredentialsHandle("Administrator at ORACLE.COM", "Kerberos", win32security.SECPKG_CRED_OUTBOUND, None, None)
>>>>>>>> cred.QueryCredentialsAttributes(1)
>>>>> 'osipovmi at AD001.SIEMENS.NET'
>>>>
>>>>
>>>> Findings Java:
>>>> * GssManager#createCredential() with ACCEPT_ONLY or INITIATE_AND_ACCEPT gives me weird credentials with partial null nembers. I'd expect an exception here.
>>>> * This is one fails, but shall work:
>>>>> GSSManager manager = GSSManager.getInstance();
>>>>> GSSName userName = manager.createName("osipovmi", GSSName.NT_USER_NAME);
>>>>> GSSCredential cred = manager.createCredential(userName, GSSCredential.DEFAULT_LIFETIME, krb5Oid, GSSCredential.INITIATE_ONLY);
>>>>> [SSPI:1627] >>>> Calling gss_create_empty_oid_set...
>>>>> [SSPI:1542] >>>> Calling gss_add_oid_set_member...
>>>>> [SSPI:612] >>>> Calling gss_acquire_cred...
>>>>> [SSPI:619] AcquireCredentialsHandle with 0 00000257FFB199B0
>>>>> [SSPI:262] gss_OID_set.count is 1
>>>>> [SSPI:237] Kerberos mech
>>>>> [SSPI:628] reqKerberos
>>>>> [SSPI:152] cred expiration: 09/13/30828  04:48 4294967295ld
>>>>> [SSPI:732] Acquiring cred with a name. Check if it's me.
>>>>> [SSPI:791] >>>> Calling gss_inquire_cred...
>>>>> [SSPI:811] Allocate new name at 00000257FFB2BC40
>>>>> [SSPI:428] >>>> Calling gss_compare_name...
>>>>> [SSPI:437] Comparing osipovmi at AD001.SIEMENS.NET and osipovmi
>>>>> [SSPI:325] >>>> Calling gss_release_name 00000257FFB17830...
>>>>> [SSPI:744] Comparing result: 0
>>>>> [SSPI:767] >>>> Calling gss_release_cred...
>>>>> [SSPI:1641] >>>> Calling gss_release_oid_set...
>>>>> Exception in thread "main" GSSException: Failure unspecified at GSS-API level
>>>>> 	at java.security.jgss/sun.security.jgss.wrapper.GSSLibStub.acquireCred(Native Method)
>>>>
>>>> The problem is that I provide a local name and expect the default realm to be used. It seems like #createCredential() does not take that into account. It also has no avail when the canonicalized form is used. See sspi.cpp#L729-L748.
>>>> * GssManager#createContext(GSSCredential) still works although this should be a acceptor context. I expect an expception. Does not fail with JGSS either. MIT Kerberos with py-gssapi properly fails:
>>>>>>>> cred = gssapi.Credentials(usage='accept')                                   >>> cred
>>>>> <gssapi.creds.Credentials object at 0x80164bbb0>
>>>>>>>> context = gssapi.SecurityContext(usage='initiate', creds=cred, name=canon_name, mech=gssapi.MechType.kerberos)
>>>>>>>> context.step(None)
>>>>> Traceback (most recent call last):
>>>>>    File "<stdin>", line 1, in <module>
>>>>>    File "<decorator-gen-15>", line 2, in step
>>>>>    File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", line 167, in check_last_err
>>>>>      return func(self, *args, **kwargs)
>>>>>    File "<decorator-gen-5>", line 2, in step
>>>>>    File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", line 127, in catch_and_return_token
>>>>>      return func(self, *args, **kwargs)
>>>>>    File "/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 521, in step
>>>>>      return self._initiator_step(token=token)
>>>>>    File "/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 542, in _initiator_step
>>>>>      token)
>>>>>    File "gssapi/raw/sec_contexts.pyx", line 245, in gssapi.raw.sec_contexts.init_sec_context
>>>>> gssapi.raw.exceptions.MissingCredentialsError: Major (458752): Es wurden keine Anmeldedaten ?bergeben oder die Anmeldedaten waren nicht verf?gbar bzw. ein Zugriff darauf nicht m?glich., Minor (100001): Unknown code 0
>>>>
>>>> That's it for now.
>>>>
>>>> Michael
> 


From michael.osipov at siemens.com  Thu Apr 16 12:51:47 2020
From: michael.osipov at siemens.com (Osipov, Michael)
Date: Thu, 16 Apr 2020 14:51:47 +0200
Subject: sun.security.spnego.msinterop does not work anymore/disable by
 default for 15
In-Reply-To: <2A7BA77C-EE02-439F-AE57-9E2B931A24C2@oracle.com>
References: <c6a7624f-e31f-1aca-f4c0-0dc0264de2e4@siemens.com>
 <5B294418-DBEF-451B-8EDF-45D4A3A5B5C7@oracle.com>
 <39457c93-9343-fa19-dd37-f87613e73ccf@siemens.com>
 <2A7BA77C-EE02-439F-AE57-9E2B931A24C2@oracle.com>
Message-ID: <e2218d3a-9393-8302-3662-a4fa9362f2ab@siemens.com>



Am 2020-04-16 um 02:50 schrieb Weijun Wang:
> 
> 
>> On Apr 16, 2020, at 5:10 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
>>
>> Max,
>>
>> Am 2020-04-15 um 15:41 schrieb Weijun Wang:
>>> I don't know about the history, but it looks like the original author believes that for MS interop a NegTokenTarg should have the same bytes in reponseToken and mechListMIC (this is weird of course). It has been working before, maybe because the client never looks into the mechListMIC or maybe it does like it being this style.
>>> So the extra size is the mechListMIC token.
>>> Since JDK 13, we don't duplicate the reponseToken into mechListMIC anymore. But we still use this system property to determine whether to fill in that field. By default, no; when set to false, add and verify it. If I understand SPNEGO correctly, the field can be missing if the acceptor only understand one mechanism, which is the case with JDK.
>>> Have you tried JDK 13 or newer to see if the default works?
>>
>> Can you point to the JBS causing that change? Going through log on AdoptOpenJDK 13u doesn't show any change in that area.
> 
> http://hg.openjdk.java.net/jdk/jdk/diff/74f0622db875/src/java.security.jgss/share/classes/sun/security/jgss/spnego/NegTokenTarg.java

There it is!

>>
>> I have tried
>>
>>> # /usr/local/openjdk13/bin/java -version
>>> openjdk version "13.0.2" 2020-01-14
>>> OpenJDK Runtime Environment (build 13.0.2+8-1)
>>> OpenJDK 64-Bit Server VM (build 13.0.2+8-1, mixed mode)
>>
>> and
>>
>>> # /usr/local/openjdk14/bin/java -version
>>> openjdk version "14" 2020-03-17
>>> OpenJDK Runtime Environment (build 14+36-1)
>>> OpenJDK 64-Bit Server VM (build 14+36-1, mixed mode, sharing)
>>
>> the tweak is not necessary anymore. Funny thing is, regardless of true or false, I never get the duplicate token now. I wonder wether the property has still any effect. I have tried curl with SSPI on Windows 10 and curl on FreeBSD with MIT Kerberos.
> 
> It is still used. When not set (or true), mechListMIC field is ignored and not generated.
> 
>>
>> So since JDK only understands Kerberos where is the point in still having this property since you always omit the mechListMIC?
> 
> Set it to false and you get the mechListMIC. It is not useful now.
> 
> I remember there is a part in the Microsoft SPNEGO doc (MS-SPNG) on which versions of Windows use this field. It's quite complicated. I think leaving this system property there might help with interop issue in some cases (when the MS peer insists the field should be present).
> 
>>
>> Can you also answer why the new token (sans mechListMIC) is still smaller than the one from MIT Kerberos or SSPI?
> 
> The AP-REP inside contains a
> 
>     EncAPRepPart    ::= [APPLICATION 27] SEQUENCE {
>             ctime           [0] KerberosTime,
>             cusec           [1] Microseconds,
>             subkey          [2] EncryptionKey OPTIONAL,
>             seq-number      [3] UInt32 OPTIONAL
> 
> So I guess it's because Java has no subkey set. Try "-Dsun.security.krb5.acceptor.subkey=true" to see if it's bigger.

Yes, it is bigger and inline with the other Kerberos implemenatations.
Is there any reason not to turn it on by default since the others do it too?

Thank you very very much for your support. Everything works now 
consistently across platforms.

Michael


From sean.mullan at oracle.com  Thu Apr 16 12:54:00 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 16 Apr 2020 08:54:00 -0400
Subject: RFR: 8242565: Policy initialization issues when the denyAfter
 constraint is enabled
In-Reply-To: <BF9707CF-AA7E-4D4A-A1C4-9F27D87705C5@oracle.com>
References: <35ed690e-7b2a-c3f1-e940-f3f782cdf3af@oracle.com>
 <83CC4665-0E5F-48A5-B353-7E06231D39E7@oracle.com>
 <9f3d92b2-c85e-a26e-b8d2-aacdcd15cf3d@oracle.com>
 <8D1A89A2-4C28-4D3C-9189-5C289661BA70@oracle.com>
 <BF9707CF-AA7E-4D4A-A1C4-9F27D87705C5@oracle.com>
Message-ID: <b7e7a24e-02b1-4f25-a054-ec909ea805a8@oracle.com>

On 4/15/20 9:58 PM, Weijun Wang wrote:
>>>>> Parsing of the denyAfter constraint is required to verify the signed JAR, which happens very early. This causes SL to search for a LocaleProvider to parse the denyAfter date field which triggers a permission check, causes the policy machinery to bootstrap, and which triggers further permission checks, etc.
>> Do we really need a LocaleProvider here? Or, is the grammar really locale-dependent? This does not look user-friendly to me.
> Just take a look. The grammar is simple but we use SimpleDateFormat for debugging messages and Calendar to validate the input.
> 
> Maybe we can use
> 
>     LocalDateTime.of(year, month, day, 0, 0).atOffset(ZoneOffset.UTC).toInstant()
> 
> to load the date. It takes care of validation and very easy to compare to Instant.now().

Good points. SimpleDateFormat definitely looks like additional overhead 
that can be avoided. And using LocalDateTime looks like it also might work.

I would like to handle this separately though, so I will file a separate 
issue.

> I don't have any other comment on the code change.

Great, thanks for reviewing.

--Sean


From weijun.wang at oracle.com  Thu Apr 16 13:14:48 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 16 Apr 2020 21:14:48 +0800
Subject: sun.security.spnego.msinterop does not work anymore/disable by
 default for 15
In-Reply-To: <e2218d3a-9393-8302-3662-a4fa9362f2ab@siemens.com>
References: <c6a7624f-e31f-1aca-f4c0-0dc0264de2e4@siemens.com>
 <5B294418-DBEF-451B-8EDF-45D4A3A5B5C7@oracle.com>
 <39457c93-9343-fa19-dd37-f87613e73ccf@siemens.com>
 <2A7BA77C-EE02-439F-AE57-9E2B931A24C2@oracle.com>
 <e2218d3a-9393-8302-3662-a4fa9362f2ab@siemens.com>
Message-ID: <DD9FFCA1-253F-42AF-BE3A-4B7244FF27E9@oracle.com>


>> 
>> So I guess it's because Java has no subkey set. Try "-Dsun.security.krb5.acceptor.subkey=true" to see if it's bigger.
> 
> Yes, it is bigger and inline with the other Kerberos implemenatations.
> Is there any reason not to turn it on by default since the others do it too?

No real reason but I seldom want to change the existing behavior.

Except for being smaller, is there any other problem?

Thanks,
Max



From michael.osipov at siemens.com  Thu Apr 16 15:10:56 2020
From: michael.osipov at siemens.com (Osipov, Michael)
Date: Thu, 16 Apr 2020 17:10:56 +0200
Subject: sun.security.spnego.msinterop does not work anymore/disable by
 default for 15
In-Reply-To: <DD9FFCA1-253F-42AF-BE3A-4B7244FF27E9@oracle.com>
References: <c6a7624f-e31f-1aca-f4c0-0dc0264de2e4@siemens.com>
 <5B294418-DBEF-451B-8EDF-45D4A3A5B5C7@oracle.com>
 <39457c93-9343-fa19-dd37-f87613e73ccf@siemens.com>
 <2A7BA77C-EE02-439F-AE57-9E2B931A24C2@oracle.com>
 <e2218d3a-9393-8302-3662-a4fa9362f2ab@siemens.com>
 <DD9FFCA1-253F-42AF-BE3A-4B7244FF27E9@oracle.com>
Message-ID: <1c3cfc02-83f2-7322-7bea-174f39032efd@siemens.com>

Am 2020-04-16 um 15:14 schrieb Weijun Wang:
> 
>>>
>>> So I guess it's because Java has no subkey set. Try "-Dsun.security.krb5.acceptor.subkey=true" to see if it's bigger.
>>
>> Yes, it is bigger and inline with the other Kerberos implemenatations.
>> Is there any reason not to turn it on by default since the others do it too?
> 
> No real reason but I seldom want to change the existing behavior.
> 
> Except for being smaller, is there any other problem?

No, none. Both SSPI and MIT Kerberos complete the context with it. 
Everything works now in this regard.

Thanks,

Michael


From sean.mullan at oracle.com  Fri Apr 17 19:24:54 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 17 Apr 2020 15:24:54 -0400
Subject: RFR 8242184: CRL generation error with RSASSA-PSS
In-Reply-To: <65EFCF37-164B-4008-8DF9-8C43E4C94977@oracle.com>
References: <610E58EF-5A67-421C-996B-BFDAB1CBDBDE@oracle.com>
 <556d9277-925c-aa9f-3281-327f36300977@oracle.com>
 <65EFCF37-164B-4008-8DF9-8C43E4C94977@oracle.com>
Message-ID: <adbbcdeb-058f-757a-63a7-8403a3eb5f94@oracle.com>

On 4/15/20 8:28 AM, Weijun Wang wrote:
> 
>> On Apr 9, 2020, at 3:46 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 4/6/20 11:11 PM, Weijun Wang wrote:
>>> Please review the fix at
>>>     http://cr.openjdk.java.net/~weijun/8242184/webrev.00/
>>> The major change is inside X509CRLImpl.java to allow params setting and reading.
>>> I also take this chance to:
>>> 1. Provide a default -sigalg for "keytool -genkeypair -keyalg rsassa-pss".
>>
>> I think you should file a CSR for that, since it is a new default, and the default varies based on the size of the key. You should also update the keytool man page section on defaults.
> 
> I've filed a CSR at https://bugs.openjdk.java.net/browse/JDK-8242812. Please take a review.

In the Problem section, you might want to mention what the current 
behavior of keytool is right now if you use an RSASSA-PSS key and you 
don't specify -sigalg.

Otherwise, looks good.

--Sean

> 
> Here, actually when the key is RSASSA-PSS, the default signature is simply RSASSA-PSS, and its parameters will take the same from the key itself, and not related to the key size.
> 
> Thanks,
> Max
> 
>>
>> --Sean
>>
>>> 2. Revert a former change in X509CertImpl.java, which might be a safer call.
>>> Thanks,
>>> Max
> 


From valerie.peng at oracle.com  Fri Apr 17 22:27:30 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 17 Apr 2020 15:27:30 -0700
Subject: RFR 8242811: AlgorithmId::getDefaultAlgorithmParameterSpec
 returns incompatible PSSParameterSpec for an RSASSA-PSS key
In-Reply-To: <3717A440-6386-4D8E-B88A-957C7F6480FD@oracle.com>
References: <3717A440-6386-4D8E-B88A-957C7F6480FD@oracle.com>
Message-ID: <d426901c-e547-e632-792e-b7ad284cefb8@oracle.com>


Changes look good~

Valerie

On 4/15/2020 3:34 AM, Weijun Wang wrote:
> Please take a review at
>
>     https://cr.openjdk.java.net/~weijun/8242811/webrev.00/
>
> The AlgorithmId::getDefaultAlgorithmParameterSpec method is used internally to retrieve a default AlgorithmParameterSpec to initialize a Signature, mainly be keytool.
>
> The test shows a case where it can be called.
>
> Thanks,
> Max
>


From hai-may.chao at oracle.com  Fri Apr 17 22:58:21 2020
From: hai-may.chao at oracle.com (Hai-May Chao)
Date: Fri, 17 Apr 2020 15:58:21 -0700
Subject: RFR 8242811: AlgorithmId::getDefaultAlgorithmParameterSpec
 returns incompatible PSSParameterSpec for an RSASSA-PSS key
In-Reply-To: <d426901c-e547-e632-792e-b7ad284cefb8@oracle.com>
References: <3717A440-6386-4D8E-B88A-957C7F6480FD@oracle.com>
 <d426901c-e547-e632-792e-b7ad284cefb8@oracle.com>
Message-ID: <219761D0-41D5-45E8-8735-D5EC22DF5191@oracle.com>

Changes good to me.

Hai-May


> On Apr 17, 2020, at 3:27 PM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> 
> Changes look good~
> 
> Valerie
> 
> On 4/15/2020 3:34 AM, Weijun Wang wrote:
>> Please take a review at
>> 
>>    https://cr.openjdk.java.net/~weijun/8242811/webrev.00/
>> 
>> The AlgorithmId::getDefaultAlgorithmParameterSpec method is used internally to retrieve a default AlgorithmParameterSpec to initialize a Signature, mainly be keytool.
>> 
>> The test shows a case where it can be called.
>> 
>> Thanks,
>> Max
>> 



From sha.jiang at oracle.com  Mon Apr 20 01:33:51 2020
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 20 Apr 2020 09:33:51 +0800
Subject: RFR[15] JDK-8243029: Rewrite
 javax/net/ssl/compatibility/Compatibility.java with a flexible interop test
 framework
Message-ID: <03ad8c60-2924-d2d4-32ce-175734fcc8dc@oracle.com>

Hi,
This patch introduces a flexible test framework for supporting JSSE 
interop testing.
This framework supports the SSL/TLS communication between not only JDK 
builds,
but also possibly other TLS implementations.

The original test cases in 
javax/net/ssl/compatibility/Compatibility.java are
divided into 3 separated tests, namely BasicConnectTest.java, 
SniTest.java and
AlpnTest.java, and introduces a new compatibility test on TLS 1.3 hello 
retry
request, namely HrrTest.java. These tests depend on the aforementioned 
framework.

And the negative cases are removed for making the test results clean and 
clear.
It doesn't generate result report anymore. All of failed test cases are 
highlighted
at the end of a test run.

Additionally, more compatibility tests will be added.

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

Best regards,
John Jiang



From weijun.wang at oracle.com  Tue Apr 21 13:36:47 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 21 Apr 2020 21:36:47 +0800
Subject: Evaluation part 1 of JDK-6722928: Provide a default native
 GSS-API library on Windows
In-Reply-To: <8e63c57f-68d0-0294-3741-784492b51de1@siemens.com>
References: <8e63c57f-68d0-0294-3741-784492b51de1@siemens.com>
Message-ID: <736322E7-0DD3-4BCC-BE33-13AFDACA22DF@oracle.com>



> On Apr 2, 2020, at 12:21 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
> 
> Hi Max,
> 
> at last I took some time to evaluate you SSPI bridge. This is part one. Interaction evaluation will follow in a second email.
> 
> Assumptions:
> * All methods, objects behave the same as with JGSS
> * AcceptSecurityContext is not implemented so should everything associated with it fail (GSSException)
> * Code analysis happens based on https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/master/src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
> and zulu13.29.9-ca-jdk13.0.2-win_x64
> 
> Findings C:
> * sspi.cpp: Would it make sense to replace "__declspec(dllexport)" with JNIEXPORT?

This is not a JNI library. It's a GSS-API native library.

> * GSSManager#createCredential(): I'd expect an exception when *not* GSSCredential.INITIATE_ONLY is requested/passed

Yes, it should fail.

> * sspi.cpp#L67-L68: Feels a bit awkward to permit SSPI_BRIDGE_TRACE="". Why not have "if (trace && *trace)"?

I think it's harmless but if every C program has that style I can follow.

> * sspi.cpp#L233: The function name says "show_oid", but I see no OID printed. Simply symbolic names.

Yes, it should be more like "what is this OID?". I'll think of a better name.

> * sspi.cpp#L290: Empty string check? like (realm && *realm)

But then it's still L"".

> * Usage of %p: If you don't know that %p is used it is hard to tell why this output is there. May turn to "at 0x%p" in general?

OK.

Most of the debug messages are used during my coding, and not really useful for a customer. Maybe I should do a cleanup.

> * sspi.cpp#L359: -2!= reads awkward. Reformat?

A space is needed.

> * sspi.cpp#L482-L483: This is highly questionable. While it is true for Windows, it does not stick to gss_compare_name behavior. Don't know what the correct approach would be here.

I'll be glad if it's always true for Windows. I found the name thing most complicated, and here it's still only simple name and not UPN...

> * sspi.cpp#L595: That's weird. A string leads to a length? Should it read: PP("Name found: %ls -> %s [%d]", names, buffer, len)

Sorry, I'll reformat. As I said, these messages are really not so useful for customers.

> * sspi.cpp#L618: You are resetting cred_usage passed with the function. This looks like a bug to me.

It's more like I ignore it. Will double check.

> * sspi.cpp#L619: Reads very bad, maybe turn into "PP("AcquireCredentialsHandle with usage: %d, creds: 0x%p", cred_usage, desired_mechs)"

OK.

> * sspi.cpp#L627-L633: Trace message could be more expressive, e.g., "Requesting Kerberos mech"

Yes, this is something that might really be useful.

> * sspi.cpp#L657-L658 and sspi.cpp#L687-L688: They look wrong and do not correspond to GSSCredentialImpl.java#L628-L640. default value should be INITIATE_AND_ACCEPT.

Oh, I'll check.

>  Same as in GSS-API:
> $ sudo python3
> > Python 3.7.7 (default, Mar 19 2020, 21:26:00)
> > [Clang 9.0.1 (git at github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b31 on freebsd12
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import gssapi
> > >>> cred = gssapi.Credentials(usage='nonsense')
> > >>> cred.usage
> > 'both'
> This also may be a bug in py-gssapi/MIT Kerberos
> * sspi.cpp#L149
> ** Can you apply a better output like ISO 8601? In strftime(3) that would be "%FT%T, ..."

I'll check, but the current format is most readable for me.

> ** "%uld" does not seem to work here: 4294967295ld. Shouldn't that read "%"PRIu32" seconds" or "%lu seconds"?

Oh.

> * sspi.cpp#L744: "Comparison result: %d". You are not comparing the result, but print comparsion result.

OK.

> * sspi.cpp#L841: man 3 gss_import_sec_context says: GSS_S_UNAVAILABLE

I'm using GSS_S_FAILURE everywhere. I know it's not precise.

> * sspi.cpp#L977-L979: Not helpful when the SEC_E_* not mapped to major/minor. This likely applies to most mapping functions.

???

> * sspi.cpp#L1012: Maybe: "Names: client: %s, server: %s"?

OK.

> * sspi.cpp#L1046: Maybe like gss_export_sec_context?

Not sure what you want me to do.

> * sspi.cpp#L1169: Remove word "IMPLEMENTED"

Oops.

> * sspi.cpp#L1169: Maybe like gss_export_sec_context?

???

> * sspi.cpp#L1480: Includes a trailing, redundant newline

Oops.

> * sspi.cpp#L729-L748: Why do you do this? The documentation for parameter 1 says: If the process that requests the handle does not have access to the credentials, the function returns an error. I have verified this with py-win32: win32security.AcquireCredentialsHandle(). Infact, it accepts any principal and always returns the default one. I found these:
> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
> > >>> cred, time = win32security.AcquireCredentialsHandle("Administrator at ORACLE.COM", "Kerberos", win32security.SECPKG_CRED_OUTBOUND, None, None)
> > >>> cred.QueryCredentialsAttributes(1)
> > 'osipovmi at AD001.SIEMENS.NET'

Is this the expected result?

> 
> 
> Findings Java:
> * GssManager#createCredential() with ACCEPT_ONLY or INITIATE_AND_ACCEPT gives me weird credentials with partial null nembers. I'd expect an exception here.

Oops. Will look into. Maybe I should reject.

> * This is one fails, but shall work:
> > GSSManager manager = GSSManager.getInstance();
> > GSSName userName = manager.createName("osipovmi", GSSName.NT_USER_NAME);
> > GSSCredential cred = manager.createCredential(userName, GSSCredential.DEFAULT_LIFETIME, krb5Oid, GSSCredential.INITIATE_ONLY);
> > [SSPI:1627] >>>> Calling gss_create_empty_oid_set...
> > [SSPI:1542] >>>> Calling gss_add_oid_set_member...
> > [SSPI:612] >>>> Calling gss_acquire_cred...
> > [SSPI:619] AcquireCredentialsHandle with 0 00000257FFB199B0
> > [SSPI:262] gss_OID_set.count is 1
> > [SSPI:237] Kerberos mech
> > [SSPI:628] reqKerberos
> > [SSPI:152] cred expiration: 09/13/30828  04:48 4294967295ld
> > [SSPI:732] Acquiring cred with a name. Check if it's me.
> > [SSPI:791] >>>> Calling gss_inquire_cred...
> > [SSPI:811] Allocate new name at 00000257FFB2BC40
> > [SSPI:428] >>>> Calling gss_compare_name...
> > [SSPI:437] Comparing osipovmi at AD001.SIEMENS.NET and osipovmi
> > [SSPI:325] >>>> Calling gss_release_name 00000257FFB17830...
> > [SSPI:744] Comparing result: 0
> > [SSPI:767] >>>> Calling gss_release_cred...
> > [SSPI:1641] >>>> Calling gss_release_oid_set...
> > Exception in thread "main" GSSException: Failure unspecified at GSS-API level
> > 	at java.security.jgss/sun.security.jgss.wrapper.GSSLibStub.acquireCred(Native Method)
> 
> The problem is that I provide a local name and expect the default realm to be used. It seems like #createCredential() does not take that into account. It also has no avail when the canonicalized form is used. See sspi.cpp#L729-L748.
> * GssManager#createContext(GSSCredential) still works although this should be a acceptor context. I expect an expception. Does not fail with JGSS either. MIT Kerberos with py-gssapi properly fails:
> > >>> cred = gssapi.Credentials(usage='accept')                                   >>> cred
> > <gssapi.creds.Credentials object at 0x80164bbb0>
> > >>> context = gssapi.SecurityContext(usage='initiate', creds=cred, name=canon_name, mech=gssapi.MechType.kerberos)
> > >>> context.step(None)
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> >   File "<decorator-gen-15>", line 2, in step
> >   File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", line 167, in check_last_err
> >     return func(self, *args, **kwargs)
> >   File "<decorator-gen-5>", line 2, in step
> >   File "/usr/local/lib/python3.7/site-packages/gssapi/_utils.py", line 127, in catch_and_return_token
> >     return func(self, *args, **kwargs)
> >   File "/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 521, in step
> >     return self._initiator_step(token=token)
> >   File "/usr/local/lib/python3.7/site-packages/gssapi/sec_contexts.py", line 542, in _initiator_step
> >     token)
> >   File "gssapi/raw/sec_contexts.pyx", line 245, in gssapi.raw.sec_contexts.init_sec_context
> > gssapi.raw.exceptions.MissingCredentialsError: Major (458752): Es wurden keine Anmeldedaten ?bergeben oder die Anmeldedaten waren nicht verf?gbar bzw. ein Zugriff darauf nicht m?glich., Minor (100001): Unknown code 0

This looks bad, I'll try it myself. First I'll need to install a Windows VirtualBox guest...

Thanks,
Max

> 
> That's it for now.
> 
> Michael



From anthony.scarpino at oracle.com  Wed Apr 22 23:57:35 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 22 Apr 2020 16:57:35 -0700
Subject: [RFR] 8229148: SSLSession.invalidate() does not invalidate stateless
 tickets
Message-ID: <4395fdcf-b7cf-9943-9896-feed43196b8a@oracle.com>

Hi,

I'd like a review of this change to add session invalidation for 
stateless resumption.  It adds a cache that stateless resumes will check 
against.  The cache keeps track of only those sessions that are 
invalidated, minimizing it's cost on the server.  This is separate from 
the existing session cache method of invalidation.

http://cr.openjdk.java.net/~ascarpino/8229148/webrev.00/

thanks

Tony


From sibabrata.sahoo at oracle.com  Thu Apr 23 07:43:15 2020
From: sibabrata.sahoo at oracle.com (sibabrata.sahoo at oracle.com)
Date: Thu, 23 Apr 2020 13:13:15 +0530
Subject: [15] RFR: 8242929: The values of jdk.tls.namedGroups should not be
 case-sensitive
Message-ID: <EDCA6D19-7D8E-4CB3-A8EA-A5DDE16F3B72@oracle.com>

Hi Xuelei,

Please review the patch for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8242929 <https://bugs.openjdk.java.net/browse/JDK-8242929>
Webrev: http://cr.openjdk.java.net/~ssahoo/8242929/webrev.00/ <http://cr.openjdk.java.net/~ssahoo/8242929/webrev.00/>

This is a small fix to make named groups case insensitive.

Thanks,
Siba



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

From matthias.baesken at sap.com  Thu Apr 23 10:33:55 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 23 Apr 2020 10:33:55 +0000
Subject: jdk/jdk + jdk11 : failing jtreg test
 security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java
Message-ID: <AM0PR02MB5412BF44EEB5AA5838151A8393D30@AM0PR02MB5412.eurprd02.prod.outlook.com>


Hello,   the test   'security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java'
started failing  since last nightly tests (both in jdk/jdk and jdk11) .
Looks like a certificate  has been revoked.

Error is :

=====================================================
Received exception: java.security.cert.CertPathValidatorException: Certificate has been revoked,
reason: SUPERSEDED, revocation date: Tue Apr 21 09:02:18 CEST 2020, authority: CN=Buypass OCSP, O=Buypass AS-983163327, C=NO, extension OIDs: []
Expected Certificate status: GOOD
Certificate status after validation: REVOKED

Is there already a JIRA bug for this ?

Best regards, Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200423/adf359fb/attachment.htm>

From sean.mullan at oracle.com  Thu Apr 23 12:41:27 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 23 Apr 2020 08:41:27 -0400
Subject: jdk/jdk + jdk11 : failing jtreg test
 security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java
In-Reply-To: <AM0PR02MB5412BF44EEB5AA5838151A8393D30@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB5412BF44EEB5AA5838151A8393D30@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <ff5ec8b3-d378-d7cc-1171-be3755bb1442@oracle.com>

On 4/23/20 6:33 AM, Baesken, Matthias wrote:
> Hello,?? the test   
> 'security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java'
> 
> started failing ?since last nightly tests (both in jdk/jdk and jdk11) .
> 
> Looks like a certificate ?has been revoked.
> 
> Error is :
> 
> =====================================================
> 
> Received exception: java.security.cert.CertPathValidatorException: 
> Certificate has been revoked,
> 
> reason: SUPERSEDED, revocation date: Tue Apr 21 09:02:18 CEST 2020, 
> authority: CN=Buypass OCSP, O=Buypass AS-983163327, C=NO, extension OIDs: []
> 
> Expected Certificate status: GOOD
> 
> Certificate status after validation: REVOKED
> 
> Is there already a JIRA bug for this ?

No, please file a bug. We may need to put this on the ProblemList until 
we can resolve the issue with the CA. We probably need to get new test 
certificates.

--Sean


From xuelei.fan at oracle.com  Thu Apr 23 15:40:39 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 23 Apr 2020 08:40:39 -0700
Subject: [15] RFR: 8242929: The values of jdk.tls.namedGroups should not
 be case-sensitive
In-Reply-To: <EDCA6D19-7D8E-4CB3-A8EA-A5DDE16F3B72@oracle.com>
References: <EDCA6D19-7D8E-4CB3-A8EA-A5DDE16F3B72@oracle.com>
Message-ID: <a07642d0-d297-0009-1aaf-5d318e14b481@oracle.com>

It looks fine to me.? Thank you!

Xuelei

On 4/23/2020 12:43 AM, sibabrata.sahoo at oracle.com wrote:
> Hi Xuelei,
>
> Please review the patch for,
> JBS: https://bugs.openjdk.java.net/browse/JDK-8242929
> Webrev: http://cr.openjdk.java.net/~ssahoo/8242929/webrev.00/
>
> This is a small fix to make named groups case insensitive.
>
> Thanks,
> Siba
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200423/a5f22424/attachment.htm>

From xuelei.fan at oracle.com  Thu Apr 23 20:14:21 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 23 Apr 2020 13:14:21 -0700
Subject: RFR JDK-8236464 : SO_LINGER option is ignored by SSLSocket in JDK 11
Message-ID: <9bf9c238-a473-0084-baee-d572cf172830@oracle.com>

Hi,

Could I get the following update reviewed?

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

In the current implementation, the sending of close_notify may not 
respect the SO_LINGER setting in some circumstances.?? With this update, 
the delivering of close_notify alert will consider the impact of the 
SO_LINGER setting.

I can confirm there is an issue per the code, but I cannot reproduce the 
issue by myself.? I'm asking for an external help for the testing.? 
"noreg-hard" and "noreg-external" tags were added to this bug.

Thanks,

Xuelei

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

From valerie.peng at oracle.com  Thu Apr 23 22:28:22 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 23 Apr 2020 15:28:22 -0700
Subject: [15] RFR JDK-8242897 KeyFactory.generatePublic( x509Spec ) failed
 with java.security.InvalidKeyException
Message-ID: <73f67be4-9e09-00da-5a87-b2fa4f99bc91@oracle.com>

Anyone has time to help review this fix? After the support for 
RSASSA-PSS keys is added, when parsing the DER encoding, the key 
algorithm is based on the parsed algorithm oid/name. However, an 
exception is thrown if the parsed algorithm oid/name is neither RSA nor 
RSASSA-PSS. For this particular report, the algorithm oid is 
1.3.14.3.2.15 which is unsupport/unrecognized by JDK. In earlier 
releases, the bytes are parsed but key algorithm is always "RSA".

To maintain this backward compatibility behavior, I changed the current 
impl to set the key algorithm upon key construction time w/ a KeyType 
argument (RSA or RSASSA-PSS) even when DER encoding is given. After 
parsing the DER encoding, for non-RSA keys, the parsed algorithm 
oid/name should match the given key type, otherwise an exception is thrown.

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

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

Mach5 run is clean.

Thanks,
Valerie


From valerie.peng at oracle.com  Thu Apr 23 23:11:45 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 23 Apr 2020 16:11:45 -0700
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security
 providers for aliases registration
Message-ID: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>

Hi Max,

Would you have time to review this change? The current webrev attempts 
to cover all security classes where hard-coded oid strings and 
consolidate these known oid string values into a single enum type. The 
changes are quite extensive, I can trim back and only cover the provider 
algorithm oids if you prefer. There are pros and cons for both approach.

I know that the naming convention is to use all upper case for enum 
constants, but choose to use the same naming convention as standard 
names to simplify the code. SecurityProviderConstants class defines the 
common mappings which are general to providers. Provider-specific alias 
mappings are handled in specific provider class, e.g. SunJSSE class.

RFE: https://bugs.openjdk.java.net/browse/JDK-8242151

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

Mach5 runs clean.

Valerie



From xuelei.fan at oracle.com  Fri Apr 24 05:34:24 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 23 Apr 2020 22:34:24 -0700
Subject: RFR[15] JDK-8243029: Rewrite
 javax/net/ssl/compatibility/Compatibility.java with a flexible interop test
 framework
In-Reply-To: <03ad8c60-2924-d2d4-32ce-175734fcc8dc@oracle.com>
References: <03ad8c60-2924-d2d4-32ce-175734fcc8dc@oracle.com>
Message-ID: <056a4d8a-8f98-145d-6c97-20e177960ede@oracle.com>

Looks good to me.

Thanks,
Xuelei

On 4/19/2020 6:33 PM, sha.jiang at oracle.com wrote:
> Hi,
> This patch introduces a flexible test framework for supporting JSSE 
> interop testing.
> This framework supports the SSL/TLS communication between not only JDK 
> builds,
> but also possibly other TLS implementations.
> 
> The original test cases in 
> javax/net/ssl/compatibility/Compatibility.java are
> divided into 3 separated tests, namely BasicConnectTest.java, 
> SniTest.java and
> AlpnTest.java, and introduces a new compatibility test on TLS 1.3 hello 
> retry
> request, namely HrrTest.java. These tests depend on the aforementioned 
> framework.
> 
> And the negative cases are removed for making the test results clean and 
> clear.
> It doesn't generate result report anymore. All of failed test cases are 
> highlighted
> at the end of a test run.
> 
> Additionally, more compatibility tests will be added.
> 
> Webrev: http://cr.openjdk.java.net/~jjiang/8243029/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8243029
> 
> Best regards,
> John Jiang
> 


From tigran.mkrtchyan at desy.de  Fri Apr 24 08:21:18 2020
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Fri, 24 Apr 2020 10:21:18 +0200 (CEST)
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
Message-ID: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>




Dear Java-SE security developers,


Imagine a following code:

```
Subject s1 = ... ;

Subject s2 = ... ;


s2.getPrincipals().addAll(s1.getPrincipals());

```

The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null' values
by calling collectionNullClean, which calls SecureSet#contains:

```
try {
    hasNullElements = coll.contains(null);
} catch (NullPointerException npe) {

```

The SecureSet#contains itself checks for 'null' values, the  NPE is always generated.

This as introduced by commit e680ab7f208e

https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java


As SecureSet doesn't allow null values, it will be much simpler to return false right away:

```

        public boolean contains(Object o) {
          if (o == null) {
               // null values rejected  by add
               return false;
          }

          ...
        }

```


Thanks in advance,
   Tigran.


From matthias.baesken at sap.com  Fri Apr 24 09:28:36 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 24 Apr 2020 09:28:36 +0000
Subject: jdk/jdk + jdk11 : failing jtreg test
 security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java
Message-ID: <AM0PR02MB5412EBC4BB097734EFBFF80393D00@AM0PR02MB5412.eurprd02.prod.outlook.com>

Hi Sean , I opened 

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

JDK-8243543 : jtreg test security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java fails

Best regards, Matthias


>> Hello,?? the test   
>> 'security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java'
>> 
>> started failing ?since last nightly tests (both in jdk/jdk and jdk11) .
>> 
>> Looks like a certificate ?has been revoked.
>> 
>
>No, please file a bug. We may need to put this on the ProblemList until 
>we can resolve the issue with the CA. We probably need to get new test 
>certificates.
>
>--Sean



From weijun.wang at oracle.com  Fri Apr 24 09:42:41 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 24 Apr 2020 17:42:41 +0800
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
Message-ID: <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>

Hi Tigran,

In java.util.Set, we have:

     * @throws NullPointerException if the specified element is null and this
     *         set does not permit null elements
     * (<a href="Collection.html#optional-restrictions">optional</a>)
     */
    boolean contains(Object o);

As an implementation, SecureSet must follow the spec to throw an NPE. If it returns null, some unexpected thing might happen when the contains() method is called somewhere else.

Thanks,
Max

> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
> 
> 
> 
> 
> Dear Java-SE security developers,
> 
> 
> Imagine a following code:
> 
> ```
> Subject s1 = ... ;
> 
> Subject s2 = ... ;
> 
> 
> s2.getPrincipals().addAll(s1.getPrincipals());
> 
> ```
> 
> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null' values
> by calling collectionNullClean, which calls SecureSet#contains:
> 
> ```
> try {
>    hasNullElements = coll.contains(null);
> } catch (NullPointerException npe) {
> 
> ```
> 
> The SecureSet#contains itself checks for 'null' values, the  NPE is always generated.
> 
> This as introduced by commit e680ab7f208e
> 
> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
> 
> 
> As SecureSet doesn't allow null values, it will be much simpler to return false right away:
> 
> ```
> 
>        public boolean contains(Object o) {
>          if (o == null) {
>               // null values rejected  by add
>               return false;
>          }
> 
>          ...
>        }
> 
> ```
> 
> 
> Thanks in advance,
>   Tigran.



From tigran.mkrtchyan at desy.de  Fri Apr 24 10:13:50 2020
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Fri, 24 Apr 2020 12:13:50 +0200 (CEST)
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
Message-ID: <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>

Hi Max,

that's right, but java doc as well mentions that this exception is *optional*, and has a corresponding note:

Some collection implementations have restrictions on the elements that they may contain. For example, some implementations prohibit null elements, and some have restrictions on the types of their elements. Attempting to add an ineligible element throws an unchecked exception, typically NullPointerException or ClassCastException. Attempting to query the presence of an ineligible element may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter. More generally, attempting an operation on an ineligible element whose completion would not result in the insertion of an ineligible element into the collection may throw an exception or it may succeed, at the option of the implementation. Such exceptions are marked as "optional" in the specification for this interface.

Thus, returning *false* is justified and spec compliant.


Thanks,
   Tigran.


----- Original Message -----
> From: "Weijun Wang" <weijun.wang at oracle.com>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
> Cc: "security-dev" <security-dev at openjdk.java.net>
> Sent: Friday, April 24, 2020 11:42:41 AM
> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol

> Hi Tigran,
> 
> In java.util.Set, we have:
> 
>     * @throws NullPointerException if the specified element is null and this
>     *         set does not permit null elements
>     * (<a href="Collection.html#optional-restrictions">optional</a>)
>     */
>    boolean contains(Object o);
> 
> As an implementation, SecureSet must follow the spec to throw an NPE. If it
> returns null, some unexpected thing might happen when the contains() method is
> called somewhere else.
> 
> Thanks,
> Max
> 
>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>> 
>> 
>> 
>> 
>> Dear Java-SE security developers,
>> 
>> 
>> Imagine a following code:
>> 
>> ```
>> Subject s1 = ... ;
>> 
>> Subject s2 = ... ;
>> 
>> 
>> s2.getPrincipals().addAll(s1.getPrincipals());
>> 
>> ```
>> 
>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>> values
>> by calling collectionNullClean, which calls SecureSet#contains:
>> 
>> ```
>> try {
>>    hasNullElements = coll.contains(null);
>> } catch (NullPointerException npe) {
>> 
>> ```
>> 
>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>> generated.
>> 
>> This as introduced by commit e680ab7f208e
>> 
>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>> 
>> 
>> As SecureSet doesn't allow null values, it will be much simpler to return false
>> right away:
>> 
>> ```
>> 
>>        public boolean contains(Object o) {
>>          if (o == null) {
>>               // null values rejected  by add
>>               return false;
>>          }
>> 
>>          ...
>>        }
>> 
>> ```
>> 
>> 
>> Thanks in advance,
> >   Tigran.


From weijun.wang at oracle.com  Fri Apr 24 10:23:48 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 24 Apr 2020 18:23:48 +0800
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
 <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
Message-ID: <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>

My understanding is by optional you have 2 options while designing the Set:

1. Allow null

2. Not allow null

Now that SecureSet has chosen the 2nd way, it is now in the "this set does not permit null elements" category and therefore it should "@throws NullPointerException if the specified element is null".

--Max

> On Apr 24, 2020, at 6:13 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
> 
> Hi Max,
> 
> that's right, but java doc as well mentions that this exception is *optional*, and has a corresponding note:
> 
> Some collection implementations have restrictions on the elements that they may contain. For example, some implementations prohibit null elements, and some have restrictions on the types of their elements. Attempting to add an ineligible element throws an unchecked exception, typically NullPointerException or ClassCastException. Attempting to query the presence of an ineligible element may throw an exception, or it may simply return false; some implementations will exhibit the former behavior and some will exhibit the latter. More generally, attempting an operation on an ineligible element whose completion would not result in the insertion of an ineligible element into the collection may throw an exception or it may succeed, at the option of the implementation. Such exceptions are marked as "optional" in the specification for this interface.
> 
> Thus, returning *false* is justified and spec compliant.
> 
> 
> Thanks,
>   Tigran.
> 
> 
> ----- Original Message -----
>> From: "Weijun Wang" <weijun.wang at oracle.com>
>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>> Cc: "security-dev" <security-dev at openjdk.java.net>
>> Sent: Friday, April 24, 2020 11:42:41 AM
>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
> 
>> Hi Tigran,
>> 
>> In java.util.Set, we have:
>> 
>>    * @throws NullPointerException if the specified element is null and this
>>    *         set does not permit null elements
>>    * (<a href="Collection.html#optional-restrictions">optional</a>)
>>    */
>>   boolean contains(Object o);
>> 
>> As an implementation, SecureSet must follow the spec to throw an NPE. If it
>> returns null, some unexpected thing might happen when the contains() method is
>> called somewhere else.
>> 
>> Thanks,
>> Max
>> 
>>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>> 
>>> 
>>> 
>>> 
>>> Dear Java-SE security developers,
>>> 
>>> 
>>> Imagine a following code:
>>> 
>>> ```
>>> Subject s1 = ... ;
>>> 
>>> Subject s2 = ... ;
>>> 
>>> 
>>> s2.getPrincipals().addAll(s1.getPrincipals());
>>> 
>>> ```
>>> 
>>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>>> values
>>> by calling collectionNullClean, which calls SecureSet#contains:
>>> 
>>> ```
>>> try {
>>>   hasNullElements = coll.contains(null);
>>> } catch (NullPointerException npe) {
>>> 
>>> ```
>>> 
>>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>>> generated.
>>> 
>>> This as introduced by commit e680ab7f208e
>>> 
>>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>>> 
>>> 
>>> As SecureSet doesn't allow null values, it will be much simpler to return false
>>> right away:
>>> 
>>> ```
>>> 
>>>       public boolean contains(Object o) {
>>>         if (o == null) {
>>>              // null values rejected  by add
>>>              return false;
>>>         }
>>> 
>>>         ...
>>>       }
>>> 
>>> ```
>>> 
>>> 
>>> Thanks in advance,
>>>  Tigran.



From tigran.mkrtchyan at desy.de  Fri Apr 24 10:50:03 2020
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Fri, 24 Apr 2020 12:50:03 +0200 (CEST)
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
 <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
 <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>
Message-ID: <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>

I read it differently:

    Attempting to query the presence of an ineligible element may throw an exception, or it may simply return false; some implementations
    will exhibit the former  behavior and some will exhibit the latter.

Implementation might thrown an exception or return false, but sill don't allow null values.

   ... would not result in the insertion of an ineligible element into the collection may throw an exception or it may
   succeed, at the option of the implementation.


For example, TreeSet throws NPE depending on Comparator.

Well, I understand, this is a corner case that possibly  not worth to optimize. Let me write
a benchmark to see how much difference it makes.

Tigran.


----- Original Message -----
> From: "Weijun Wang" <weijun.wang at oracle.com>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
> Cc: "security-dev" <security-dev at openjdk.java.net>
> Sent: Friday, April 24, 2020 12:23:48 PM
> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol

> My understanding is by optional you have 2 options while designing the Set:
> 
> 1. Allow null
> 
> 2. Not allow null
> 
> Now that SecureSet has chosen the 2nd way, it is now in the "this set does not
> permit null elements" category and therefore it should "@throws
> NullPointerException if the specified element is null".
> 
> --Max
> 
>> On Apr 24, 2020, at 6:13 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>> 
>> Hi Max,
>> 
>> that's right, but java doc as well mentions that this exception is *optional*,
>> and has a corresponding note:
>> 
>> Some collection implementations have restrictions on the elements that they may
>> contain. For example, some implementations prohibit null elements, and some
>> have restrictions on the types of their elements. Attempting to add an
>> ineligible element throws an unchecked exception, typically
>> NullPointerException or ClassCastException. Attempting to query the presence of
>> an ineligible element may throw an exception, or it may simply return false;
>> some implementations will exhibit the former behavior and some will exhibit the
>> latter. More generally, attempting an operation on an ineligible element whose
>> completion would not result in the insertion of an ineligible element into the
>> collection may throw an exception or it may succeed, at the option of the
>> implementation. Such exceptions are marked as "optional" in the specification
>> for this interface.
>> 
>> Thus, returning *false* is justified and spec compliant.
>> 
>> 
>> Thanks,
>>   Tigran.
>> 
>> 
>> ----- Original Message -----
>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>> Sent: Friday, April 24, 2020 11:42:41 AM
>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>> 
>>> Hi Tigran,
>>> 
>>> In java.util.Set, we have:
>>> 
>>>    * @throws NullPointerException if the specified element is null and this
>>>    *         set does not permit null elements
>>>    * (<a href="Collection.html#optional-restrictions">optional</a>)
>>>    */
>>>   boolean contains(Object o);
>>> 
>>> As an implementation, SecureSet must follow the spec to throw an NPE. If it
>>> returns null, some unexpected thing might happen when the contains() method is
>>> called somewhere else.
>>> 
>>> Thanks,
>>> Max
>>> 
>>>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Dear Java-SE security developers,
>>>> 
>>>> 
>>>> Imagine a following code:
>>>> 
>>>> ```
>>>> Subject s1 = ... ;
>>>> 
>>>> Subject s2 = ... ;
>>>> 
>>>> 
>>>> s2.getPrincipals().addAll(s1.getPrincipals());
>>>> 
>>>> ```
>>>> 
>>>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>>>> values
>>>> by calling collectionNullClean, which calls SecureSet#contains:
>>>> 
>>>> ```
>>>> try {
>>>>   hasNullElements = coll.contains(null);
>>>> } catch (NullPointerException npe) {
>>>> 
>>>> ```
>>>> 
>>>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>>>> generated.
>>>> 
>>>> This as introduced by commit e680ab7f208e
>>>> 
>>>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>>>> 
>>>> 
>>>> As SecureSet doesn't allow null values, it will be much simpler to return false
>>>> right away:
>>>> 
>>>> ```
>>>> 
>>>>       public boolean contains(Object o) {
>>>>         if (o == null) {
>>>>              // null values rejected  by add
>>>>              return false;
>>>>         }
>>>> 
>>>>         ...
>>>>       }
>>>> 
>>>> ```
>>>> 
>>>> 
>>>> Thanks in advance,
> >>>  Tigran.


From ecki at zusammenkunft.net  Fri Apr 24 11:23:37 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 24 Apr 2020 11:23:37 +0000
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
 <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
 <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>,
 <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>
Message-ID: <AM6PR03MB4389F435E35830D6D07992B6FFD00@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

I would agree with the interpretation that the NPE is not mandatory.

 But even if we keep it, the actual problem in addAll() should be fixed? There is no point in calling contains(null) on a SecureSet, right?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: security-dev <security-dev-bounces at openjdk.java.net> im Auftrag von Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de>
Gesendet: Freitag, April 24, 2020 12:52 PM
An: Weijun Wang
Cc: security-dev
Betreff: Re: NPE is used in javax.security.auth.Subject for flowcontrol

I read it differently:

    Attempting to query the presence of an ineligible element may throw an exception, or it may simply return false; some implementations
    will exhibit the former  behavior and some will exhibit the latter.

Implementation might thrown an exception or return false, but sill don't allow null values.

   ... would not result in the insertion of an ineligible element into the collection may throw an exception or it may
   succeed, at the option of the implementation.


For example, TreeSet throws NPE depending on Comparator.

Well, I understand, this is a corner case that possibly  not worth to optimize. Let me write
a benchmark to see how much difference it makes.

Tigran.


----- Original Message -----
> From: "Weijun Wang" <weijun.wang at oracle.com>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
> Cc: "security-dev" <security-dev at openjdk.java.net>
> Sent: Friday, April 24, 2020 12:23:48 PM
> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol

> My understanding is by optional you have 2 options while designing the Set:
>
> 1. Allow null
>
> 2. Not allow null
>
> Now that SecureSet has chosen the 2nd way, it is now in the "this set does not
> permit null elements" category and therefore it should "@throws
> NullPointerException if the specified element is null".
>
> --Max
>
>> On Apr 24, 2020, at 6:13 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>
>> Hi Max,
>>
>> that's right, but java doc as well mentions that this exception is *optional*,
>> and has a corresponding note:
>>
>> Some collection implementations have restrictions on the elements that they may
>> contain. For example, some implementations prohibit null elements, and some
>> have restrictions on the types of their elements. Attempting to add an
>> ineligible element throws an unchecked exception, typically
>> NullPointerException or ClassCastException. Attempting to query the presence of
>> an ineligible element may throw an exception, or it may simply return false;
>> some implementations will exhibit the former behavior and some will exhibit the
>> latter. More generally, attempting an operation on an ineligible element whose
>> completion would not result in the insertion of an ineligible element into the
>> collection may throw an exception or it may succeed, at the option of the
>> implementation. Such exceptions are marked as "optional" in the specification
>> for this interface.
>>
>> Thus, returning *false* is justified and spec compliant.
>>
>>
>> Thanks,
>>   Tigran.
>>
>>
>> ----- Original Message -----
>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>> Sent: Friday, April 24, 2020 11:42:41 AM
>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>
>>> Hi Tigran,
>>>
>>> In java.util.Set, we have:
>>>
>>>    * @throws NullPointerException if the specified element is null and this
>>>    *         set does not permit null elements
>>>    * (<a href="Collection.html#optional-restrictions">optional</a>)
>>>    */
>>>   boolean contains(Object o);
>>>
>>> As an implementation, SecureSet must follow the spec to throw an NPE. If it
>>> returns null, some unexpected thing might happen when the contains() method is
>>> called somewhere else.
>>>
>>> Thanks,
>>> Max
>>>
>>>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> Dear Java-SE security developers,
>>>>
>>>>
>>>> Imagine a following code:
>>>>
>>>> ```
>>>> Subject s1 = ... ;
>>>>
>>>> Subject s2 = ... ;
>>>>
>>>>
>>>> s2.getPrincipals().addAll(s1.getPrincipals());
>>>>
>>>> ```
>>>>
>>>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>>>> values
>>>> by calling collectionNullClean, which calls SecureSet#contains:
>>>>
>>>> ```
>>>> try {
>>>>   hasNullElements = coll.contains(null);
>>>> } catch (NullPointerException npe) {
>>>>
>>>> ```
>>>>
>>>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>>>> generated.
>>>>
>>>> This as introduced by commit e680ab7f208e
>>>>
>>>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>>>>
>>>>
>>>> As SecureSet doesn't allow null values, it will be much simpler to return false
>>>> right away:
>>>>
>>>> ```
>>>>
>>>>       public boolean contains(Object o) {
>>>>         if (o == null) {
>>>>              // null values rejected  by add
>>>>              return false;
>>>>         }
>>>>
>>>>         ...
>>>>       }
>>>>
>>>> ```
>>>>
>>>>
>>>> Thanks in advance,
> >>>  Tigran.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200424/6da30e25/attachment.htm>

From tigran.mkrtchyan at desy.de  Fri Apr 24 13:00:28 2020
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Fri, 24 Apr 2020 15:00:28 +0200 (CEST)
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
 <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
 <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>
 <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>
Message-ID: <1076908669.873011.1587733228019.JavaMail.zimbra@desy.de>



Here is the benchmark results:

Benchmark                         Mode  Cnt        Score       Error  Units
SubjectBenchmark.jdkSubject      thrpt   20   473086.025 ?  7661.215  ops/s
SubjectBenchmark.patchedSubject  thrpt   20  2529016.530 ? 50982.465  ops/s

On a one hand, patched version has 5x higher throughput. However, on an other hand
the throughput of the original code is sufficient for any real application. The
benchmark code is attached.

Sorry for the noise. Should have done benchmarks before trying to optimize it.

Tigran.

----- Original Message -----
> From: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
> To: "Weijun Wang" <weijun.wang at oracle.com>
> Cc: "security-dev" <security-dev at openjdk.java.net>
> Sent: Friday, April 24, 2020 12:50:03 PM
> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol

> I read it differently:
> 
>    Attempting to query the presence of an ineligible element may throw an
>    exception, or it may simply return false; some implementations
>    will exhibit the former  behavior and some will exhibit the latter.
> 
> Implementation might thrown an exception or return false, but sill don't allow
> null values.
> 
>   ... would not result in the insertion of an ineligible element into the
>   collection may throw an exception or it may
>   succeed, at the option of the implementation.
> 
> 
> For example, TreeSet throws NPE depending on Comparator.
> 
> Well, I understand, this is a corner case that possibly  not worth to optimize.
> Let me write
> a benchmark to see how much difference it makes.
> 
> Tigran.
> 
> 
> ----- Original Message -----
>> From: "Weijun Wang" <weijun.wang at oracle.com>
>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>> Cc: "security-dev" <security-dev at openjdk.java.net>
>> Sent: Friday, April 24, 2020 12:23:48 PM
>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
> 
>> My understanding is by optional you have 2 options while designing the Set:
>> 
>> 1. Allow null
>> 
>> 2. Not allow null
>> 
>> Now that SecureSet has chosen the 2nd way, it is now in the "this set does not
>> permit null elements" category and therefore it should "@throws
>> NullPointerException if the specified element is null".
>> 
>> --Max
>> 
>>> On Apr 24, 2020, at 6:13 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>> 
>>> Hi Max,
>>> 
>>> that's right, but java doc as well mentions that this exception is *optional*,
>>> and has a corresponding note:
>>> 
>>> Some collection implementations have restrictions on the elements that they may
>>> contain. For example, some implementations prohibit null elements, and some
>>> have restrictions on the types of their elements. Attempting to add an
>>> ineligible element throws an unchecked exception, typically
>>> NullPointerException or ClassCastException. Attempting to query the presence of
>>> an ineligible element may throw an exception, or it may simply return false;
>>> some implementations will exhibit the former behavior and some will exhibit the
>>> latter. More generally, attempting an operation on an ineligible element whose
>>> completion would not result in the insertion of an ineligible element into the
>>> collection may throw an exception or it may succeed, at the option of the
>>> implementation. Such exceptions are marked as "optional" in the specification
>>> for this interface.
>>> 
>>> Thus, returning *false* is justified and spec compliant.
>>> 
>>> 
>>> Thanks,
>>>   Tigran.
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>> Sent: Friday, April 24, 2020 11:42:41 AM
>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>> 
>>>> Hi Tigran,
>>>> 
>>>> In java.util.Set, we have:
>>>> 
>>>>    * @throws NullPointerException if the specified element is null and this
>>>>    *         set does not permit null elements
>>>>    * (<a href="Collection.html#optional-restrictions">optional</a>)
>>>>    */
>>>>   boolean contains(Object o);
>>>> 
>>>> As an implementation, SecureSet must follow the spec to throw an NPE. If it
>>>> returns null, some unexpected thing might happen when the contains() method is
>>>> called somewhere else.
>>>> 
>>>> Thanks,
>>>> Max
>>>> 
>>>>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Dear Java-SE security developers,
>>>>> 
>>>>> 
>>>>> Imagine a following code:
>>>>> 
>>>>> ```
>>>>> Subject s1 = ... ;
>>>>> 
>>>>> Subject s2 = ... ;
>>>>> 
>>>>> 
>>>>> s2.getPrincipals().addAll(s1.getPrincipals());
>>>>> 
>>>>> ```
>>>>> 
>>>>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>>>>> values
>>>>> by calling collectionNullClean, which calls SecureSet#contains:
>>>>> 
>>>>> ```
>>>>> try {
>>>>>   hasNullElements = coll.contains(null);
>>>>> } catch (NullPointerException npe) {
>>>>> 
>>>>> ```
>>>>> 
>>>>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>>>>> generated.
>>>>> 
>>>>> This as introduced by commit e680ab7f208e
>>>>> 
>>>>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>>>>> 
>>>>> 
>>>>> As SecureSet doesn't allow null values, it will be much simpler to return false
>>>>> right away:
>>>>> 
>>>>> ```
>>>>> 
>>>>>       public boolean contains(Object o) {
>>>>>         if (o == null) {
>>>>>              // null values rejected  by add
>>>>>              return false;
>>>>>         }
>>>>> 
>>>>>         ...
>>>>>       }
>>>>> 
>>>>> ```
>>>>> 
>>>>> 
>>>>> Thanks in advance,
> > >>>  Tigran.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SubjectBenchmark.java
Type: text/x-java
Size: 1920 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200424/e114ff0e/SubjectBenchmark.java>

From weijun.wang at oracle.com  Fri Apr 24 13:29:02 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 24 Apr 2020 21:29:02 +0800
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <1076908669.873011.1587733228019.JavaMail.zimbra@desy.de>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
 <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
 <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>
 <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>
 <1076908669.873011.1587733228019.JavaMail.zimbra@desy.de>
Message-ID: <FA4AEB31-6183-4C12-B205-1011C5B045CC@oracle.com>

Hi Tigran,

I read "Collection.html#optional-restrictions" carefully, and yes you're correct. Sorry for my ignorance.

This method is called quite a lot. It might be worth an enhancement.

Thanks,
Max

> On Apr 24, 2020, at 9:00 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
> 
> 
> 
> Here is the benchmark results:
> 
> Benchmark                         Mode  Cnt        Score       Error  Units
> SubjectBenchmark.jdkSubject      thrpt   20   473086.025 ?  7661.215  ops/s
> SubjectBenchmark.patchedSubject  thrpt   20  2529016.530 ? 50982.465  ops/s
> 
> On a one hand, patched version has 5x higher throughput. However, on an other hand
> the throughput of the original code is sufficient for any real application. The
> benchmark code is attached.
> 
> Sorry for the noise. Should have done benchmarks before trying to optimize it.
> 
> Tigran.
> 
> ----- Original Message -----
>> From: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>> To: "Weijun Wang" <weijun.wang at oracle.com>
>> Cc: "security-dev" <security-dev at openjdk.java.net>
>> Sent: Friday, April 24, 2020 12:50:03 PM
>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
> 
>> I read it differently:
>> 
>>   Attempting to query the presence of an ineligible element may throw an
>>   exception, or it may simply return false; some implementations
>>   will exhibit the former  behavior and some will exhibit the latter.
>> 
>> Implementation might thrown an exception or return false, but sill don't allow
>> null values.
>> 
>>  ... would not result in the insertion of an ineligible element into the
>>  collection may throw an exception or it may
>>  succeed, at the option of the implementation.
>> 
>> 
>> For example, TreeSet throws NPE depending on Comparator.
>> 
>> Well, I understand, this is a corner case that possibly  not worth to optimize.
>> Let me write
>> a benchmark to see how much difference it makes.
>> 
>> Tigran.
>> 
>> 
>> ----- Original Message -----
>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>> Sent: Friday, April 24, 2020 12:23:48 PM
>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>> 
>>> My understanding is by optional you have 2 options while designing the Set:
>>> 
>>> 1. Allow null
>>> 
>>> 2. Not allow null
>>> 
>>> Now that SecureSet has chosen the 2nd way, it is now in the "this set does not
>>> permit null elements" category and therefore it should "@throws
>>> NullPointerException if the specified element is null".
>>> 
>>> --Max
>>> 
>>>> On Apr 24, 2020, at 6:13 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>> 
>>>> Hi Max,
>>>> 
>>>> that's right, but java doc as well mentions that this exception is *optional*,
>>>> and has a corresponding note:
>>>> 
>>>> Some collection implementations have restrictions on the elements that they may
>>>> contain. For example, some implementations prohibit null elements, and some
>>>> have restrictions on the types of their elements. Attempting to add an
>>>> ineligible element throws an unchecked exception, typically
>>>> NullPointerException or ClassCastException. Attempting to query the presence of
>>>> an ineligible element may throw an exception, or it may simply return false;
>>>> some implementations will exhibit the former behavior and some will exhibit the
>>>> latter. More generally, attempting an operation on an ineligible element whose
>>>> completion would not result in the insertion of an ineligible element into the
>>>> collection may throw an exception or it may succeed, at the option of the
>>>> implementation. Such exceptions are marked as "optional" in the specification
>>>> for this interface.
>>>> 
>>>> Thus, returning *false* is justified and spec compliant.
>>>> 
>>>> 
>>>> Thanks,
>>>>  Tigran.
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>>> Sent: Friday, April 24, 2020 11:42:41 AM
>>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>>> 
>>>>> Hi Tigran,
>>>>> 
>>>>> In java.util.Set, we have:
>>>>> 
>>>>>   * @throws NullPointerException if the specified element is null and this
>>>>>   *         set does not permit null elements
>>>>>   * (<a href="Collection.html#optional-restrictions">optional</a>)
>>>>>   */
>>>>>  boolean contains(Object o);
>>>>> 
>>>>> As an implementation, SecureSet must follow the spec to throw an NPE. If it
>>>>> returns null, some unexpected thing might happen when the contains() method is
>>>>> called somewhere else.
>>>>> 
>>>>> Thanks,
>>>>> Max
>>>>> 
>>>>>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Dear Java-SE security developers,
>>>>>> 
>>>>>> 
>>>>>> Imagine a following code:
>>>>>> 
>>>>>> ```
>>>>>> Subject s1 = ... ;
>>>>>> 
>>>>>> Subject s2 = ... ;
>>>>>> 
>>>>>> 
>>>>>> s2.getPrincipals().addAll(s1.getPrincipals());
>>>>>> 
>>>>>> ```
>>>>>> 
>>>>>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>>>>>> values
>>>>>> by calling collectionNullClean, which calls SecureSet#contains:
>>>>>> 
>>>>>> ```
>>>>>> try {
>>>>>>  hasNullElements = coll.contains(null);
>>>>>> } catch (NullPointerException npe) {
>>>>>> 
>>>>>> ```
>>>>>> 
>>>>>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>>>>>> generated.
>>>>>> 
>>>>>> This as introduced by commit e680ab7f208e
>>>>>> 
>>>>>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>>>>>> 
>>>>>> 
>>>>>> As SecureSet doesn't allow null values, it will be much simpler to return false
>>>>>> right away:
>>>>>> 
>>>>>> ```
>>>>>> 
>>>>>>      public boolean contains(Object o) {
>>>>>>        if (o == null) {
>>>>>>             // null values rejected  by add
>>>>>>             return false;
>>>>>>        }
>>>>>> 
>>>>>>        ...
>>>>>>      }
>>>>>> 
>>>>>> ```
>>>>>> 
>>>>>> 
>>>>>> Thanks in advance,
>>>>>> Tigran.
> <SubjectBenchmark.java>



From tigran.mkrtchyan at desy.de  Fri Apr 24 13:54:23 2020
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Fri, 24 Apr 2020 15:54:23 +0200 (CEST)
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <FA4AEB31-6183-4C12-B205-1011C5B045CC@oracle.com>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
 <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
 <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>
 <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>
 <1076908669.873011.1587733228019.JavaMail.zimbra@desy.de>
 <FA4AEB31-6183-4C12-B205-1011C5B045CC@oracle.com>
Message-ID: <69965046.884055.1587736463235.JavaMail.zimbra@desy.de>

Hi Max,

Do you want me to go though official contribution (I already have signed OCA for glassfish) or
someone from oracle team will take care about it?

Thanks,
  Tigran.

----- Original Message -----
> From: "Weijun Wang" <weijun.wang at oracle.com>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
> Cc: "security-dev" <security-dev at openjdk.java.net>
> Sent: Friday, April 24, 2020 3:29:02 PM
> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol

> Hi Tigran,
> 
> I read "Collection.html#optional-restrictions" carefully, and yes you're
> correct. Sorry for my ignorance.
> 
> This method is called quite a lot. It might be worth an enhancement.
> 
> Thanks,
> Max
> 
>> On Apr 24, 2020, at 9:00 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>> 
>> 
>> 
>> Here is the benchmark results:
>> 
>> Benchmark                         Mode  Cnt        Score       Error  Units
>> SubjectBenchmark.jdkSubject      thrpt   20   473086.025 ?  7661.215  ops/s
>> SubjectBenchmark.patchedSubject  thrpt   20  2529016.530 ? 50982.465  ops/s
>> 
>> On a one hand, patched version has 5x higher throughput. However, on an other
>> hand
>> the throughput of the original code is sufficient for any real application. The
>> benchmark code is attached.
>> 
>> Sorry for the noise. Should have done benchmarks before trying to optimize it.
>> 
>> Tigran.
>> 
>> ----- Original Message -----
>>> From: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>> To: "Weijun Wang" <weijun.wang at oracle.com>
>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>> Sent: Friday, April 24, 2020 12:50:03 PM
>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>> 
>>> I read it differently:
>>> 
>>>   Attempting to query the presence of an ineligible element may throw an
>>>   exception, or it may simply return false; some implementations
>>>   will exhibit the former  behavior and some will exhibit the latter.
>>> 
>>> Implementation might thrown an exception or return false, but sill don't allow
>>> null values.
>>> 
>>>  ... would not result in the insertion of an ineligible element into the
>>>  collection may throw an exception or it may
>>>  succeed, at the option of the implementation.
>>> 
>>> 
>>> For example, TreeSet throws NPE depending on Comparator.
>>> 
>>> Well, I understand, this is a corner case that possibly  not worth to optimize.
>>> Let me write
>>> a benchmark to see how much difference it makes.
>>> 
>>> Tigran.
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>> Sent: Friday, April 24, 2020 12:23:48 PM
>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>> 
>>>> My understanding is by optional you have 2 options while designing the Set:
>>>> 
>>>> 1. Allow null
>>>> 
>>>> 2. Not allow null
>>>> 
>>>> Now that SecureSet has chosen the 2nd way, it is now in the "this set does not
>>>> permit null elements" category and therefore it should "@throws
>>>> NullPointerException if the specified element is null".
>>>> 
>>>> --Max
>>>> 
>>>>> On Apr 24, 2020, at 6:13 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>> 
>>>>> Hi Max,
>>>>> 
>>>>> that's right, but java doc as well mentions that this exception is *optional*,
>>>>> and has a corresponding note:
>>>>> 
>>>>> Some collection implementations have restrictions on the elements that they may
>>>>> contain. For example, some implementations prohibit null elements, and some
>>>>> have restrictions on the types of their elements. Attempting to add an
>>>>> ineligible element throws an unchecked exception, typically
>>>>> NullPointerException or ClassCastException. Attempting to query the presence of
>>>>> an ineligible element may throw an exception, or it may simply return false;
>>>>> some implementations will exhibit the former behavior and some will exhibit the
>>>>> latter. More generally, attempting an operation on an ineligible element whose
>>>>> completion would not result in the insertion of an ineligible element into the
>>>>> collection may throw an exception or it may succeed, at the option of the
>>>>> implementation. Such exceptions are marked as "optional" in the specification
>>>>> for this interface.
>>>>> 
>>>>> Thus, returning *false* is justified and spec compliant.
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>>  Tigran.
>>>>> 
>>>>> 
>>>>> ----- Original Message -----
>>>>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>>>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>>>> Sent: Friday, April 24, 2020 11:42:41 AM
>>>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>>>> 
>>>>>> Hi Tigran,
>>>>>> 
>>>>>> In java.util.Set, we have:
>>>>>> 
>>>>>>   * @throws NullPointerException if the specified element is null and this
>>>>>>   *         set does not permit null elements
>>>>>>   * (<a href="Collection.html#optional-restrictions">optional</a>)
>>>>>>   */
>>>>>>  boolean contains(Object o);
>>>>>> 
>>>>>> As an implementation, SecureSet must follow the spec to throw an NPE. If it
>>>>>> returns null, some unexpected thing might happen when the contains() method is
>>>>>> called somewhere else.
>>>>>> 
>>>>>> Thanks,
>>>>>> Max
>>>>>> 
>>>>>>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Dear Java-SE security developers,
>>>>>>> 
>>>>>>> 
>>>>>>> Imagine a following code:
>>>>>>> 
>>>>>>> ```
>>>>>>> Subject s1 = ... ;
>>>>>>> 
>>>>>>> Subject s2 = ... ;
>>>>>>> 
>>>>>>> 
>>>>>>> s2.getPrincipals().addAll(s1.getPrincipals());
>>>>>>> 
>>>>>>> ```
>>>>>>> 
>>>>>>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>>>>>>> values
>>>>>>> by calling collectionNullClean, which calls SecureSet#contains:
>>>>>>> 
>>>>>>> ```
>>>>>>> try {
>>>>>>>  hasNullElements = coll.contains(null);
>>>>>>> } catch (NullPointerException npe) {
>>>>>>> 
>>>>>>> ```
>>>>>>> 
>>>>>>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>>>>>>> generated.
>>>>>>> 
>>>>>>> This as introduced by commit e680ab7f208e
>>>>>>> 
>>>>>>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>>>>>>> 
>>>>>>> 
>>>>>>> As SecureSet doesn't allow null values, it will be much simpler to return false
>>>>>>> right away:
>>>>>>> 
>>>>>>> ```
>>>>>>> 
>>>>>>>      public boolean contains(Object o) {
>>>>>>>        if (o == null) {
>>>>>>>             // null values rejected  by add
>>>>>>>             return false;
>>>>>>>        }
>>>>>>> 
>>>>>>>        ...
>>>>>>>      }
>>>>>>> 
>>>>>>> ```
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks in advance,
>>>>>>> Tigran.
> > <SubjectBenchmark.java>


From weijun.wang at oracle.com  Fri Apr 24 14:21:27 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 24 Apr 2020 22:21:27 +0800
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <69965046.884055.1587736463235.JavaMail.zimbra@desy.de>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <6FE2B40E-1211-454C-B9EC-D85EBB58556C@oracle.com>
 <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
 <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>
 <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>
 <1076908669.873011.1587733228019.JavaMail.zimbra@desy.de>
 <FA4AEB31-6183-4C12-B205-1011C5B045CC@oracle.com>
 <69965046.884055.1587736463235.JavaMail.zimbra@desy.de>
Message-ID: <0524D60B-761F-4CC3-82EE-8A8BE0B14B1D@oracle.com>

You can send me a patch and I can sponsor it.

Thanks,
Max

> On Apr 24, 2020, at 9:54 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
> 
> Hi Max,
> 
> Do you want me to go though official contribution (I already have signed OCA for glassfish) or
> someone from oracle team will take care about it?
> 
> Thanks,
>  Tigran.
> 
> ----- Original Message -----
>> From: "Weijun Wang" <weijun.wang at oracle.com>
>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>> Cc: "security-dev" <security-dev at openjdk.java.net>
>> Sent: Friday, April 24, 2020 3:29:02 PM
>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
> 
>> Hi Tigran,
>> 
>> I read "Collection.html#optional-restrictions" carefully, and yes you're
>> correct. Sorry for my ignorance.
>> 
>> This method is called quite a lot. It might be worth an enhancement.
>> 
>> Thanks,
>> Max
>> 
>>> On Apr 24, 2020, at 9:00 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>> 
>>> 
>>> 
>>> Here is the benchmark results:
>>> 
>>> Benchmark                         Mode  Cnt        Score       Error  Units
>>> SubjectBenchmark.jdkSubject      thrpt   20   473086.025 ?  7661.215  ops/s
>>> SubjectBenchmark.patchedSubject  thrpt   20  2529016.530 ? 50982.465  ops/s
>>> 
>>> On a one hand, patched version has 5x higher throughput. However, on an other
>>> hand
>>> the throughput of the original code is sufficient for any real application. The
>>> benchmark code is attached.
>>> 
>>> Sorry for the noise. Should have done benchmarks before trying to optimize it.
>>> 
>>> Tigran.
>>> 
>>> ----- Original Message -----
>>>> From: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>> To: "Weijun Wang" <weijun.wang at oracle.com>
>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>> Sent: Friday, April 24, 2020 12:50:03 PM
>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>> 
>>>> I read it differently:
>>>> 
>>>>  Attempting to query the presence of an ineligible element may throw an
>>>>  exception, or it may simply return false; some implementations
>>>>  will exhibit the former  behavior and some will exhibit the latter.
>>>> 
>>>> Implementation might thrown an exception or return false, but sill don't allow
>>>> null values.
>>>> 
>>>> ... would not result in the insertion of an ineligible element into the
>>>> collection may throw an exception or it may
>>>> succeed, at the option of the implementation.
>>>> 
>>>> 
>>>> For example, TreeSet throws NPE depending on Comparator.
>>>> 
>>>> Well, I understand, this is a corner case that possibly  not worth to optimize.
>>>> Let me write
>>>> a benchmark to see how much difference it makes.
>>>> 
>>>> Tigran.
>>>> 
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>>> Sent: Friday, April 24, 2020 12:23:48 PM
>>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>>> 
>>>>> My understanding is by optional you have 2 options while designing the Set:
>>>>> 
>>>>> 1. Allow null
>>>>> 
>>>>> 2. Not allow null
>>>>> 
>>>>> Now that SecureSet has chosen the 2nd way, it is now in the "this set does not
>>>>> permit null elements" category and therefore it should "@throws
>>>>> NullPointerException if the specified element is null".
>>>>> 
>>>>> --Max
>>>>> 
>>>>>> On Apr 24, 2020, at 6:13 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>>> 
>>>>>> Hi Max,
>>>>>> 
>>>>>> that's right, but java doc as well mentions that this exception is *optional*,
>>>>>> and has a corresponding note:
>>>>>> 
>>>>>> Some collection implementations have restrictions on the elements that they may
>>>>>> contain. For example, some implementations prohibit null elements, and some
>>>>>> have restrictions on the types of their elements. Attempting to add an
>>>>>> ineligible element throws an unchecked exception, typically
>>>>>> NullPointerException or ClassCastException. Attempting to query the presence of
>>>>>> an ineligible element may throw an exception, or it may simply return false;
>>>>>> some implementations will exhibit the former behavior and some will exhibit the
>>>>>> latter. More generally, attempting an operation on an ineligible element whose
>>>>>> completion would not result in the insertion of an ineligible element into the
>>>>>> collection may throw an exception or it may succeed, at the option of the
>>>>>> implementation. Such exceptions are marked as "optional" in the specification
>>>>>> for this interface.
>>>>>> 
>>>>>> Thus, returning *false* is justified and spec compliant.
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> Tigran.
>>>>>> 
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>>>>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>>>>> Sent: Friday, April 24, 2020 11:42:41 AM
>>>>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>>>>> 
>>>>>>> Hi Tigran,
>>>>>>> 
>>>>>>> In java.util.Set, we have:
>>>>>>> 
>>>>>>>  * @throws NullPointerException if the specified element is null and this
>>>>>>>  *         set does not permit null elements
>>>>>>>  * (<a href="Collection.html#optional-restrictions">optional</a>)
>>>>>>>  */
>>>>>>> boolean contains(Object o);
>>>>>>> 
>>>>>>> As an implementation, SecureSet must follow the spec to throw an NPE. If it
>>>>>>> returns null, some unexpected thing might happen when the contains() method is
>>>>>>> called somewhere else.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Max
>>>>>>> 
>>>>>>>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Dear Java-SE security developers,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Imagine a following code:
>>>>>>>> 
>>>>>>>> ```
>>>>>>>> Subject s1 = ... ;
>>>>>>>> 
>>>>>>>> Subject s2 = ... ;
>>>>>>>> 
>>>>>>>> 
>>>>>>>> s2.getPrincipals().addAll(s1.getPrincipals());
>>>>>>>> 
>>>>>>>> ```
>>>>>>>> 
>>>>>>>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>>>>>>>> values
>>>>>>>> by calling collectionNullClean, which calls SecureSet#contains:
>>>>>>>> 
>>>>>>>> ```
>>>>>>>> try {
>>>>>>>> hasNullElements = coll.contains(null);
>>>>>>>> } catch (NullPointerException npe) {
>>>>>>>> 
>>>>>>>> ```
>>>>>>>> 
>>>>>>>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>>>>>>>> generated.
>>>>>>>> 
>>>>>>>> This as introduced by commit e680ab7f208e
>>>>>>>> 
>>>>>>>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>>>>>>>> 
>>>>>>>> 
>>>>>>>> As SecureSet doesn't allow null values, it will be much simpler to return false
>>>>>>>> right away:
>>>>>>>> 
>>>>>>>> ```
>>>>>>>> 
>>>>>>>>     public boolean contains(Object o) {
>>>>>>>>       if (o == null) {
>>>>>>>>            // null values rejected  by add
>>>>>>>>            return false;
>>>>>>>>       }
>>>>>>>> 
>>>>>>>>       ...
>>>>>>>>     }
>>>>>>>> 
>>>>>>>> ```
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks in advance,
>>>>>>>> Tigran.
>>> <SubjectBenchmark.java>



From sha.jiang at oracle.com  Fri Apr 24 15:42:12 2020
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Fri, 24 Apr 2020 23:42:12 +0800
Subject: RFR[15] JDK-8243549:
 sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java failed with
 Unsupported signature algorithm: DSA
Message-ID: <ac2b0c0e-7ddf-b77f-dfb2-e9cbe7a1fb4a@oracle.com>

Hi,
DHE_DSS cipher suites cannot work with SHA256withDSA (key size 2048) 
certificates over pre-TLSv1.2 protocols.
Please see JDK-8242928 for more details.

This fix takes the test to use a SHA1withDSA certificate (key size 1024) 
for TLSv1 and TLSv1.1.

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

Best regards,
John Jiang



From xuelei.fan at oracle.com  Fri Apr 24 16:47:07 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 24 Apr 2020 09:47:07 -0700
Subject: RFR[15] JDK-8243549:
 sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java failed with
 Unsupported signature algorithm: DSA
In-Reply-To: <ac2b0c0e-7ddf-b77f-dfb2-e9cbe7a1fb4a@oracle.com>
References: <ac2b0c0e-7ddf-b77f-dfb2-e9cbe7a1fb4a@oracle.com>
Message-ID: <f25cfc93-9a0c-682f-7e0b-c26e12b87de4@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 4/24/2020 8:42 AM, sha.jiang at oracle.com wrote:
> Hi,
> DHE_DSS cipher suites cannot work with SHA256withDSA (key size 2048) 
> certificates over pre-TLSv1.2 protocols.
> Please see JDK-8242928 for more details.
> 
> This fix takes the test to use a SHA1withDSA certificate (key size 1024) 
> for TLSv1 and TLSv1.1.
> 
> Webrev: http://cr.openjdk.java.net/~jjiang/8243549/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8243549
> 
> Best regards,
> John Jiang
> 


From Roger.Riggs at oracle.com  Fri Apr 24 17:03:12 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 24 Apr 2020 13:03:12 -0400
Subject: RFR 15: 8243010: Test support: Customizable Hex Printer (and
 security test updates)
In-Reply-To: <4c1caa7c-7569-fdc2-d525-7824929b95ad@oracle.com>
References: <9c191999-b265-68a5-2188-ee2b9168dd17@oracle.com>
 <e39872c0-963c-f651-293d-bcb0af0eeb5c@oracle.com>
 <4c1caa7c-7569-fdc2-d525-7824929b95ad@oracle.com>
Message-ID: <34235666-f73e-e624-3987-2c054984cf5d@oracle.com>

To correct an oversight to include security-dev in the reviews...
Several security tests were modified to use the HexPrinter instead of 
HexDumpEncoder.


Please review[2] and comment on a new Hex printing utility to support 
OpenJDK tests.
The usefulness of a hex printing has been discussed from time to time with
many suggestions as to the API shape and features.

To get an idea of the API and features, take a look at the javadoc[1].
It covers the basic formatting of offset, and values, and extends the
descriptive part beyond simple ASCII or printable so that a custom 
formatter
can interpret the byte stream in parallel to the bytes.

The webrev includes changes to existing tests that currently
use HexDumpEncoder to use HexPrinter.

Comments appreciated, Roger

[1]Javadoc:
http://cr.openjdk.java.net/~rriggs/webrev-hexprinter-8243010/javadoc

[2] Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-hexprinter-8243010/

[3] Issue:
https://bugs.openjdk.java.net/browse/JDK-8243010


From anthony.scarpino at oracle.com  Fri Apr 24 17:08:32 2020
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 24 Apr 2020 10:08:32 -0700
Subject: RFR JDK-8236464 : SO_LINGER option is ignored by SSLSocket in JDK
 11
In-Reply-To: <9bf9c238-a473-0084-baee-d572cf172830@oracle.com>
References: <9bf9c238-a473-0084-baee-d572cf172830@oracle.com>
Message-ID: <7cb31094-61e9-eb05-9cfa-d1339b4802cb@oracle.com>

On 4/23/20 1:14 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed?
> 
> http://cr.openjdk.java.net/~xuelei/8236464/webrev.00/
> 
> In the current implementation, the sending of close_notify may not 
> respect the SO_LINGER setting in some circumstances.?? With this update, 
> the delivering of close_notify alert will consider the impact of the 
> SO_LINGER setting.
> 
> I can confirm there is an issue per the code, but I cannot reproduce the 
> issue by myself.? I'm asking for an external help for the testing.  
> "noreg-hard" and "noreg-external" tags were added to this bug.
> 
> Thanks,
> 
> Xuelei
> 
Looks good..  with one minor typo:
TransportContext.java
259  // Socket transport is a special because of the SO_LINGER impact.

remove the 'a'

No need for re-review

Tony


From tigran.mkrtchyan at desy.de  Fri Apr 24 17:58:52 2020
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Fri, 24 Apr 2020 19:58:52 +0200 (CEST)
Subject: NPE is used in javax.security.auth.Subject for flowcontrol
In-Reply-To: <0524D60B-761F-4CC3-82EE-8A8BE0B14B1D@oracle.com>
References: <1264394564.798491.1587716478705.JavaMail.zimbra@desy.de>
 <1330501434.833221.1587723230958.JavaMail.zimbra@desy.de>
 <4A8B5494-8751-4EF5-B6C9-8423E6ED3714@oracle.com>
 <104811967.840481.1587725403032.JavaMail.zimbra@desy.de>
 <1076908669.873011.1587733228019.JavaMail.zimbra@desy.de>
 <FA4AEB31-6183-4C12-B205-1011C5B045CC@oracle.com>
 <69965046.884055.1587736463235.JavaMail.zimbra@desy.de>
 <0524D60B-761F-4CC3-82EE-8A8BE0B14B1D@oracle.com>
Message-ID: <541314948.935245.1587751132640.JavaMail.zimbra@desy.de>


The patch is attached.


Thanks,
   Tigran.

----- Original Message -----
> From: "Weijun Wang" <weijun.wang at oracle.com>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
> Cc: "security-dev" <security-dev at openjdk.java.net>
> Sent: Friday, April 24, 2020 4:21:27 PM
> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol

> You can send me a patch and I can sponsor it.
> 
> Thanks,
> Max
> 
>> On Apr 24, 2020, at 9:54 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>> 
>> Hi Max,
>> 
>> Do you want me to go though official contribution (I already have signed OCA for
>> glassfish) or
>> someone from oracle team will take care about it?
>> 
>> Thanks,
>>  Tigran.
>> 
>> ----- Original Message -----
>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>> Sent: Friday, April 24, 2020 3:29:02 PM
>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>> 
>>> Hi Tigran,
>>> 
>>> I read "Collection.html#optional-restrictions" carefully, and yes you're
>>> correct. Sorry for my ignorance.
>>> 
>>> This method is called quite a lot. It might be worth an enhancement.
>>> 
>>> Thanks,
>>> Max
>>> 
>>>> On Apr 24, 2020, at 9:00 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>> 
>>>> 
>>>> 
>>>> Here is the benchmark results:
>>>> 
>>>> Benchmark                         Mode  Cnt        Score       Error  Units
>>>> SubjectBenchmark.jdkSubject      thrpt   20   473086.025 ?  7661.215  ops/s
>>>> SubjectBenchmark.patchedSubject  thrpt   20  2529016.530 ? 50982.465  ops/s
>>>> 
>>>> On a one hand, patched version has 5x higher throughput. However, on an other
>>>> hand
>>>> the throughput of the original code is sufficient for any real application. The
>>>> benchmark code is attached.
>>>> 
>>>> Sorry for the noise. Should have done benchmarks before trying to optimize it.
>>>> 
>>>> Tigran.
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>>> To: "Weijun Wang" <weijun.wang at oracle.com>
>>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>>> Sent: Friday, April 24, 2020 12:50:03 PM
>>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>>> 
>>>>> I read it differently:
>>>>> 
>>>>>  Attempting to query the presence of an ineligible element may throw an
>>>>>  exception, or it may simply return false; some implementations
>>>>>  will exhibit the former  behavior and some will exhibit the latter.
>>>>> 
>>>>> Implementation might thrown an exception or return false, but sill don't allow
>>>>> null values.
>>>>> 
>>>>> ... would not result in the insertion of an ineligible element into the
>>>>> collection may throw an exception or it may
>>>>> succeed, at the option of the implementation.
>>>>> 
>>>>> 
>>>>> For example, TreeSet throws NPE depending on Comparator.
>>>>> 
>>>>> Well, I understand, this is a corner case that possibly  not worth to optimize.
>>>>> Let me write
>>>>> a benchmark to see how much difference it makes.
>>>>> 
>>>>> Tigran.
>>>>> 
>>>>> 
>>>>> ----- Original Message -----
>>>>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>>>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>>>> Sent: Friday, April 24, 2020 12:23:48 PM
>>>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>>>> 
>>>>>> My understanding is by optional you have 2 options while designing the Set:
>>>>>> 
>>>>>> 1. Allow null
>>>>>> 
>>>>>> 2. Not allow null
>>>>>> 
>>>>>> Now that SecureSet has chosen the 2nd way, it is now in the "this set does not
>>>>>> permit null elements" category and therefore it should "@throws
>>>>>> NullPointerException if the specified element is null".
>>>>>> 
>>>>>> --Max
>>>>>> 
>>>>>>> On Apr 24, 2020, at 6:13 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>>>> 
>>>>>>> Hi Max,
>>>>>>> 
>>>>>>> that's right, but java doc as well mentions that this exception is *optional*,
>>>>>>> and has a corresponding note:
>>>>>>> 
>>>>>>> Some collection implementations have restrictions on the elements that they may
>>>>>>> contain. For example, some implementations prohibit null elements, and some
>>>>>>> have restrictions on the types of their elements. Attempting to add an
>>>>>>> ineligible element throws an unchecked exception, typically
>>>>>>> NullPointerException or ClassCastException. Attempting to query the presence of
>>>>>>> an ineligible element may throw an exception, or it may simply return false;
>>>>>>> some implementations will exhibit the former behavior and some will exhibit the
>>>>>>> latter. More generally, attempting an operation on an ineligible element whose
>>>>>>> completion would not result in the insertion of an ineligible element into the
>>>>>>> collection may throw an exception or it may succeed, at the option of the
>>>>>>> implementation. Such exceptions are marked as "optional" in the specification
>>>>>>> for this interface.
>>>>>>> 
>>>>>>> Thus, returning *false* is justified and spec compliant.
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Tigran.
>>>>>>> 
>>>>>>> 
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Weijun Wang" <weijun.wang at oracle.com>
>>>>>>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan at desy.de>
>>>>>>>> Cc: "security-dev" <security-dev at openjdk.java.net>
>>>>>>>> Sent: Friday, April 24, 2020 11:42:41 AM
>>>>>>>> Subject: Re: NPE is used in javax.security.auth.Subject for flowcontrol
>>>>>>> 
>>>>>>>> Hi Tigran,
>>>>>>>> 
>>>>>>>> In java.util.Set, we have:
>>>>>>>> 
>>>>>>>>  * @throws NullPointerException if the specified element is null and this
>>>>>>>>  *         set does not permit null elements
>>>>>>>>  * (<a href="Collection.html#optional-restrictions">optional</a>)
>>>>>>>>  */
>>>>>>>> boolean contains(Object o);
>>>>>>>> 
>>>>>>>> As an implementation, SecureSet must follow the spec to throw an NPE. If it
>>>>>>>> returns null, some unexpected thing might happen when the contains() method is
>>>>>>>> called somewhere else.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Max
>>>>>>>> 
>>>>>>>>> On Apr 24, 2020, at 4:21 PM, Mkrtchyan, Tigran <tigran.mkrtchyan at desy.de> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Dear Java-SE security developers,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Imagine a following code:
>>>>>>>>> 
>>>>>>>>> ```
>>>>>>>>> Subject s1 = ... ;
>>>>>>>>> 
>>>>>>>>> Subject s2 = ... ;
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> s2.getPrincipals().addAll(s1.getPrincipals());
>>>>>>>>> 
>>>>>>>>> ```
>>>>>>>>> 
>>>>>>>>> The Subject's SecureSet.addAll checks that provided Set doesn't contains 'null'
>>>>>>>>> values
>>>>>>>>> by calling collectionNullClean, which calls SecureSet#contains:
>>>>>>>>> 
>>>>>>>>> ```
>>>>>>>>> try {
>>>>>>>>> hasNullElements = coll.contains(null);
>>>>>>>>> } catch (NullPointerException npe) {
>>>>>>>>> 
>>>>>>>>> ```
>>>>>>>>> 
>>>>>>>>> The SecureSet#contains itself checks for 'null' values, the  NPE is always
>>>>>>>>> generated.
>>>>>>>>> 
>>>>>>>>> This as introduced by commit e680ab7f208e
>>>>>>>>> 
>>>>>>>>> https://hg.openjdk.java.net/jdk/jdk/diff/e680ab7f208e/jdk/src/share/classes/javax/security/auth/Subject.java
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> As SecureSet doesn't allow null values, it will be much simpler to return false
>>>>>>>>> right away:
>>>>>>>>> 
>>>>>>>>> ```
>>>>>>>>> 
>>>>>>>>>     public boolean contains(Object o) {
>>>>>>>>>       if (o == null) {
>>>>>>>>>            // null values rejected  by add
>>>>>>>>>            return false;
>>>>>>>>>       }
>>>>>>>>> 
>>>>>>>>>       ...
>>>>>>>>>     }
>>>>>>>>> 
>>>>>>>>> ```
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks in advance,
>>>>>>>>> Tigran.
> >>> <SubjectBenchmark.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: optimize-subject.patch
Type: text/x-patch
Size: 1566 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200424/6b56be3c/optimize-subject.patch>

From xuelei.fan at oracle.com  Fri Apr 24 18:43:42 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 24 Apr 2020 11:43:42 -0700
Subject: RFR JDK-8236464 : SO_LINGER option is ignored by SSLSocket in JDK
 11
In-Reply-To: <7cb31094-61e9-eb05-9cfa-d1339b4802cb@oracle.com>
References: <9bf9c238-a473-0084-baee-d572cf172830@oracle.com>
 <7cb31094-61e9-eb05-9cfa-d1339b4802cb@oracle.com>
Message-ID: <69b3e3ee-feb4-1a97-21a5-d1328f6a969f@oracle.com>

Hi Tony,

Thanks for the review.  I will update the typo before commit.

Xuelei

On 4/24/2020 10:08 AM, Anthony Scarpino wrote:
> On 4/23/20 1:14 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the following update reviewed?
>>
>> http://cr.openjdk.java.net/~xuelei/8236464/webrev.00/
>>
>> In the current implementation, the sending of close_notify may not 
>> respect the SO_LINGER setting in some circumstances.?? With this 
>> update, the delivering of close_notify alert will consider the impact 
>> of the SO_LINGER setting.
>>
>> I can confirm there is an issue per the code, but I cannot reproduce 
>> the issue by myself.? I'm asking for an external help for the testing. 
>> "noreg-hard" and "noreg-external" tags were added to this bug.
>>
>> Thanks,
>>
>> Xuelei
>>
> Looks good..? with one minor typo:
> TransportContext.java
> 259? // Socket transport is a special because of the SO_LINGER impact.
> 
> remove the 'a'
> 
> No need for re-review
> 
> Tony


From weijun.wang at oracle.com  Sat Apr 25 00:59:51 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 25 Apr 2020 08:59:51 +0800
Subject: RFR 15: 8243010: Test support: Customizable Hex Printer (and
 security test updates)
In-Reply-To: <34235666-f73e-e624-3987-2c054984cf5d@oracle.com>
References: <9c191999-b265-68a5-2188-ee2b9168dd17@oracle.com>
 <e39872c0-963c-f651-293d-bcb0af0eeb5c@oracle.com>
 <4c1caa7c-7569-fdc2-d525-7824929b95ad@oracle.com>
 <34235666-f73e-e624-3987-2c054984cf5d@oracle.com>
Message-ID: <31D34FAC-1739-4F95-B179-7175014298EC@oracle.com>

Everything in the security tests looks fine to me.

Thanks,
Max

> On Apr 25, 2020, at 1:03 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> To correct an oversight to include security-dev in the reviews...
> Several security tests were modified to use the HexPrinter instead of HexDumpEncoder.
> 
> 
> Please review[2] and comment on a new Hex printing utility to support OpenJDK tests.
> The usefulness of a hex printing has been discussed from time to time with
> many suggestions as to the API shape and features.
> 
> To get an idea of the API and features, take a look at the javadoc[1].
> It covers the basic formatting of offset, and values, and extends the
> descriptive part beyond simple ASCII or printable so that a custom formatter
> can interpret the byte stream in parallel to the bytes.
> 
> The webrev includes changes to existing tests that currently
> use HexDumpEncoder to use HexPrinter.
> 
> Comments appreciated, Roger
> 
> [1]Javadoc:
> http://cr.openjdk.java.net/~rriggs/webrev-hexprinter-8243010/javadoc
> 
> [2] Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-hexprinter-8243010/
> 
> [3] Issue:
> https://bugs.openjdk.java.net/browse/JDK-8243010



From weijun.wang at oracle.com  Sat Apr 25 07:39:19 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 25 Apr 2020 15:39:19 +0800
Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
Message-ID: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>

Please take a review at

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

This is helpful if we do any set arithmetic between 2 Subject objects.

No new regression test, I intend to add a noreg-trivial label.

*Tigran*: Please confirm you are OK with the "Contributed-by" line.

Thanks,
Max



From tigran.mkrtchyan at desy.de  Sat Apr 25 08:37:28 2020
From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran)
Date: Sat, 25 Apr 2020 10:37:28 +0200 (CEST)
Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
In-Reply-To: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
Message-ID: <-cqrbor-fchj855hucgv-7ecygoohql8l-ozlddy-gppufm86dj7wcxa35izbopvn-az0qlz-l753n2-coa32h-mc6g6p-3ihdvj53ly38-4jb3zcoa9127-m99zfh-zfviyy-vak9wp-au2oitd2j6gt-nvut42.1587803851954@email.android.com>

Looks good to me.
 Thanks,
 Tigran

 -------- Original message --------
 From: Weijun Wang <weijun.wang at oracle.com>
 Date: Sat, Apr 25, 2020, 09:40
 To: security-dev at openjdk.java.net
 Cc: "Mkrtchyan, Tigran" <tigran.mkrtchyan at desy.de>
 Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
Please take a review at

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

This is helpful if we do any set arithmetic between 2 Subject objects.

No new regression test, I intend to add a noreg-trivial label.

*Tigran*: Please confirm you are OK with the "Contributed-by" line.

Thanks,
Max

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

From weijun.wang at oracle.com  Sat Apr 25 10:28:54 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 25 Apr 2020 18:28:54 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
Message-ID: <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>

OidString.java
==============

1. ExtendedKeyUsage names: used to be "serverAuth", now "ServerAuth". First letter capitalized, is this necessary?

2. Can we move name2oidStr() from OidString to AlgorithmId? The computeOidTable process looks like an alien.

3. Two questions on the following lines:

 415         // set extra alias mappings or specify the preferred one when
 416         // one standard name maps to multiple enums
 417         // NOTE: key must use UPPER CASE
 418         name2enum.put("SHA1", SHA_1);
 419         name2enum.put("SHA", SHA_1);
 420         name2enum.put("SHA224", SHA_224);
 421         name2enum.put("SHA256", SHA_256);
 422         name2enum.put("SHA384", SHA_384);
 423         name2enum.put("SHA512", SHA_512);
 424         name2enum.put("SHA512/224", SHA_512$224);
 425         name2enum.put("SHA512/256", SHA_512$256);
 426         name2enum.put("DH", DiffieHellman);
 427         name2enum.put("DSS", SHA1withDSA);
 428         name2enum.put("RSA", RSA);

   a) For line 428, is this because both RSA and ITUX509_RSA have the same stdName and you are setting the preferred one? However, I can see that "DiffieHellman", "DSA", and "SHA1withDSA" also appear in multiple places. Do they need special attention?

   b) For the other lines, can we make this info somewhere inside the constructor? After all our goal is to consolidate all info in one single place, and a single line is better than a single file, esp, a very big file.

4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?

5. I found KnownOIDs to be a better class name.

AlgorithmId.java
================

There are still many lines like

    public static final ObjectIdentifier MD2_oid = algOID(OidString.MD2);

here. Can they be eliminated? I use IntelliJ IDEA to find their usages and most are used in only one place and some are not used at all.


I haven't read other files yet. Will send more comment later.

Thanks,
Max


> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Hi Max,
> 
> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
> 
> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
> 
> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
> 
> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
> 
> Mach5 runs clean.
> 
> Valerie
> 



From weijun.wang at oracle.com  Sat Apr 25 14:46:08 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 25 Apr 2020 22:46:08 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
Message-ID: <CD284E5D-AE77-4757-AB7D-84467BCD5114@oracle.com>

And I am confused by aliases in SecurityProviderConstants, together with the duplicated stdName in OidString, it seems to show that one OID could have multiple names, and one name could have multiple OIDs. Can we consolidate aliases inside OidString also?

Also, looking at the store() calls in SecurityProviderConstants, it looks like a stdName itself is one of its aliases. Is this really useful? From what I read in the provider classes, you are adding ServiceKeys based on these aliases to a serviceMap which already has a ServiceKey based on stdName.

Thanks,
Max

> On Apr 25, 2020, at 6:28 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> OidString.java
> ==============
> 
> 1. ExtendedKeyUsage names: used to be "serverAuth", now "ServerAuth". First letter capitalized, is this necessary?
> 
> 2. Can we move name2oidStr() from OidString to AlgorithmId? The computeOidTable process looks like an alien.
> 
> 3. Two questions on the following lines:
> 
> 415         // set extra alias mappings or specify the preferred one when
> 416         // one standard name maps to multiple enums
> 417         // NOTE: key must use UPPER CASE
> 418         name2enum.put("SHA1", SHA_1);
> 419         name2enum.put("SHA", SHA_1);
> 420         name2enum.put("SHA224", SHA_224);
> 421         name2enum.put("SHA256", SHA_256);
> 422         name2enum.put("SHA384", SHA_384);
> 423         name2enum.put("SHA512", SHA_512);
> 424         name2enum.put("SHA512/224", SHA_512$224);
> 425         name2enum.put("SHA512/256", SHA_512$256);
> 426         name2enum.put("DH", DiffieHellman);
> 427         name2enum.put("DSS", SHA1withDSA);
> 428         name2enum.put("RSA", RSA);
> 
>   a) For line 428, is this because both RSA and ITUX509_RSA have the same stdName and you are setting the preferred one? However, I can see that "DiffieHellman", "DSA", and "SHA1withDSA" also appear in multiple places. Do they need special attention?
> 
>   b) For the other lines, can we make this info somewhere inside the constructor? After all our goal is to consolidate all info in one single place, and a single line is better than a single file, esp, a very big file.
> 
> 4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?
> 
> 5. I found KnownOIDs to be a better class name.
> 
> AlgorithmId.java
> ================
> 
> There are still many lines like
> 
>    public static final ObjectIdentifier MD2_oid = algOID(OidString.MD2);
> 
> here. Can they be eliminated? I use IntelliJ IDEA to find their usages and most are used in only one place and some are not used at all.
> 
> 
> I haven't read other files yet. Will send more comment later.
> 
> Thanks,
> Max
> 
> 
>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>> 
>> Hi Max,
>> 
>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>> 
>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>> 
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>> 
>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>> 
>> Mach5 runs clean.
>> 
>> Valerie
>> 
> 



From weijun.wang at oracle.com  Sun Apr 26 11:34:40 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sun, 26 Apr 2020 19:34:40 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
Message-ID: <A0F3F09B-B77C-4905-B746-4E96126852D8@oracle.com>

I see this change in Provider$Service::toString output of SHA1withRSA:

 SunRsaSign: Signature.SHA1withRSA -> sun.security.rsa.RSASignature$SHA1withRSA
-  aliases: [1.2.840.113549.1.1.5, 1.3.14.3.2.29, OID.1.2.840.113549.1.1.5]
+  aliases: [1.2.840.113549.1.1.5, OID.1.2.840.113549.1.1.5]
   attributes: {SupportedKeyClasses=java.security.interfaces.RSAPublicKey|java.security.interfaces.RSAPrivateKey}

Why is OIW_SHA1withRSA left out now? Maybe you should have added it to SecurityProviderConstants?

Thanks,
Max


> On Apr 25, 2020, at 6:28 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> 4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?



From sean.mullan at oracle.com  Mon Apr 27 14:27:16 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 27 Apr 2020 10:27:16 -0400
Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
In-Reply-To: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
Message-ID: <d814219e-3337-e1f8-4ad7-0dde2534060e@oracle.com>

The fix looks fine to me. For consistency, you could make the same 
change for null elements in the other SecureSet methods: add, remove.

--Sean

On 4/25/20 3:39 AM, Weijun Wang wrote:
> Please take a review at
> 
>     http://cr.openjdk.java.net/~weijun/8243592/webrev.00/
> 
> This is helpful if we do any set arithmetic between 2 Subject objects.
> 
> No new regression test, I intend to add a noreg-trivial label.
> 
> *Tigran*: Please confirm you are OK with the "Contributed-by" line.
> 
> Thanks,
> Max
> 


From valerie.peng at oracle.com  Mon Apr 27 22:19:29 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 27 Apr 2020 15:19:29 -0700
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
Message-ID: <23326b44-baa7-19d3-f67c-7161656d7e0e@oracle.com>

Hi Max,

Thanks for reviewing this~ Please find my replies inline.

On 4/25/2020 3:28 AM, Weijun Wang wrote:
> OidString.java
> ==============
>
> 1. ExtendedKeyUsage names: used to be "serverAuth", now "ServerAuth". First letter capitalized, is this necessary?

Yes, I made a change here. Using "ServerAuth" seems more consistent with 
the rest of constants in OidString. So I made a change here. It affects 
the displayed out but no regression tests are affected by this change. 
Well, if we want to be 100% same as before, I can change these to start 
with lower case, but then we probably need comments so it's clear that 
these are intentional changes.

> 2. Can we move name2oidStr() from OidString to AlgorithmId? The computeOidTable process looks like an alien.

Well, I think it's better to consolidate all oid string/algorithm names 
to as few places as possible.

AlgorithmId class used to contain a lot of such conversions and now that 
there is OidString class (we can discuss a better name for it), it 
should be updated to use OidString and just be a general impl class for 
handling ASN AlgorithmId structure. Let me try putting this utility 
method name2oidStr() elsewhere and see.

> 3. Two questions on the following lines:
>
>   415         // set extra alias mappings or specify the preferred one when
>   416         // one standard name maps to multiple enums
>   417         // NOTE: key must use UPPER CASE
>   418         name2enum.put("SHA1", SHA_1);
>   419         name2enum.put("SHA", SHA_1);
>   420         name2enum.put("SHA224", SHA_224);
>   421         name2enum.put("SHA256", SHA_256);
>   422         name2enum.put("SHA384", SHA_384);
>   423         name2enum.put("SHA512", SHA_512);
>   424         name2enum.put("SHA512/224", SHA_512$224);
>   425         name2enum.put("SHA512/256", SHA_512$256);
>   426         name2enum.put("DH", DiffieHellman);
>   427         name2enum.put("DSS", SHA1withDSA);
>   428         name2enum.put("RSA", RSA);
>
>     a) For line 428, is this because both RSA and ITUX509_RSA have the same stdName and you are setting the preferred one? However, I can see that "DiffieHellman", "DSA", and "SHA1withDSA" also appear in multiple places. Do they need special attention?

Yes, initially I was relying on the ordering of enums to handle the 
1-to-N mapping. Later, I changed to explicitly define the mapping as in 
the webrev as this should be more robust. I should have added other 
algorithms here too. Will update.

>     b) For the other lines, can we make this info somewhere inside the constructor? After all our goal is to consolidate all info in one single place, and a single line is better than a single file, esp, a very big file.
For other lines => are you referring to the extra aliases? Instead of 
specifying the aliases for each enum explicitly as in current webrev, 
store them into the constructor and save them into the name2enum map 
while looping through the enum values? The current approach has the 
benefit of being straightforward and no need to worry about duplicate 
aliases.
> 4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?
OID is tied to an algorithm name. Thus, it should be universal to all 
JDK providers as long as the algorithm impl is interoperable. In the 
past, it's very easy to miss adding the OIDs as they are hardcoded in 
different places. For providers who are lower in the provider list, 
registering the OIDs may not be that important if a more preferred 
provider already supports the same impl. Rather than registering 
identical entries, with this change, the OID support should be 
consistent across providers.
> 5. I found KnownOIDs to be a better class name.
Sure, fine with me.
>
> AlgorithmId.java
> ================
>
> There are still many lines like
>
>      public static final ObjectIdentifier MD2_oid = algOID(OidString.MD2);
>
> here. Can they be eliminated? I use IntelliJ IDEA to find their usages and most are used in only one place and some are not used at all.

Yes, I debated about it. It's tricky to draw the line. My current 
thought is to keep these "public static" constants intact if they are 
directly referenced somewhere. There are also many places where I think 
further trimming/cleanup can be made. But as it is, it is already 
extensive. Maybe it's safer to be conservative and gradually clean up...

> I haven't read other files yet. Will send more comment later.

Sure, these two are the key files.

I will experiment on the utility method and we can discuss it further.

Thanks,
Valerie
>
> Thanks,
> Max
>
>
>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Hi Max,
>>
>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>
>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>
>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>
>> Mach5 runs clean.
>>
>> Valerie
>>


From valerie.peng at oracle.com  Tue Apr 28 00:08:07 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 27 Apr 2020 17:08:07 -0700
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <CD284E5D-AE77-4757-AB7D-84467BCD5114@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
 <CD284E5D-AE77-4757-AB7D-84467BCD5114@oracle.com>
Message-ID: <cd968cc6-3b86-cf1b-9618-12137861c9a3@oracle.com>

Yes, it can be quite a confusing scenario. Some algorithms have multiple 
oids (say X) and multiple algorithm names (say Y). We need to be able to 
handle all of them (X+Y). However, the separation of alias definition 
for OidString and SecurityProviderConstants are intentional and I have 
them separated with the reason below:

The aliases in OidString can be viewed as internal, e.g. from JCA 
classes and used by AlgorithmId class and its regression tests. All of 
the supported oids (X of them) have to have an OidString enum type as 
their usage may be present in the DER encoding and all internal classes 
need to handle it. As for the multiple algorithm names, supposedly, 
there is only one standard name and the rest are all aliases. Aliases 
can be used to request the impl from provider, but that's all. Internal 
classes do not need to understand these external/provider-related 
aliases. By separating these external aliases inside 
SecurityProviderConstants, it is clear that these aliases are for 
providers only.

StdName itself should not be its aliases. Which line in 
SecurityProviderConstants class has this problem?

Thanks,

Valerie

On 4/25/2020 7:46 AM, Weijun Wang wrote:
> And I am confused by aliases in SecurityProviderConstants, together with the duplicated stdName in OidString, it seems to show that one OID could have multiple names, and one name could have multiple OIDs. Can we consolidate aliases inside OidString also?
>
> Also, looking at the store() calls in SecurityProviderConstants, it looks like a stdName itself is one of its aliases. Is this really useful? From what I read in the provider classes, you are adding ServiceKeys based on these aliases to a serviceMap which already has a ServiceKey based on stdName.
>
> Thanks,
> Max
>
>> On Apr 25, 2020, at 6:28 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> OidString.java
>> ==============
>>
>> 1. ExtendedKeyUsage names: used to be "serverAuth", now "ServerAuth". First letter capitalized, is this necessary?
>>
>> 2. Can we move name2oidStr() from OidString to AlgorithmId? The computeOidTable process looks like an alien.
>>
>> 3. Two questions on the following lines:
>>
>> 415         // set extra alias mappings or specify the preferred one when
>> 416         // one standard name maps to multiple enums
>> 417         // NOTE: key must use UPPER CASE
>> 418         name2enum.put("SHA1", SHA_1);
>> 419         name2enum.put("SHA", SHA_1);
>> 420         name2enum.put("SHA224", SHA_224);
>> 421         name2enum.put("SHA256", SHA_256);
>> 422         name2enum.put("SHA384", SHA_384);
>> 423         name2enum.put("SHA512", SHA_512);
>> 424         name2enum.put("SHA512/224", SHA_512$224);
>> 425         name2enum.put("SHA512/256", SHA_512$256);
>> 426         name2enum.put("DH", DiffieHellman);
>> 427         name2enum.put("DSS", SHA1withDSA);
>> 428         name2enum.put("RSA", RSA);
>>
>>    a) For line 428, is this because both RSA and ITUX509_RSA have the same stdName and you are setting the preferred one? However, I can see that "DiffieHellman", "DSA", and "SHA1withDSA" also appear in multiple places. Do they need special attention?
>>
>>    b) For the other lines, can we make this info somewhere inside the constructor? After all our goal is to consolidate all info in one single place, and a single line is better than a single file, esp, a very big file.
>>
>> 4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?
>>
>> 5. I found KnownOIDs to be a better class name.
>>
>> AlgorithmId.java
>> ================
>>
>> There are still many lines like
>>
>>     public static final ObjectIdentifier MD2_oid = algOID(OidString.MD2);
>>
>> here. Can they be eliminated? I use IntelliJ IDEA to find their usages and most are used in only one place and some are not used at all.
>>
>>
>> I haven't read other files yet. Will send more comment later.
>>
>> Thanks,
>> Max
>>
>>
>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>
>>> Hi Max,
>>>
>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>>
>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>>
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>>
>>> Mach5 runs clean.
>>>
>>> Valerie
>>>


From weijun.wang at oracle.com  Tue Apr 28 01:37:26 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 28 Apr 2020 09:37:26 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <cd968cc6-3b86-cf1b-9618-12137861c9a3@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
 <CD284E5D-AE77-4757-AB7D-84467BCD5114@oracle.com>
 <cd968cc6-3b86-cf1b-9618-12137861c9a3@oracle.com>
Message-ID: <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com>


> On Apr 28, 2020, at 8:08 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Yes, it can be quite a confusing scenario. Some algorithms have multiple oids (say X) and multiple algorithm names (say Y). We need to be able to handle all of them (X+Y). However, the separation of alias definition for OidString and SecurityProviderConstants are intentional and I have them separated with the reason below:
> 
> The aliases in OidString can be viewed as internal, e.g. from JCA classes and used by AlgorithmId class and its regression tests. All of the supported oids (X of them) have to have an OidString enum type as their usage may be present in the DER encoding and all internal classes need to handle it. As for the multiple algorithm names, supposedly, there is only one standard name and the rest are all aliases. Aliases can be used to request the impl from provider, but that's all. Internal classes do not need to understand these external/provider-related aliases. By separating these external aliases inside SecurityProviderConstants, it is clear that these aliases are for providers only.

I understand.

In SecurityProviderConstants::getAliases, is it possible to combine aliases.get(o) and OidString.findMatch(o)? Or we can rewrite store() and grab info from OidString so that there is no need to always add OID.oid and oid in the store() calls.

Inside getAliases(), why must there be an exception when there is no OidString.findMatch(o)? Does every algorithm name need an OID? I thought of X.509 but you have added it into aliases.

> 
> StdName itself should not be its aliases. Which line in SecurityProviderConstants class has this problem?

Sorry, I got it wrong. I've mistakenly thought that OidString.DSA.value() is the name.

Thanks,
Max

> 
> Thanks,
> 
> Valerie
> 
> On 4/25/2020 7:46 AM, Weijun Wang wrote:
>> And I am confused by aliases in SecurityProviderConstants, together with the duplicated stdName in OidString, it seems to show that one OID could have multiple names, and one name could have multiple OIDs. Can we consolidate aliases inside OidString also?
>> 
>> Also, looking at the store() calls in SecurityProviderConstants, it looks like a stdName itself is one of its aliases. Is this really useful? From what I read in the provider classes, you are adding ServiceKeys based on these aliases to a serviceMap which already has a ServiceKey based on stdName.
>> 
>> Thanks,
>> Max
>> 
>>> On Apr 25, 2020, at 6:28 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> OidString.java
>>> ==============
>>> 
>>> 1. ExtendedKeyUsage names: used to be "serverAuth", now "ServerAuth". First letter capitalized, is this necessary?
>>> 
>>> 2. Can we move name2oidStr() from OidString to AlgorithmId? The computeOidTable process looks like an alien.
>>> 
>>> 3. Two questions on the following lines:
>>> 
>>> 415         // set extra alias mappings or specify the preferred one when
>>> 416         // one standard name maps to multiple enums
>>> 417         // NOTE: key must use UPPER CASE
>>> 418         name2enum.put("SHA1", SHA_1);
>>> 419         name2enum.put("SHA", SHA_1);
>>> 420         name2enum.put("SHA224", SHA_224);
>>> 421         name2enum.put("SHA256", SHA_256);
>>> 422         name2enum.put("SHA384", SHA_384);
>>> 423         name2enum.put("SHA512", SHA_512);
>>> 424         name2enum.put("SHA512/224", SHA_512$224);
>>> 425         name2enum.put("SHA512/256", SHA_512$256);
>>> 426         name2enum.put("DH", DiffieHellman);
>>> 427         name2enum.put("DSS", SHA1withDSA);
>>> 428         name2enum.put("RSA", RSA);
>>> 
>>>   a) For line 428, is this because both RSA and ITUX509_RSA have the same stdName and you are setting the preferred one? However, I can see that "DiffieHellman", "DSA", and "SHA1withDSA" also appear in multiple places. Do they need special attention?
>>> 
>>>   b) For the other lines, can we make this info somewhere inside the constructor? After all our goal is to consolidate all info in one single place, and a single line is better than a single file, esp, a very big file.
>>> 
>>> 4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?
>>> 
>>> 5. I found KnownOIDs to be a better class name.
>>> 
>>> AlgorithmId.java
>>> ================
>>> 
>>> There are still many lines like
>>> 
>>>    public static final ObjectIdentifier MD2_oid = algOID(OidString.MD2);
>>> 
>>> here. Can they be eliminated? I use IntelliJ IDEA to find their usages and most are used in only one place and some are not used at all.
>>> 
>>> 
>>> I haven't read other files yet. Will send more comment later.
>>> 
>>> Thanks,
>>> Max
>>> 
>>> 
>>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>> 
>>>> Hi Max,
>>>> 
>>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>>> 
>>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>>> 
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>>> 
>>>> Mach5 runs clean.
>>>> 
>>>> Valerie
>>>> 



From weijun.wang at oracle.com  Tue Apr 28 02:15:55 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 28 Apr 2020 10:15:55 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <23326b44-baa7-19d3-f67c-7161656d7e0e@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
 <23326b44-baa7-19d3-f67c-7161656d7e0e@oracle.com>
Message-ID: <9227B6A8-DBCF-4217-9E12-995B70630643@oracle.com>



> On Apr 28, 2020, at 6:19 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Hi Max,
> 
> Thanks for reviewing this~ Please find my replies inline.
> 
> On 4/25/2020 3:28 AM, Weijun Wang wrote:
>> OidString.java
>> ==============
>> 
>> 1. ExtendedKeyUsage names: used to be "serverAuth", now "ServerAuth". First letter capitalized, is this necessary?
> 
> Yes, I made a change here. Using "ServerAuth" seems more consistent with the rest of constants in OidString. So I made a change here. It affects the displayed out but no regression tests are affected by this change. Well, if we want to be 100% same as before, I can change these to start with lower case, but then we probably need comments so it's clear that these are intentional changes.

I'd rather use the old name.

> 
>> 2. Can we move name2oidStr() from OidString to AlgorithmId? The computeOidTable process looks like an alien.
> 
> Well, I think it's better to consolidate all oid string/algorithm names to as few places as possible.
> 
> AlgorithmId class used to contain a lot of such conversions and now that there is OidString class (we can discuss a better name for it), it should be updated to use OidString and just be a general impl class for handling ASN AlgorithmId structure. Let me try putting this utility method name2oidStr() elsewhere and see.

computeOidTable() is only called by name2oid() only called by name2oidStr() only called by algOID() which is in AlgorithmId.

algOID() in AlgorithmId is called by AlgorithmId::get which makes it quite the core of that class.

> 
>> 3. Two questions on the following lines:
>> 
>>  415         // set extra alias mappings or specify the preferred one when
>>  416         // one standard name maps to multiple enums
>>  417         // NOTE: key must use UPPER CASE
>>  418         name2enum.put("SHA1", SHA_1);
>>  419         name2enum.put("SHA", SHA_1);
>>  420         name2enum.put("SHA224", SHA_224);
>>  421         name2enum.put("SHA256", SHA_256);
>>  422         name2enum.put("SHA384", SHA_384);
>>  423         name2enum.put("SHA512", SHA_512);
>>  424         name2enum.put("SHA512/224", SHA_512$224);
>>  425         name2enum.put("SHA512/256", SHA_512$256);
>>  426         name2enum.put("DH", DiffieHellman);
>>  427         name2enum.put("DSS", SHA1withDSA);
>>  428         name2enum.put("RSA", RSA);
>> 
>>    a) For line 428, is this because both RSA and ITUX509_RSA have the same stdName and you are setting the preferred one? However, I can see that "DiffieHellman", "DSA", and "SHA1withDSA" also appear in multiple places. Do they need special attention?
> 
> Yes, initially I was relying on the ordering of enums to handle the 1-to-N mapping. Later, I changed to explicitly define the mapping as in the webrev as this should be more robust. I should have added other algorithms here too. Will update.

I caught them by looking at the "skipped" debug output. Can we add some logic to detect this? For example, for those nonpreferred OIDs, use a special constructor?

> 
>>    b) For the other lines, can we make this info somewhere inside the constructor? After all our goal is to consolidate all info in one single place, and a single line is better than a single file, esp, a very big file.
> For other lines => are you referring to the extra aliases?

Oh, I meant lines 415 - 428.

> Instead of specifying the aliases for each enum explicitly as in current webrev, store them into the constructor and save them into the name2enum map while looping through the enum values? The current approach has the benefit of being straightforward and no need to worry about duplicate aliases.

We can also populate the name2enum map inside the constructor, there is no need to store the aliases in each enum.

>> 4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?
> OID is tied to an algorithm name. Thus, it should be universal to all JDK providers as long as the algorithm impl is interoperable. In the past, it's very easy to miss adding the OIDs as they are hardcoded in different places. For providers who are lower in the provider list, registering the OIDs may not be that important if a more preferred provider already supports the same impl. Rather than registering identical entries, with this change, the OID support should be consistent across providers.

Good to know.

>> 5. I found KnownOIDs to be a better class name.
> Sure, fine with me.
>> 
>> AlgorithmId.java
>> ================
>> 
>> There are still many lines like
>> 
>>     public static final ObjectIdentifier MD2_oid = algOID(OidString.MD2);
>> 
>> here. Can they be eliminated? I use IntelliJ IDEA to find their usages and most are used in only one place and some are not used at all.
> 
> Yes, I debated about it. It's tricky to draw the line. My current thought is to keep these "public static" constants intact if they are directly referenced somewhere. There are also many places where I think further trimming/cleanup can be made. But as it is, it is already extensive. Maybe it's safer to be conservative and gradually clean up...

Fair enough.

If we want to eliminate the use of these objects later, is there a way to not create a new ObjectIdentifier object each time? I think I've read some C projects that defines OID as the DER encoding but not as strings. String is only best for log usages. But this is a much broader topic.

> 
>> I haven't read other files yet. Will send more comment later.
> 
> Sure, these two are the key files.
> 
> I will experiment on the utility method and we can discuss it further.

Thanks,
Max

> 
> Thanks,
> Valerie
>> 
>> Thanks,
>> Max
>> 
>> 
>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>> 
>>> Hi Max,
>>> 
>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>> 
>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>> 
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>> 
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>> 
>>> Mach5 runs clean.
>>> 
>>> Valerie
>>> 



From weijun.wang at oracle.com  Tue Apr 28 02:39:09 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 28 Apr 2020 10:39:09 +0800
Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
In-Reply-To: <d814219e-3337-e1f8-4ad7-0dde2534060e@oracle.com>
References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
 <d814219e-3337-e1f8-4ad7-0dde2534060e@oracle.com>
Message-ID: <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com>

Reading the Set spec, it looks like an NPE is still needed for add(), but remove() can be modified.

--Max

> On Apr 27, 2020, at 10:27 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> The fix looks fine to me. For consistency, you could make the same change for null elements in the other SecureSet methods: add, remove.
> 
> --Sean
> 
> On 4/25/20 3:39 AM, Weijun Wang wrote:
>> Please take a review at
>>    http://cr.openjdk.java.net/~weijun/8243592/webrev.00/
>> This is helpful if we do any set arithmetic between 2 Subject objects.
>> No new regression test, I intend to add a noreg-trivial label.
>> *Tigran*: Please confirm you are OK with the "Contributed-by" line.
>> Thanks,
>> Max



From sibabrata.sahoo at oracle.com  Tue Apr 28 07:38:53 2020
From: sibabrata.sahoo at oracle.com (sibabrata.sahoo at oracle.com)
Date: Tue, 28 Apr 2020 13:08:53 +0530
Subject: [15] RFR: 8242335: Additional Tests for RSASSA-PSS
Message-ID: <DAE3FB0F-1356-4A2A-8B5F-56E5E8942BB7@oracle.com>

Hi Valerie,

Please review the patch for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8242335 <https://bugs.openjdk.java.net/browse/JDK-8242335>
Webrev: http://cr.openjdk.java.net/~ssahoo/8242335/webrev.00/ <http://cr.openjdk.java.net/~ssahoo/8242335/webrev.00/>

These are additional Tests developed to support RSASSA-PSS algorithm. One is key compatibility with OpenSSL generated while the other one is the API Tests for serialized keys.

Thanks,
Siba



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

From weijun.wang at oracle.com  Tue Apr 28 08:53:54 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 28 Apr 2020 16:53:54 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
Message-ID: <BE30CAB9-9D62-450C-851A-0AECCC98342C@oracle.com>

Where is the following OID used

      RSAEncryption("1.2.840.113549.1.1.1", "RSA"), // in RSA Cipher

I only found in RSAUtil.java:

                case RSA:
                    oid = AlgorithmId.RSAEncryption_oid;
                    break;

What if we do not give it a different stdName? Or, should we make it an alias in SunJCE for Cipher.RSA?

--Max


> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Hi Max,
> 
> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
> 
> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
> 
> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
> 
> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
> 
> Mach5 runs clean.
> 
> Valerie
> 



From weijun.wang at oracle.com  Tue Apr 28 09:39:11 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 28 Apr 2020 17:39:11 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <BE30CAB9-9D62-450C-851A-0AECCC98342C@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <BE30CAB9-9D62-450C-851A-0AECCC98342C@oracle.com>
Message-ID: <F8F245F6-DFA4-4BEC-903E-1E6B9F30323E@oracle.com>

I found two algorithm names in a very twisted relation, in SecurityProviderConstants.java:

        store("ARCFOUR", "RC4");

and in OidString.java:

    RC4("1.2.840.113549.3.4", "ARCFOUR")

So each is the other's alias, and because of this, Cipher.ARCFOUR does not have OID aliases.

I can see in https://download.java.net/java/early_access/jdk15/docs/specs/security/standard-names.html that both ARCFOUR and RC4 are standard names. In my understanding, this means both must be supported and it looks like some kind of "required" alias. Is this the reason we have to define them in this way?

Thanks,
Max


> On Apr 28, 2020, at 4:53 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Where is the following OID used
> 
>      RSAEncryption("1.2.840.113549.1.1.1", "RSA"), // in RSA Cipher
> 
> I only found in RSAUtil.java:
> 
>                case RSA:
>                    oid = AlgorithmId.RSAEncryption_oid;
>                    break;
> 
> What if we do not give it a different stdName? Or, should we make it an alias in SunJCE for Cipher.RSA?
> 
> --Max
> 
> 
>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>> 
>> Hi Max,
>> 
>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>> 
>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>> 
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>> 
>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>> 
>> Mach5 runs clean.
>> 
>> Valerie
>> 
> 



From weijun.wang at oracle.com  Tue Apr 28 10:37:07 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 28 Apr 2020 18:37:07 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
Message-ID: <A1CC1EE2-B11D-4490-AAC6-9FA75225793E@oracle.com>

Is OidString::toString really used anywhere? If so, I suggest we create a special method for it so it's easy to use an IDE to find out all usages. Finding toString returns usages of Object::toString and it's everywhere.

--Max

> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Hi Max,
> 
> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
> 
> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
> 
> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
> 
> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
> 
> Mach5 runs clean.
> 
> Valerie
> 



From sean.mullan at oracle.com  Tue Apr 28 12:16:59 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 28 Apr 2020 08:16:59 -0400
Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
In-Reply-To: <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com>
References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
 <d814219e-3337-e1f8-4ad7-0dde2534060e@oracle.com>
 <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com>
Message-ID: <1dfd1e84-d1ea-6162-970e-f061373e8fa7@oracle.com>

On 4/27/20 10:39 PM, Weijun Wang wrote:
> Reading the Set spec, it looks like an NPE is still needed for add(), but remove() can be modified.

Good point, I agree.

--Sean

> 
> --Max
> 
>> On Apr 27, 2020, at 10:27 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> The fix looks fine to me. For consistency, you could make the same change for null elements in the other SecureSet methods: add, remove.
>>
>> --Sean
>>
>> On 4/25/20 3:39 AM, Weijun Wang wrote:
>>> Please take a review at
>>>     http://cr.openjdk.java.net/~weijun/8243592/webrev.00/
>>> This is helpful if we do any set arithmetic between 2 Subject objects.
>>> No new regression test, I intend to add a noreg-trivial label.
>>> *Tigran*: Please confirm you are OK with the "Contributed-by" line.
>>> Thanks,
>>> Max
> 


From weijun.wang at oracle.com  Tue Apr 28 13:58:19 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 28 Apr 2020 21:58:19 +0800
Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
In-Reply-To: <1dfd1e84-d1ea-6162-970e-f061373e8fa7@oracle.com>
References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
 <d814219e-3337-e1f8-4ad7-0dde2534060e@oracle.com>
 <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com>
 <1dfd1e84-d1ea-6162-970e-f061373e8fa7@oracle.com>
Message-ID: <FFB9D940-2F66-4024-879E-E5AF78BDEC62@oracle.com>

A new webrev is at

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

I take this chance to do some formatting and add a new test. My first testng test!

Thanks,
Max

> On Apr 28, 2020, at 8:16 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 4/27/20 10:39 PM, Weijun Wang wrote:
>> Reading the Set spec, it looks like an NPE is still needed for add(), but remove() can be modified.
> 
> Good point, I agree.
> 
> --Sean
> 
>> --Max
>>> On Apr 27, 2020, at 10:27 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> The fix looks fine to me. For consistency, you could make the same change for null elements in the other SecureSet methods: add, remove.
>>> 
>>> --Sean
>>> 
>>> On 4/25/20 3:39 AM, Weijun Wang wrote:
>>>> Please take a review at
>>>>    http://cr.openjdk.java.net/~weijun/8243592/webrev.00/
>>>> This is helpful if we do any set arithmetic between 2 Subject objects.
>>>> No new regression test, I intend to add a noreg-trivial label.
>>>> *Tigran*: Please confirm you are OK with the "Contributed-by" line.
>>>> Thanks,
>>>> Max



From michael.osipov at siemens.com  Tue Apr 28 17:05:03 2020
From: michael.osipov at siemens.com (Osipov, Michael)
Date: Tue, 28 Apr 2020 19:05:03 +0200
Subject: Evaluation part 1 of JDK-6722928: Provide a default native
 GSS-API library on Windows
In-Reply-To: <736322E7-0DD3-4BCC-BE33-13AFDACA22DF@oracle.com>
References: <8e63c57f-68d0-0294-3741-784492b51de1@siemens.com>
 <736322E7-0DD3-4BCC-BE33-13AFDACA22DF@oracle.com>
Message-ID: <2a512ba7-0546-0fe5-e0b6-bee2c5f65973@siemens.com>

Hi Max,

for those sections I have dropped I consider them resovled or some 
action wil be taken from you with a followup webrev and a JBS issue.

A general note on trace output: I found it really helpful, don't remove it!

Am 2020-04-21 um 15:36 schrieb Weijun Wang:
> 
> 
>> On Apr 2, 2020, at 12:21 AM, Osipov, Michael <michael.osipov at siemens.com> wrote:
>>
>> Hi Max,
>>
>> at last I took some time to evaluate you SSPI bridge. This is part one. Interaction evaluation will follow in a second email.
>>
>> Assumptions:
>> * All methods, objects behave the same as with JGSS
>> * AcceptSecurityContext is not implemented so should everything associated with it fail (GSSException)
>> * Code analysis happens based on https://github.com/AdoptOpenJDK/openjdk-jdk13u/blob/master/src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp
>> and zulu13.29.9-ca-jdk13.0.2-win_x64
>>
>> Findings C:

>> * sspi.cpp#L67-L68: Feels a bit awkward to permit SSPI_BRIDGE_TRACE="". Why not have "if (trace && *trace)"?
> 
> I think it's harmless but if every C program has that style I can follow.

Yes, it is harmless, but somewhat counter intuitive from a client 
perspective.

>> * sspi.cpp#L233: The function name says "show_oid", but I see no OID printed. Simply symbolic names.
> 
> Yes, it should be more like "what is this OID?". I'll think of a better name.

Exactly!

>> * sspi.cpp#L290: Empty string check? like (realm && *realm)
> 
> But then it's still L"".

My bad, misunderstanding.

>> * sspi.cpp#L482-L483: This is highly questionable. While it is true for Windows, it does not stick to gss_compare_name behavior. Don't know what the correct approach would be here.
> 
> I'll be glad if it's always true for Windows. I found the name thing most complicated, and here it's still only simple name and not UPN...

I would really not use the Windows approach here since you use GSS-API. 
Moreover, this is suspicious too:
> one has no realm and
>     // one has realm but they have the same name

It would consider the following equal while they aren't:
default realm: AD001.EXAMPLE.COM
gss_name_compare("michael-o", "michael-o at AD002.EXAMPLE.COM") == 1

>> * sspi.cpp#L618: You are resetting cred_usage passed with the function. This looks like a bug to me.
> 
> It's more like I ignore it. Will double check.

You really should not ignore this. It should at least match JGSS.
Tighten to MIT Kerberos behavior: 
https://github.com/krb5/krb5/blob/6d4eb6eb473c93f0db05409195448364382760a9/src/lib/gssapi/mechglue/g_acquire_cred.c#L73-L78?

>>   Same as in GSS-API:
>> $ sudo python3
>>> Python 3.7.7 (default, Mar 19 2020, 21:26:00)
>>> [Clang 9.0.1 (git at github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b31 on freebsd12
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> import gssapi
>>>>>> cred = gssapi.Credentials(usage='nonsense')
>>>>>> cred.usage
>>> 'both'
>> This also may be a bug in py-gssapi/MIT Kerberos

Reported for py-gssapi: 
https://github.com/pythongssapi/python-gssapi/issues/202

>> * sspi.cpp#L149
>> ** Can you apply a better output like ISO 8601? In strftime(3) that would be "%FT%T, ..."
> 
> I'll check, but the current format is most readable for me.

Really? I though that ISO 8601 style is most pleasant in Asia. Besides 
that, since the time is far in the future, does it make sense at all to 
have show_time()? I consider expiry quite pointless with such high values.

>> * sspi.cpp#L841: man 3 gss_import_sec_context says: GSS_S_UNAVAILABLE
> 
> I'm using GSS_S_FAILURE everywhere. I know it's not precise.

Can you file this as an issue. For a novice user this makes it really 
really hard to tackle down issue especially behavior you have zero 
debugging with SSPI compared to KRB5_TRACE.

>> * sspi.cpp#L977-L979: Not helpful when the SEC_E_* not mapped to major/minor. This likely applies to most mapping functions.
> 
> ???

This is bascially the same as the one above. you map 'ss' simply to 
GSS_S_FAILURE. Little context here.

>> * sspi.cpp#L1046: Maybe like gss_export_sec_context?
> 
> Not sure what you want me to do.
> 
>> * sspi.cpp#L1169: Maybe like gss_export_sec_context?
> 
> ???
> 

My bad, I gave to little context. The manpage for 
gss_export_sec_context() allows to return GSS_S_UNAVAILABLE. I would 
expect this return value for both of them.

>> * sspi.cpp#L729-L748: Why do you do this? The documentation for parameter 1 says: If the process that requests the handle does not have access to the credentials, the function returns an error. I have verified this with py-win32: win32security.AcquireCredentialsHandle(). Infact, it accepts any principal and always returns the default one. I found these:
>> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
>> ** https://github.com/twosigma/gsskrb5/blob/master/krb5/krb5cred.c#L127-L132
>>>>>> cred, time = win32security.AcquireCredentialsHandle("Administrator at ORACLE.COM", "Kerberos", win32security.SECPKG_CRED_OUTBOUND, None, None)
>>>>>> cred.QueryCredentialsAttributes(1)
>>> 'osipovmi at AD001.SIEMENS.NET'
> 
> Is this the expected result?

Yes. You cannot acquire a cred handle for another identity unless you do 
protocol transition or pass the auth_identity struct which makes 
pszPrincipal obsolete anyway. See also here: 
https://github.com/requests/requests-kerberos/pull/75#issuecomment-223657799 
and 
https://groups.google.com/d/msg/microsoft.public.platformsdk.security/Xlo23EMiH9U/r1tNRXfv08QJ

The Kerberos SSP will ignore this value. You never have access to other 
TGTs, this is by design.

This maybe different for kernel space, but this is just a wild guess.

>> Findings Java:
>> * GssManager#createCredential() with ACCEPT_ONLY or INITIATE_AND_ACCEPT gives me weird credentials with partial null nembers. I'd expect an exception here.
> 
> Oops. Will look into. Maybe I should reject.

Definitvely.

>> * This is one fails, but shall work:
>>> GSSManager manager = GSSManager.getInstance();
>>> GSSName userName = manager.createName("osipovmi", GSSName.NT_USER_NAME);
>>> GSSCredential cred = manager.createCredential(userName, GSSCredential.DEFAULT_LIFETIME, krb5Oid, GSSCredential.INITIATE_ONLY);
>>> [SSPI:1627] >>>> Calling gss_create_empty_oid_set...
>>> [SSPI:1542] >>>> Calling gss_add_oid_set_member...
>>> [SSPI:612] >>>> Calling gss_acquire_cred...
>>> [SSPI:619] AcquireCredentialsHandle with 0 00000257FFB199B0
>>> [SSPI:262] gss_OID_set.count is 1
>>> [SSPI:237] Kerberos mech
>>> [SSPI:628] reqKerberos
>>> [SSPI:152] cred expiration: 09/13/30828  04:48 4294967295ld
>>> [SSPI:732] Acquiring cred with a name. Check if it's me.
>>> [SSPI:791] >>>> Calling gss_inquire_cred...
>>> [SSPI:811] Allocate new name at 00000257FFB2BC40
>>> [SSPI:428] >>>> Calling gss_compare_name...
>>> [SSPI:437] Comparing osipovmi at AD001.SIEMENS.NET and osipovmi
>>> [SSPI:325] >>>> Calling gss_release_name 00000257FFB17830...
>>> [SSPI:744] Comparing result: 0
>>> [SSPI:767] >>>> Calling gss_release_cred...
>>> [SSPI:1641] >>>> Calling gss_release_oid_set...
>>> Exception in thread "main" GSSException: Failure unspecified at GSS-API level
>>> 	at java.security.jgss/sun.security.jgss.wrapper.GSSLibStub.acquireCred(Native Method)
>>
>> The problem is that I provide a local name and expect the default realm to be used. It seems like #createCredential() does not take that into account. It also has no avail when the canonicalized form is used. See sspi.cpp#L729-L748.

Open one...

I will work somewhere next week on part 2 of the analysis.

Regards,

Michael


From sean.mullan at oracle.com  Tue Apr 28 18:57:25 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 28 Apr 2020 14:57:25 -0400
Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
In-Reply-To: <FFB9D940-2F66-4024-879E-E5AF78BDEC62@oracle.com>
References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
 <d814219e-3337-e1f8-4ad7-0dde2534060e@oracle.com>
 <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com>
 <1dfd1e84-d1ea-6162-970e-f061373e8fa7@oracle.com>
 <FFB9D940-2F66-4024-879E-E5AF78BDEC62@oracle.com>
Message-ID: <1cb283c7-2047-bbd1-05a2-c852b19f67f8@oracle.com>

I don't think containsAll and retainsAll need to call 
collectionNullClean either because SecureSet.contains(null) returns 
false now.

--Sean

On 4/28/20 9:58 AM, Weijun Wang wrote:
> A new webrev is at
> 
>     http://cr.openjdk.java.net/~weijun/8243592/webrev.01/
> 
> I take this chance to do some formatting and add a new test. My first testng test!
> 
> Thanks,
> Max
> 
>> On Apr 28, 2020, at 8:16 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>
>> On 4/27/20 10:39 PM, Weijun Wang wrote:
>>> Reading the Set spec, it looks like an NPE is still needed for add(), but remove() can be modified.
>>
>> Good point, I agree.
>>
>> --Sean
>>
>>> --Max
>>>> On Apr 27, 2020, at 10:27 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>>
>>>> The fix looks fine to me. For consistency, you could make the same change for null elements in the other SecureSet methods: add, remove.
>>>>
>>>> --Sean
>>>>
>>>> On 4/25/20 3:39 AM, Weijun Wang wrote:
>>>>> Please take a review at
>>>>>     http://cr.openjdk.java.net/~weijun/8243592/webrev.00/
>>>>> This is helpful if we do any set arithmetic between 2 Subject objects.
>>>>> No new regression test, I intend to add a noreg-trivial label.
>>>>> *Tigran*: Please confirm you are OK with the "Contributed-by" line.
>>>>> Thanks,
>>>>> Max
> 


From bradford.wetmore at oracle.com  Wed Apr 29 00:58:15 2020
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Tue, 28 Apr 2020 17:58:15 -0700
Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm
 (JEP 339)
In-Reply-To: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
References: <f8f478c3-9886-b589-3ee2-86536a286cd6@oracle.com>
 <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com>
Message-ID: <0860fcd8-9cb7-7041-a448-7db3bc709224@oracle.com>

Hi Tony,

Apologies for the delay.

 > I updated the webrev with some minor updates that were commented
 > previously.
 >
 > https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/

I've finished the APIs and a fair chunk of the implementation, but had 
some initial comments.

Overall, the APIs look reasonable and I (or whoever) should have no 
problems adding TLS support for EdDSA once this is in place.

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

BTW, I reviewed based off the webrev.01 version (above), but I found in 
a later email exchange there was mention of a .04:

 > https://cr.openjdk.java.net/~ascarpino/8166597/webrev.04/

dated April 1.  I'm hoping that was just a proposed change idea, and not 
a new version to review.  Please advise if so.

In my comments below, if I say "you" below, it's the colloquial "you."
Could be you or the previous engineer.

If some of these questions have already been answered, I'll apologize in 
advance. I'm getting up to speed in RFC 8032 specifics so forgive any 
"duh" questions.

----

Common:  Throughout the API's, I noticed multiple minor javadoc
style issues, such as:

     . periods inconsistencies (missing or extras) (e.g.  EdECPoint)
     . omissions of @code (e.g. EdDSAParameterSpec/EdECPoint/etc.)

Suggest a javadoc sweep before final CSR.  I started calling them out, 
but stopped.

For keysize in things like KeyPairGenerator, why are we using 255/448 
(externally and internally) instead of 256/456?  From RFC 8032:

     section 3.2:  "An EdDSA private key is a b-bit string k"
+
     section 5.1.5/Ed25519:  "The private key is 32 octets (256 bits,
     corresponding to b) of cryptographically secure random data..."
     section 5.2.5/Ed448:  "The private key is 57 octets (456 bits,
     corresponding to b) of cryptographically secure random data..."

and

     section 3, parameter 2: "EdDSA public keys have exactly b bits"
and
     section 5.1:  "(parameter) b: 256"
     section 5.2:  "(parameter) b: 456"

The Wikipedia entry also lists as 256.  https://en.wikipedia.org/wiki/EdDSA

I notice BC does actually use both.

https://github.com/bcgit/bc-java/blob/master/prov/src/test/jdk1.4/org/bouncycastle/jce/provider/test/EdECTest.java#L365
https://github.com/bcgit/bc-java/blob/master/prov/src/test/jdk1.4/org/bouncycastle/jce/provider/test/EdECTest.java#L371

Why did you decide to not use the full algorithm names for the variants e.g.
Ed25519ctx/Ed25519ph/Ed448ph instead of just Ed25519/Ed448 and let the 
selection be done using the Parameters.  More for my understanding than 
an issue.

Also, I thing you and Max might have discussed EdDSA vs EDDSA (case), 
but in a different context.  RFC 8410/Section 8, the full names are 
"EdDSA"/"Ed25519"/"Ed448",
but you're using "EDDSA"/"ED25519"/"ED448".
There is precedence for upper/lower case in our Java Standard Names.
https://docs.oracle.com/en/java/javase/14/docs/specs/security/standard-names.html 
, so just wondering why you're standardizing on the upper case variant?

Is Ed448ph working?  I've been playing with your test vectors from RFC 
8032 in test/jdk/sun/security/ec/ed/TestEdDSA.java, where you included 
Ed25519/Ed25519ctx/Ed25519ph, but omitted several (6 of 9) of the Ed448 
tests and all of the Ed448ph tests. I tried very quickly to add the two 
Ed448ph tests in in section 7.5, but no luck.  Could be pilot error, but 
I tried a lot of different combos (with/without ph boolean, null array 
vs. empty array, etc), but seems like it should have been 
straightforward given the test framework.


Specific file comments:

make/jdk/src/classes/build/tools/intpoly/FieldGen.java
--------------------------------------------
Lines 643-650 are creating a bunch of comment like this which are
the BigInteger values used later:

 
//(0%nat,16110573)::(26%nat,10012311)::(52%nat,30238081)::(78%nat,-8746018)::(104%nat,1367802)::nil.

but what is the format of comment expressing?  What ae %nat/nil/::/etc.

src/java.base/share/classes/java/security/spec/NamedParameterSpec.java
--------------------------------------------
94: This never seems to be called in our main test suite, so not sure 
why this is here.  Please add a comment as to why you added this new 
no-args constructor.  (was it some Class.newInstance() somewhere/prevent 
unexpected object creation/some kind of reflection?)

Minor nit, you could put this constructor above the other constructor,
it gets kind of lost here visually.

src/java.base/share/classes/sun/security/pkcs/PKCS7.java
--------------------------------------------
832:  Seems like the right thing to do for making things bulletproof.
You're convinced this shouldn't happen in our code somewhere?  (i.e. 
unexpected new failure?)

src/java.base/share/classes/sun/security/provider/SHA3.java
--------------------------------------------
I see what you did here and made 0x06 a parameter in each of the 
implementation classes, but wondering why?  Is there another change I 
haven't gotten to yet?

src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java
--------------------------------------------
74:  Why 255 and not 256?  (See comment above)

src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java
--------------------------------------------
OK - I didn't check the math closely in this package, but the 
refactoring looks reasonable.

src/java.base/share/classes/java/security/interfaces/EdECPrivateKey.java
--------------------------------------------
47:  Do you want to mention a new copy of the array is returned here? 
You do say this in the spec version, and we do in the XECPrivateKey 
interface.

48:  @code the Optional.

53:  Might suggest reworking this to mention the Optional, since it is
actually the return type.  See XECPrivatekey for an example.

src/java.base/share/classes/java/security/interfaces/EdECPublicKey.java
--------------------------------------------
47:  @code the EdECPoint.

src/java.base/share/classes/java/security/spec/EdDSAParameterSpec.java
--------------------------------------------
Do you want to include checks/restrictions for contexts > 255 chars?

52/65:  @code the EdDSAParameterSpec

92:  "...bound to the signature" sounds premature.  This is the context
bound to the EdDSAParameteerSpec, which hasn't been yet bound to the 
signature.

94:  The word "empty" here seems overloaded between empty arrays which
are array objects with no elements, and empty Optionals which are 
Optionals with no values which would later throw a 
NoSuchElementException on a get().  Wondering if there is a better way 
to say this to not cause confusion? Maybe saying this is an "empty 
Optional?"

src/java.base/share/classes/java/security/spec/EdECPrivateKeySpec.java
--------------------------------------------
33:  Same comment about representation as above.

test/jdk/sun/security/ec/ed/TestEdDSA.java
--------------------------------------------
40:  Should not need this kind of SecureRandom initialization anymore. 
Remove the seed byte array.

51:  Please add some comments in here to indicate that these are the
test vectors from RFC 8032, so that folks can mentally map if they so 
choose.

194:  Comment is above, but more details here.  All of the test vectors 
were included to this point, then it just stopped after 3 Ed448 tests, 
leaving out 6 of 9 tests, including all of the Ed448ph tests.  RFC pages 
32-39.  Intentional? I did try to stick in the two Ed448ph tests from 
7.5, and it failed, so maybe I'm missing something?

Thanks, I'll continue on tomorrow.

Brad


On 3/23/2020 11:53 AM, Anthony Scarpino wrote:
> On 2/25/20 12:49 PM, Anthony Scarpino wrote:
>> Hi
>>
>> I need a code review for the EdDSA support in JEP 339.? The code 
>> builds on the existing java implemented constant time classes used for 
>> XDH and the NIST curves.? The change also adds classes to the public 
>> API to support EdDSA operations.
>>
>> All information about the JEP is located at:
>> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219
>>
>> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/
>>
>> thanks
>>
>> Tony



From weijun.wang at oracle.com  Wed Apr 29 08:08:41 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 29 Apr 2020 16:08:41 +0800
Subject: RFR 8244087: 2020-04-24 public suffix list update
Message-ID: <5F57E122-3800-4C08-8C9D-0D3DF6C86B1D@oracle.com>

Please take a review at

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

I modified the test a little and thus updated the test program with a new copyright year and a @bug. This makes sure the automatic (?) verifier knows there is a regression test.

*Frances*: Do I need to link this RFE to any other JBS issues?

Thanks,
Max



From frances.ho at oracle.com  Wed Apr 29 15:40:33 2020
From: frances.ho at oracle.com (Frances Ho)
Date: Wed, 29 Apr 2020 08:40:33 -0700
Subject: RFR 8244087: 2020-04-24 public suffix list update
In-Reply-To: <5F57E122-3800-4C08-8C9D-0D3DF6C86B1D@oracle.com>
References: <5F57E122-3800-4C08-8C9D-0D3DF6C86B1D@oracle.com>
Message-ID: <8672d1c5-85cc-1605-748e-184f5cc4cd2a@oracle.com>



On 4/29/2020 1:08 AM, Weijun Wang wrote:
> Please take a review at
>
>    https://cr.openjdk.java.net/~weijun/8244087/webrev.00
>
> I modified the test a little and thus updated the test program with a new copyright year and a @bug. This makes sure the automatic (?) verifier knows there is a regression test.
>
> *Frances*: Do I need to link this RFE to any other JBS issues?
I don't think so, we didn't do special linking for any of the previous
update right? Sean?
>
> Thanks,
> Max
>



From valerie.peng at oracle.com  Wed Apr 29 22:59:52 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 29 Apr 2020 15:59:52 -0700
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
 <CD284E5D-AE77-4757-AB7D-84467BCD5114@oracle.com>
 <cd968cc6-3b86-cf1b-9618-12137861c9a3@oracle.com>
 <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com>
Message-ID: <b00c119b-3c8a-6e0b-1740-ea9a74697e4c@oracle.com>

Hi Max,

Here is the updated webrev 
http://cr.openjdk.java.net/~valeriep/8242151/webrev.01/

which should address your earlier comments (see below)

- OidString renamed to KnownOIDs and updated the aliasing handling code 
in both KnownOIDs and SecurityProviderConstants classes

- Removed additional oid constants in AlgorithmId class which are only 
referenced by regression tests, so webrev.01 adds two more regression 
tests accordingly

- Moved the computeOidTable() and its relevant code to AlgorithmId class

- Use extra standard name arg for ExtendedKeyUsage enums.

> Inside getAliases(), why must there be an exception when there is no OidString.findMatch(o)? Does every algorithm name need an OID? I thought of X.509 but you have added it into aliases.

Hmm, the exception is meant to catch scenarios where the specified name 
has a typo and to signal the caller that expected aliases is not found. 
I updated the code in webrev.01 to make it clearer.

Valerie

On 4/27/2020 6:37 PM, Weijun Wang wrote:
>> On Apr 28, 2020, at 8:08 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Yes, it can be quite a confusing scenario. Some algorithms have multiple oids (say X) and multiple algorithm names (say Y). We need to be able to handle all of them (X+Y). However, the separation of alias definition for OidString and SecurityProviderConstants are intentional and I have them separated with the reason below:
>>
>> The aliases in OidString can be viewed as internal, e.g. from JCA classes and used by AlgorithmId class and its regression tests. All of the supported oids (X of them) have to have an OidString enum type as their usage may be present in the DER encoding and all internal classes need to handle it. As for the multiple algorithm names, supposedly, there is only one standard name and the rest are all aliases. Aliases can be used to request the impl from provider, but that's all. Internal classes do not need to understand these external/provider-related aliases. By separating these external aliases inside SecurityProviderConstants, it is clear that these aliases are for providers only.
> I understand.
>
> In SecurityProviderConstants::getAliases, is it possible to combine aliases.get(o) and OidString.findMatch(o)? Or we can rewrite store() and grab info from OidString so that there is no need to always add OID.oid and oid in the store() calls.
>
> Inside getAliases(), why must there be an exception when there is no OidString.findMatch(o)? Does every algorithm name need an OID? I thought of X.509 but you have added it into aliases.
>
>> StdName itself should not be its aliases. Which line in SecurityProviderConstants class has this problem?
> Sorry, I got it wrong. I've mistakenly thought that OidString.DSA.value() is the name.
>
> Thanks,
> Max
>
>> Thanks,
>>
>> Valerie
>>
>> On 4/25/2020 7:46 AM, Weijun Wang wrote:
>>> And I am confused by aliases in SecurityProviderConstants, together with the duplicated stdName in OidString, it seems to show that one OID could have multiple names, and one name could have multiple OIDs. Can we consolidate aliases inside OidString also?
>>>
>>> Also, looking at the store() calls in SecurityProviderConstants, it looks like a stdName itself is one of its aliases. Is this really useful? From what I read in the provider classes, you are adding ServiceKeys based on these aliases to a serviceMap which already has a ServiceKey based on stdName.
>>>
>>> Thanks,
>>> Max
>>>
>>>> On Apr 25, 2020, at 6:28 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>
>>>> OidString.java
>>>> ==============
>>>>
>>>> 1. ExtendedKeyUsage names: used to be "serverAuth", now "ServerAuth". First letter capitalized, is this necessary?
>>>>
>>>> 2. Can we move name2oidStr() from OidString to AlgorithmId? The computeOidTable process looks like an alien.
>>>>
>>>> 3. Two questions on the following lines:
>>>>
>>>> 415         // set extra alias mappings or specify the preferred one when
>>>> 416         // one standard name maps to multiple enums
>>>> 417         // NOTE: key must use UPPER CASE
>>>> 418         name2enum.put("SHA1", SHA_1);
>>>> 419         name2enum.put("SHA", SHA_1);
>>>> 420         name2enum.put("SHA224", SHA_224);
>>>> 421         name2enum.put("SHA256", SHA_256);
>>>> 422         name2enum.put("SHA384", SHA_384);
>>>> 423         name2enum.put("SHA512", SHA_512);
>>>> 424         name2enum.put("SHA512/224", SHA_512$224);
>>>> 425         name2enum.put("SHA512/256", SHA_512$256);
>>>> 426         name2enum.put("DH", DiffieHellman);
>>>> 427         name2enum.put("DSS", SHA1withDSA);
>>>> 428         name2enum.put("RSA", RSA);
>>>>
>>>>    a) For line 428, is this because both RSA and ITUX509_RSA have the same stdName and you are setting the preferred one? However, I can see that "DiffieHellman", "DSA", and "SHA1withDSA" also appear in multiple places. Do they need special attention?
>>>>
>>>>    b) For the other lines, can we make this info somewhere inside the constructor? After all our goal is to consolidate all info in one single place, and a single line is better than a single file, esp, a very big file.
>>>>
>>>> 4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?
>>>>
>>>> 5. I found KnownOIDs to be a better class name.
>>>>
>>>> AlgorithmId.java
>>>> ================
>>>>
>>>> There are still many lines like
>>>>
>>>>     public static final ObjectIdentifier MD2_oid = algOID(OidString.MD2);
>>>>
>>>> here. Can they be eliminated? I use IntelliJ IDEA to find their usages and most are used in only one place and some are not used at all.
>>>>
>>>>
>>>> I haven't read other files yet. Will send more comment later.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>
>>>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>>>
>>>>> Hi Max,
>>>>>
>>>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>>>>
>>>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>>>>
>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>>>>
>>>>> Mach5 runs clean.
>>>>>
>>>>> Valerie
>>>>>


From valerie.peng at oracle.com  Wed Apr 29 23:07:20 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 29 Apr 2020 16:07:20 -0700
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <A1CC1EE2-B11D-4490-AAC6-9FA75225793E@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <A1CC1EE2-B11D-4490-AAC6-9FA75225793E@oracle.com>
Message-ID: <6a28b35e-ab05-8e32-bed1-95738fc0fa9c@oracle.com>


toString() returns the standard name which the enum corresponds to.

Yes, I agree that it's better to use a dedicated method name for this. 
Will address this in webrev.02.

Valerie


On 4/28/2020 3:37 AM, Weijun Wang wrote:
> Is OidString::toString really used anywhere? If so, I suggest we create a special method for it so it's easy to use an IDE to find out all usages. Finding toString returns usages of Object::toString and it's everywhere.
>
> --Max
>
>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Hi Max,
>>
>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>
>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>
>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>
>> Mach5 runs clean.
>>
>> Valerie
>>


From valerie.peng at oracle.com  Wed Apr 29 23:55:37 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 29 Apr 2020 16:55:37 -0700
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <9227B6A8-DBCF-4217-9E12-995B70630643@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <CC661B20-D732-4BB8-8A4E-9B143C6497EB@oracle.com>
 <23326b44-baa7-19d3-f67c-7161656d7e0e@oracle.com>
 <9227B6A8-DBCF-4217-9E12-995B70630643@oracle.com>
Message-ID: <6c48e2c5-82ae-37e5-70b4-4df97d94fdea@oracle.com>

Hi Max,

I believe most of your comments (except the two below) in this email 
should already be addressed in webrev.01.

> I caught them by looking at the "skipped" debug output. Can we add some logic to detect this? For example, for those nonpreferred OIDs, use a special constructor?
Hmm, ok, let me think about this. Will see what I can do in webrev.02.

> We can also populate the name2enum map inside the constructor, there is no need to store the aliases in each enum.
I tried this approach earlier and ran into some class initialization 
error when building JDK. So, I still populate the name2enum map in the 
static initialization block.

Thanks,
Valerie
On 4/27/2020 7:15 PM, Weijun Wang wrote:
>> On Apr 28, 2020, at 6:19 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>> Hi Max,
>>
>> Thanks for reviewing this~ Please find my replies inline.
>>
>> On 4/25/2020 3:28 AM, Weijun Wang wrote:
>>> OidString.java
>>> ==============
>>>
>>> 1. ExtendedKeyUsage names: used to be "serverAuth", now "ServerAuth". First letter capitalized, is this necessary?
>> Yes, I made a change here. Using "ServerAuth" seems more consistent with the rest of constants in OidString. So I made a change here. It affects the displayed out but no regression tests are affected by this change. Well, if we want to be 100% same as before, I can change these to start with lower case, but then we probably need comments so it's clear that these are intentional changes.
> I'd rather use the old name.
>
>>> 2. Can we move name2oidStr() from OidString to AlgorithmId? The computeOidTable process looks like an alien.
>> Well, I think it's better to consolidate all oid string/algorithm names to as few places as possible.
>>
>> AlgorithmId class used to contain a lot of such conversions and now that there is OidString class (we can discuss a better name for it), it should be updated to use OidString and just be a general impl class for handling ASN AlgorithmId structure. Let me try putting this utility method name2oidStr() elsewhere and see.
> computeOidTable() is only called by name2oid() only called by name2oidStr() only called by algOID() which is in AlgorithmId.
>
> algOID() in AlgorithmId is called by AlgorithmId::get which makes it quite the core of that class.
>
>>> 3. Two questions on the following lines:
>>>
>>>   415         // set extra alias mappings or specify the preferred one when
>>>   416         // one standard name maps to multiple enums
>>>   417         // NOTE: key must use UPPER CASE
>>>   418         name2enum.put("SHA1", SHA_1);
>>>   419         name2enum.put("SHA", SHA_1);
>>>   420         name2enum.put("SHA224", SHA_224);
>>>   421         name2enum.put("SHA256", SHA_256);
>>>   422         name2enum.put("SHA384", SHA_384);
>>>   423         name2enum.put("SHA512", SHA_512);
>>>   424         name2enum.put("SHA512/224", SHA_512$224);
>>>   425         name2enum.put("SHA512/256", SHA_512$256);
>>>   426         name2enum.put("DH", DiffieHellman);
>>>   427         name2enum.put("DSS", SHA1withDSA);
>>>   428         name2enum.put("RSA", RSA);
>>>
>>>     a) For line 428, is this because both RSA and ITUX509_RSA have the same stdName and you are setting the preferred one? However, I can see that "DiffieHellman", "DSA", and "SHA1withDSA" also appear in multiple places. Do they need special attention?
>> Yes, initially I was relying on the ordering of enums to handle the 1-to-N mapping. Later, I changed to explicitly define the mapping as in the webrev as this should be more robust. I should have added other algorithms here too. Will update.
> I caught them by looking at the "skipped" debug output. Can we add some logic to detect this? For example, for those nonpreferred OIDs, use a special constructor?
>
>>>     b) For the other lines, can we make this info somewhere inside the constructor? After all our goal is to consolidate all info in one single place, and a single line is better than a single file, esp, a very big file.
>> For other lines => are you referring to the extra aliases?
> Oh, I meant lines 415 - 428.
>
>> Instead of specifying the aliases for each enum explicitly as in current webrev, store them into the constructor and save them into the name2enum map while looping through the enum values? The current approach has the benefit of being straightforward and no need to worry about duplicate aliases.
> We can also populate the name2enum map inside the constructor, there is no need to store the aliases in each enum.
>
>>> 4. Are you sure the OID <-> name mapping is always the same everywhere (for all primitives and in all providers)? I mean for a stdName, if one OID alias is added in one place, should it always be added the same way in another? Have you compared the aliases map after this change?
>> OID is tied to an algorithm name. Thus, it should be universal to all JDK providers as long as the algorithm impl is interoperable. In the past, it's very easy to miss adding the OIDs as they are hardcoded in different places. For providers who are lower in the provider list, registering the OIDs may not be that important if a more preferred provider already supports the same impl. Rather than registering identical entries, with this change, the OID support should be consistent across providers.
> Good to know.
>
>>> 5. I found KnownOIDs to be a better class name.
>> Sure, fine with me.
>>> AlgorithmId.java
>>> ================
>>>
>>> There are still many lines like
>>>
>>>      public static final ObjectIdentifier MD2_oid = algOID(OidString.MD2);
>>>
>>> here. Can they be eliminated? I use IntelliJ IDEA to find their usages and most are used in only one place and some are not used at all.
>> Yes, I debated about it. It's tricky to draw the line. My current thought is to keep these "public static" constants intact if they are directly referenced somewhere. There are also many places where I think further trimming/cleanup can be made. But as it is, it is already extensive. Maybe it's safer to be conservative and gradually clean up...
> Fair enough.
>
> If we want to eliminate the use of these objects later, is there a way to not create a new ObjectIdentifier object each time? I think I've read some C projects that defines OID as the DER encoding but not as strings. String is only best for log usages. But this is a much broader topic.
>
>>> I haven't read other files yet. Will send more comment later.
>> Sure, these two are the key files.
>>
>> I will experiment on the utility method and we can discuss it further.
> Thanks,
> Max
>
>> Thanks,
>> Valerie
>>> Thanks,
>>> Max
>>>
>>>
>>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>>
>>>> Hi Max,
>>>>
>>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>>>
>>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>>>
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>>>
>>>> Mach5 runs clean.
>>>>
>>>> Valerie
>>>>


From valerie.peng at oracle.com  Thu Apr 30 00:15:35 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 29 Apr 2020 17:15:35 -0700
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <F8F245F6-DFA4-4BEC-903E-1E6B9F30323E@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <BE30CAB9-9D62-450C-851A-0AECCC98342C@oracle.com>
 <F8F245F6-DFA4-4BEC-903E-1E6B9F30323E@oracle.com>
Message-ID: <b885cbdc-ec89-a3ff-3ae2-886a67423891@oracle.com>


If you look at the original SunJCE impl, it also did not register oid 
for RC4 cipher. So, that's why I didn't include RC4 oid in 
SecurityProviderConstants in the aliases for RC4.

If I recall correctly, "RC4" is the algorithm name, however, due to some 
patent(?) concern, non-RSA vendors register their impl under "ARCFOUR" 
and set "RC4" to be the alias. So, that's the convention that I continue 
to use, i.e. use "ARCFOUR" as the standard name and "RC4" as the alias.

I can add the oid as the RC4 alias for completeness sake. (Will update 
in webrev.02)

Thanks,
Valerie
On 4/28/2020 2:39 AM, Weijun Wang wrote:
> I found two algorithm names in a very twisted relation, in SecurityProviderConstants.java:
>
>          store("ARCFOUR", "RC4");
>
> and in OidString.java:
>
>      RC4("1.2.840.113549.3.4", "ARCFOUR")
>
> So each is the other's alias, and because of this, Cipher.ARCFOUR does not have OID aliases.
>
> I can see in https://download.java.net/java/early_access/jdk15/docs/specs/security/standard-names.html that both ARCFOUR and RC4 are standard names. In my understanding, this means both must be supported and it looks like some kind of "required" alias. Is this the reason we have to define them in this way?
>
> Thanks,
> Max
>
>
>> On Apr 28, 2020, at 4:53 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Where is the following OID used
>>
>>       RSAEncryption("1.2.840.113549.1.1.1", "RSA"), // in RSA Cipher
>>
>> I only found in RSAUtil.java:
>>
>>                 case RSA:
>>                     oid = AlgorithmId.RSAEncryption_oid;
>>                     break;
>>
>> What if we do not give it a different stdName? Or, should we make it an alias in SunJCE for Cipher.RSA?
>>
>> --Max
>>
>>
>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>
>>> Hi Max,
>>>
>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>>
>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>>
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>>
>>> Mach5 runs clean.
>>>
>>> Valerie
>>>


From weijun.wang at oracle.com  Thu Apr 30 13:50:02 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 30 Apr 2020 21:50:02 +0800
Subject: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal
In-Reply-To: <1cb283c7-2047-bbd1-05a2-c852b19f67f8@oracle.com>
References: <45F36569-C6F0-4827-ACF4-6A7B69890559@oracle.com>
 <d814219e-3337-e1f8-4ad7-0dde2534060e@oracle.com>
 <40F07BEA-6C60-4D80-B1C1-86402FD67E57@oracle.com>
 <1dfd1e84-d1ea-6162-970e-f061373e8fa7@oracle.com>
 <FFB9D940-2F66-4024-879E-E5AF78BDEC62@oracle.com>
 <1cb283c7-2047-bbd1-05a2-c852b19f67f8@oracle.com>
Message-ID: <FC2D6BAF-4FD4-42F6-A67C-46DE8EC4E4E3@oracle.com>

Webrev updated at

   http://cr.openjdk.java.net/~weijun/8243592/webrev.02/

I removed my old test and rewrite the existing SubjectNullTests.java test in TestNG with quite some new test cases.

There are so many behavior changes (although we might say good programs are not affected) that I decided to add a CSR and a release note. Please also take a look.

            CSR : https://bugs.openjdk.java.net/browse/JDK-8244165
   release note : https://bugs.openjdk.java.net/browse/JDK-8244169

Thanks,
Max


> On Apr 29, 2020, at 2:57 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> I don't think containsAll and retainsAll need to call collectionNullClean either because SecureSet.contains(null) returns false now.
> 
> --Sean
> 
> On 4/28/20 9:58 AM, Weijun Wang wrote:
>> A new webrev is at
>>    http://cr.openjdk.java.net/~weijun/8243592/webrev.01/
>> I take this chance to do some formatting and add a new test. My first testng test!
>> Thanks,
>> Max
>>> On Apr 28, 2020, at 8:16 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> On 4/27/20 10:39 PM, Weijun Wang wrote:
>>>> Reading the Set spec, it looks like an NPE is still needed for add(), but remove() can be modified.
>>> 
>>> Good point, I agree.
>>> 
>>> --Sean
>>> 
>>>> --Max
>>>>> On Apr 27, 2020, at 10:27 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>>>> 
>>>>> The fix looks fine to me. For consistency, you could make the same change for null elements in the other SecureSet methods: add, remove.
>>>>> 
>>>>> --Sean
>>>>> 
>>>>> On 4/25/20 3:39 AM, Weijun Wang wrote:
>>>>>> Please take a review at
>>>>>>    http://cr.openjdk.java.net/~weijun/8243592/webrev.00/
>>>>>> This is helpful if we do any set arithmetic between 2 Subject objects.
>>>>>> No new regression test, I intend to add a noreg-trivial label.
>>>>>> *Tigran*: Please confirm you are OK with the "Contributed-by" line.
>>>>>> Thanks,
>>>>>> Max



From weijun.wang at oracle.com  Thu Apr 30 13:55:16 2020
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 30 Apr 2020 21:55:16 +0800
Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK
 security providers for aliases registration
In-Reply-To: <b885cbdc-ec89-a3ff-3ae2-886a67423891@oracle.com>
References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com>
 <BE30CAB9-9D62-450C-851A-0AECCC98342C@oracle.com>
 <F8F245F6-DFA4-4BEC-903E-1E6B9F30323E@oracle.com>
 <b885cbdc-ec89-a3ff-3ae2-886a67423891@oracle.com>
Message-ID: <B403FDA0-7242-4A11-9A1D-2E98209FAA32@oracle.com>

Sorry, it's been a busy day on something else and I haven't looked at your webrev.01 yet. Will look at it tomorrow.

> On Apr 30, 2020, at 8:15 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> 
> If you look at the original SunJCE impl, it also did not register oid for RC4 cipher. So, that's why I didn't include RC4 oid in SecurityProviderConstants in the aliases for RC4.
> 
> If I recall correctly, "RC4" is the algorithm name, however, due to some patent(?) concern, non-RSA vendors register their impl under "ARCFOUR" and set "RC4" to be the alias. So, that's the convention that I continue to use, i.e. use "ARCFOUR" as the standard name and "RC4" as the alias.
> 
> I can add the oid as the RC4 alias for completeness sake. (Will update in webrev.02)

Since ARCFOUR is the standard name, does it make sense to rewrite the OidString to

      ARCFOUR("1.2.840.113549.3.4", "RC4"),

--Max

> 
> Thanks,
> Valerie
> On 4/28/2020 2:39 AM, Weijun Wang wrote:
>> I found two algorithm names in a very twisted relation, in SecurityProviderConstants.java:
>> 
>>         store("ARCFOUR", "RC4");
>> 
>> and in OidString.java:
>> 
>>     RC4("1.2.840.113549.3.4", "ARCFOUR")
>> 
>> So each is the other's alias, and because of this, Cipher.ARCFOUR does not have OID aliases.
>> 
>> I can see in https://download.java.net/java/early_access/jdk15/docs/specs/security/standard-names.html that both ARCFOUR and RC4 are standard names. In my understanding, this means both must be supported and it looks like some kind of "required" alias. Is this the reason we have to define them in this way?
>> 
>> Thanks,
>> Max
>> 
>> 
>>> On Apr 28, 2020, at 4:53 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Where is the following OID used
>>> 
>>>      RSAEncryption("1.2.840.113549.1.1.1", "RSA"), // in RSA Cipher
>>> 
>>> I only found in RSAUtil.java:
>>> 
>>>                case RSA:
>>>                    oid = AlgorithmId.RSAEncryption_oid;
>>>                    break;
>>> 
>>> What if we do not give it a different stdName? Or, should we make it an alias in SunJCE for Cipher.RSA?
>>> 
>>> --Max
>>> 
>>> 
>>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>>> 
>>>> Hi Max,
>>>> 
>>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach.
>>>> 
>>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class.
>>>> 
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/
>>>> 
>>>> Mach5 runs clean.
>>>> 
>>>> Valerie
>>>> 



From xuelei.fan at oracle.com  Thu Apr 30 17:19:45 2020
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 30 Apr 2020 10:19:45 -0700
Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the
 handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3
Message-ID: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com>

Hi,

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

For TLS 1.3 full handshake, if the last handshake flight wraps the 
Finished together with other handshake message, for example client 
certificate, the flight could be wrapped and encrypted in one record and 
delegated tasks would be used.  There is no chance to return FINISHED 
handshake status with SSLEngine.(un)wrap(). However, per the 
HandshakeStatus.FINISHED specification, this handshake status is only 
generated by a call to SSLEngine.wrap()/unwrap() and it is never 
generated by SSLEngine.getHandshakeStatus().

In order to workaround this case for TLS 1.3, the FINISHED status could 
present with SSLEngine.wrap() while delivering of the NewSessionTicket 
post-handshake message.  If this post-handshake message is not needed, a 
follow-on SSLEngine.wrap() should be called to indicate the FINISHED 
handshake status.  Although this special SSLEngine.wrap() should not 
consume or produce any application or network data.

I also clean up some debug log, names and code style a little bit.

The update could be confirmed with Tomcat and Firefox in private mode, 
as described in the bug description.  As this case happens only when 
psk_key_exchange_modes does not present, which is not a behavior 
supported by JDK, I did not find a workaround for a new regression test 
yet.  I added the labels, noreg-external and noreg-hard.

Thanks,
Xuelei


From RAJAN.HALADE at ORACLE.COM  Thu Apr 30 18:11:14 2020
From: RAJAN.HALADE at ORACLE.COM (Rajan Halade)
Date: Thu, 30 Apr 2020 11:11:14 -0700
Subject: RFR: 8225068: Remove DocuSign root certificate that is expiring in
 May 2020
Message-ID: <FB6F08CA-1811-46B4-BD22-D1C6994E67A5@ORACLE.COM>

Please review this patch to remove Keynectis CA certificate from cacerts store.

Webrev: http://cr.openjdk.java.net/~rhalade/8225068/webrev.00/ <http://cr.openjdk.java.net/~rhalade/8225068/webrev.00/>

Thanks,
Rajan

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

From mstjohns at comcast.net  Thu Apr 30 18:53:16 2020
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 30 Apr 2020 14:53:16 -0400
Subject: RFR: 8225068: Remove DocuSign root certificate that is expiring
 in May 2020
In-Reply-To: <FB6F08CA-1811-46B4-BD22-D1C6994E67A5@ORACLE.COM>
References: <FB6F08CA-1811-46B4-BD22-D1C6994E67A5@ORACLE.COM>
Message-ID: <2038b2ca-75fe-5128-52f7-380cfeeb20b7@comcast.net>

On 4/30/2020 2:11 PM, Rajan Halade wrote:
> Please review this patch to remove Keynectis CA certificate from 
> cacerts store.
>
> Webrev: http://cr.openjdk.java.net/~rhalade/8225068/webrev.00/
>
> Thanks,
> Rajan
>
Hi -

There are three other certificates expiring a week after the one you're 
removing - why aren't they going too?

Mike


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

From sean.mullan at oracle.com  Thu Apr 30 21:22:07 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 30 Apr 2020 17:22:07 -0400
Subject: RFR: 8225068: Remove DocuSign root certificate that is expiring
 in May 2020
In-Reply-To: <FB6F08CA-1811-46B4-BD22-D1C6994E67A5@ORACLE.COM>
References: <FB6F08CA-1811-46B4-BD22-D1C6994E67A5@ORACLE.COM>
Message-ID: <f2df1e17-a88a-0feb-94d2-28becc02fdd4@oracle.com>

Looks fine to me.

--Sean

On 4/30/20 2:11 PM, Rajan Halade wrote:
> Please review this patch to remove Keynectis CA certificate from cacerts 
> store.
> 
> Webrev: http://cr.openjdk.java.net/~rhalade/8225068/webrev.00/
> 
> Thanks,
> Rajan
> 


From sean.mullan at oracle.com  Thu Apr 30 21:29:57 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 30 Apr 2020 17:29:57 -0400
Subject: RFR: 8225068: Remove DocuSign root certificate that is expiring
 in May 2020
In-Reply-To: <2038b2ca-75fe-5128-52f7-380cfeeb20b7@comcast.net>
References: <FB6F08CA-1811-46B4-BD22-D1C6994E67A5@ORACLE.COM>
 <2038b2ca-75fe-5128-52f7-380cfeeb20b7@comcast.net>
Message-ID: <012135f6-2cf5-89a9-09d4-9e3e874996d7@oracle.com>

On 4/30/20 2:53 PM, Michael StJohns wrote:
> On 4/30/2020 2:11 PM, Rajan Halade wrote:
>> Please review this patch to remove Keynectis CA certificate from 
>> cacerts store.
>>
>> Webrev: http://cr.openjdk.java.net/~rhalade/8225068/webrev.00/
>>
>> Thanks,
>> Rajan
>>
> Hi -
> 
> There are three other certificates expiring a week after the one you're 
> removing - why aren't they going too?

One of those will be removed soon. See 
https://bugs.openjdk.java.net/browse/JDK-8225069

The other two have had code signing certificates that chain back to the 
roots. The roots need to remain in order to continue to support 
applications that have been previously signed and timestamped.

--Sean


From sean.mullan at oracle.com  Thu Apr 30 21:39:04 2020
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 30 Apr 2020 17:39:04 -0400
Subject: RFR 8244087: 2020-04-24 public suffix list update
In-Reply-To: <5F57E122-3800-4C08-8C9D-0D3DF6C86B1D@oracle.com>
References: <5F57E122-3800-4C08-8C9D-0D3DF6C86B1D@oracle.com>
Message-ID: <a43edd9d-297e-5717-c295-59cb89aa9483@oracle.com>

Looks good to me.

--Sean

On 4/29/20 4:08 AM, Weijun Wang wrote:
> Please take a review at
> 
>     https://cr.openjdk.java.net/~weijun/8244087/webrev.00
> 
> I modified the test a little and thus updated the test program with a new copyright year and a @bug. This makes sure the automatic (?) verifier knows there is a regression test.
> 
> *Frances*: Do I need to link this RFE to any other JBS issues?
> 
> Thanks,
> Max
> 


From valerie.peng at oracle.com  Thu Apr 30 23:28:06 2020
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 30 Apr 2020 16:28:06 -0700
Subject: [15] RFR: 8242335: Additional Tests for RSASSA-PSS
In-Reply-To: <DAE3FB0F-1356-4A2A-8B5F-56E5E8942BB7@oracle.com>
References: <DAE3FB0F-1356-4A2A-8B5F-56E5E8942BB7@oracle.com>
Message-ID: <61ba42dc-5492-69fe-ec3e-360d93fc6a7b@oracle.com>

Hi, Siba,

Here are my comments:

<SerializedPSSKey.java>

- Typos: Initialisation -> Initialization.

- the 2nd algorithm specific initialization using reflection doesn't 
seem too useful. The code path should be exactly the same as the 
non-reflection one. Maybe just remove it.

Rest looks fine.

Thanks,
Valerie
On 4/28/2020 12:38 AM, sibabrata.sahoo at oracle.com wrote:
> Hi Valerie,
>
> Please review the patch for,
> JBS: https://bugs.openjdk.java.net/browse/JDK-8242335
> Webrev: http://cr.openjdk.java.net/~ssahoo/8242335/webrev.00/
>
> These are additional Tests developed to support RSASSA-PSS algorithm. 
> One is key compatibility with OpenSSL generated while the other one is 
> the API Tests for serialized keys.
>
> Thanks,
> Siba
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200430/c4810744/attachment.htm>

From hai-may.chao at oracle.com  Thu Apr 30 23:29:48 2020
From: hai-may.chao at oracle.com (Hai-May Chao)
Date: Thu, 30 Apr 2020 16:29:48 -0700
Subject: RFR[15] 8242060: Add revocation checking to jarsigner
Message-ID: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com>

Hi,

I?d like to request a review for:

JBS: https://bugs.openjdk.java.net/browse/JDK-8242060
CSR: https://bugs.openjdk.java.net/browse/JDK-8244046
Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/

The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL.

Thanks,
Hai-May