Re: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339)

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

Re: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal

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

Re: Evaluation part 1 of JDK-6722928: Provide a default native GSS-API library on Windows

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

Re: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal

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 wrote: > > On 4/27/20 10:39 PM, Weijun Wang wrote: >> Reading the Set spec,

Re: RFR 8243592: Subject$SecureSet::contains(null) is suboptimal

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 wrote: The fix looks fine to me. For consistency, you could make the

Re: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration

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 wrote: > > Hi Max, >

Re: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration

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

Re: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration

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,

[15] RFR: 8242335: Additional Tests for RSASSA-PSS

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