From weijun.wang at oracle.com Mon Jun 1 01:26:03 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 1 Jun 2020 09:26:03 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <6d2f9950-5306-b4a9-d62e-688bbac2f989@oracle.com> References: <1f29a11a-40de-2e56-7524-1323d0ed326d@oracle.com> <95519263-3ED3-4D80-AB30-80A86ECAA611@oracle.com> <6d2f9950-5306-b4a9-d62e-688bbac2f989@oracle.com> Message-ID: Replies inline below. I've removed the items I agree with for simplicity. > On May 30, 2020, at 3:32 AM, Sean Mullan wrote: > > On 5/23/20 4:21 AM, Weijun Wang wrote: >> CSR updated at https://bugs.openjdk.java.net/browse/JDK-8245274 with the full patch on docs. > > - Comments on the Specification section: > > Some of this wording where you discuss what is going to be done in jarsigner and the tool doc seems more like it belongs in the Solution section, but it may be ok either way (not sure, I guess Joe will let you know if it is an issue). > > +RSASSA-PSS \<= 3072 RSASSA-PSS using SHA-256 > + \<= 7680 RSASSA-PSS using SHA-384 > + \> 7680 RSASSA-PSS using SHA-512 > > It might be better to be more specific, for example "RSASSA-PSS with the SHA-256 message digest algorithm" I used the term "with" as that is the word we use in the standard signature algorithm strings. Can I simply say "RSASSA-PSS with SHA-256"? Otherwise the text is much longer than the other rows. That said, we have enough width and no need to wrap. Also, we used to say HASHwithENC, but here it's "ENC with HASH". Hopefully this will not make people laugh. > > > +for keysize \<= 3072 bits, use a `PSSParameterSpec` with SHA-256 as the hash > > s/use a `PSSParameterSpec`/a `PSSParameterSpec` will be used/ > > +and MGF1 algorithms; for keysize \<= 7680 bits, use SHA-384; for > +keysize \>= 7680 bits, use SHA-512. > > s/use SHA-384/SHA-384 will be used/ > s/use SHA-512/SHA-512 will be used/ My original text is Precisely, for keysize \<= 3072 bits, use a `PSSParameterSpec` with SHA-256 as the hash and MGF1 algorithms; for keysize \<= 7680 bits, use SHA-384; for keysize \>= 7680 bits, use SHA-512. So the object of "use" here is the PSSParameterSpec. If I change it to passive voice, it will be a `PSSParameterSpec` with SHA-256 as the hash and MGF1 algorithms will be used, and `PSSParameterSpec` (instead of SHA-256) will be the noun. The "SHA-384 will be used" in the next sentence might not be 100% grammatically correct in this sense but I think it's OK and nobody will misunderstand it. (In fact, there is the same problem in my original text). Thanks, Max p.s. This is probably the only RFE I can add into jdk15 before rdp1 now. The strong p12 algorithms and new CACERTS keystore type won't be ready. I do have several bug fixes that can wait till rdp2. > > --Sean > From weijun.wang at oracle.com Mon Jun 1 03:26:49 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 1 Jun 2020 11:26:49 +0800 Subject: [15] RFR JDK-8242897 KeyFactory.generatePublic( x509Spec ) failed with java.security.InvalidKeyException In-Reply-To: References: <73f67be4-9e09-00da-5a87-b2fa4f99bc91@oracle.com> <72eb4030-4a15-3683-fb37-b66e038b5c43@oracle.com> Message-ID: <6893B8FE-5E45-4D48-ABF2-01A2DAEFB9C5@oracle.com> The code change looks fine to me. One small comment: I notice that "KeyType type" and "AlgorithmParameterSpec keyParams" always go hand in hand, either as fields inside a class, or in the argument list of a method. Does it make sense to combine these 2 guys into a single class? It will look like a child class of AlgorithmId which understand what its alg and params mean. Of course you won't be able to make KeyType an enum anymore. All up to you. Thanks, Max > On May 30, 2020, at 5:07 AM, Valerie Peng wrote: > > Re-worked the fix a bit to take in Max's feedback: > > Webrev updated athttp://cr.openjdk.java.net/~valeriep/8242897/webrev.01/ > > Instead of completely reverting to the pre-PSS behavior of ignoring the OID in the DER encoding, this updated webrev has special handling to work with the scenario in the bug report. Most changes are code refactoring driven by the argument type change... > > Thanks, > Valerie > > > On 5/7/2020 4:17 PM, Valerie Peng wrote: >> Ping? >> >> On 4/23/2020 3:28 PM, Valerie Peng wrote: >>> 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 weijun.wang at oracle.com Mon Jun 1 04:45:49 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 1 Jun 2020 12:45:49 +0800 Subject: [15] RFR JDK-8242897 KeyFactory.generatePublic( x509Spec ) failed with java.security.InvalidKeyException In-Reply-To: <6893B8FE-5E45-4D48-ABF2-01A2DAEFB9C5@oracle.com> References: <73f67be4-9e09-00da-5a87-b2fa4f99bc91@oracle.com> <72eb4030-4a15-3683-fb37-b66e038b5c43@oracle.com> <6893B8FE-5E45-4D48-ABF2-01A2DAEFB9C5@oracle.com> Message-ID: It looks like I am suggesting you to rollback to the old "new RSAXyzKey(AlgorithmId,...)" style, only that the 1st argument is now an RsaId (child class extends AlgorithmId) that remembers the type and spec so you don't need to call RSAUtil methods to translate them back. I tried to implement this idea in RSAPublicKeyImpl but found it uncomfortable. Whenever I need that type and spec info from a key class, I'll have to cast algId to RsaId and this really smells bad. Or, I can add a "RsaId rsaId" field there but it's actually the same object as algId, and this is not better than your current webrev that simple store both type and spec into the class. So just ignore my suggestion. You current webrev is good. Thanks, Max > On Jun 1, 2020, at 11:26 AM, Weijun Wang wrote: > > The code change looks fine to me. > > One small comment: I notice that "KeyType type" and "AlgorithmParameterSpec keyParams" always go hand in hand, either as fields inside a class, or in the argument list of a method. Does it make sense to combine these 2 guys into a single class? It will look like a child class of AlgorithmId which understand what its alg and params mean. Of course you won't be able to make KeyType an enum anymore. > > All up to you. > > Thanks, > Max > > >> On May 30, 2020, at 5:07 AM, Valerie Peng wrote: >> >> Re-worked the fix a bit to take in Max's feedback: >> >> Webrev updated athttp://cr.openjdk.java.net/~valeriep/8242897/webrev.01/ >> >> Instead of completely reverting to the pre-PSS behavior of ignoring the OID in the DER encoding, this updated webrev has special handling to work with the scenario in the bug report. Most changes are code refactoring driven by the argument type change... >> >> Thanks, >> Valerie >> >> >> On 5/7/2020 4:17 PM, Valerie Peng wrote: >>> Ping? >>> >>> On 4/23/2020 3:28 PM, Valerie Peng wrote: >>>> 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 weijun.wang at oracle.com Mon Jun 1 07:35:32 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 1 Jun 2020 15:35:32 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <24F7645C-EBF8-4BD3-A547-32F0E00F132C@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> <74378A56-8536-4151-9B5D-257FBD5969EA@oracle.com> <253066b0-4a5f-4311-f3aa-4d6cd2393809@oracle.com> <24F7645C-EBF8-4BD3-A547-32F0E00F132C@oracle.com> Message-ID: Updated webrev at https://cr.openjdk.java.net/~weijun/8244565/webrev.03. I've inlined more methods that is only called once and inside the same method. Thanks, Max > On May 28, 2020, at 9:16 AM, Weijun Wang wrote: > > > >> On May 28, 2020, at 8:46 AM, Valerie Peng wrote: >> >> Hi Max, >> >> I like this new structure better. Much easier to understand. Most of the changes are technical debt that's accumulated inside PKCS8Key class. >> >> A few notable differences which I am not so sure about are >> >> - the encodedKey is returned by getEncoded() directly w/o cloning, and > > Too bad. I'll fix. > >> >> - the protected parseKeyBits() method being made private. I wonder if the parseKeyBits() method should be made abstract so it's more obvious that the subclasses needs to parse the key bytes into algorithm-specific components. > > Or how about I just inline parseKeyBits in those child classes into their constructors? I don't think the child class will forget it. Otherwise, why write a child class? > > Thanks, > Max > >> >> Thanks, >> Valerie >> On 5/26/2020 5:54 PM, Weijun Wang wrote: >>> Can you please take a look (not a review) at an updated webrev at http://cr.openjdk.java.net/~weijun/8244565/webrev.02/? It contains the code to inspect the extra fields. I haven't deal with the "..." here yet. >>> >>> However, when I tried to consolidate the DER parsing into one place, I've made more and more changes everywhere. The major change now is a base constructor PKCS8Key(byte[]) and subclass constructors that call it and no more protected parseKeyBits(). Although I don't think there is any technical error here but at the end of the day I'm asking myself if this is too much code change for such a simple bug. >>> >>> Do you like the overall structure? If yes, I'll continue this way. Otherwise, I can restrict the change only inside PKCS8Key. >>> >>> Thanks, >>> Max >>> >>> >>>> On May 27, 2020, at 7:14 AM, Valerie Peng wrote: >>>> >>>> I suppose we can allow trailing data to conform to "..." then. >>>> >>>> But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? >>>> >>>> Valerie >>>> >>>> On 5/25/2020 9:02 PM, Weijun Wang wrote: >>>>> The new definition at https://tools.ietf.org/html/rfc5958 shows, >>>>> >>>>> OneAsymmetricKey ::= SEQUENCE { >>>>> version Version, >>>>> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, >>>>> privateKey PrivateKey, >>>>> attributes [0] Attributes OPTIONAL, >>>>> ..., >>>>> [[2: publicKey [1] PublicKey OPTIONAL ]], >>>>> ... >>>>> } >>>>> >>>>> According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: >>>>> >>>>> The string "..." in ASN.1 is called an extension marker. The extension marker, >>>>> ellipsis, is an indication that extension additions are expected. It makes no >>>>> statement as to how such additions should be handled. However they shall not be >>>>> treated as an error during the decoding process. >>>>> >>>>> So there might be more fields in the future. Do you still insist we need more validation? >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> On May 20, 2020, at 1:37 PM, Valerie Peng wrote: >>>>>> >>>>>> >>>>>> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. >>>>>> >>>>>> Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> On 5/18/2020 9:36 PM, Weijun Wang wrote: >>>>>>>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>>>>>>> >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>>>>>>> >>>>>>>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>>>>>>> >>>>>>>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>>>>>>> throws IOException { >>>>>>>> boolean hasAttributes = false; >>>>>>>> boolean hasPublicKey = false; >>>>>>>> while (derIn.available () != 0) { >>>>>>>> // check for OPTIONAL attributes and/or publicKey >>>>>>>> DerValue tmp = derIn.getDerValue(); >>>>>>>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>>>>>>> // OPTIONAL attributes not supported yet >>>>>>>> // discard for now and move on >>>>>>>> hasAttributes = true; >>>>>>>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>>>>>>> !hasPublicKey) { >>>>>>>> // OPTIONAL v2 public key not supported yet >>>>>>>> // discard for now and move on >>>>>>>> hasPublicKey = true; >>>>>>>> } else { >>>>>>>> throw new IOException ("illegal encoding in private key"); >>>>>>>> } >>>>>>>> } >>>>>>>> } >>>>>>> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >>>>>>> >>>>>>>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >>>>>>> OK. >>>>>>> >>>>>>>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >>>>>>> Yes. >>>>>>> >>>>>>>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >>>>>>> If you still want checkTrailingBytes, then yes. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Valerie >>>>>>>> >>>>>>>> >>>>>>>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>>>>>>> I will take a look. >>>>>>>>> >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>>>>>>> Found an existing test I can update. Webrev updated at >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>>>>>>> >>>>>>>>>>> Please take a review at >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>>>>>>> >>>>>>>>>>> I also take this chance to make some format change. >>>>>>>>>>> >>>>>>>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>> > From simone.bordet at gmail.com Mon Jun 1 09:13:55 2020 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 1 Jun 2020 11:13:55 +0200 Subject: Alias internal format leaked to application code? Message-ID: Hi, when using "PKIX" as KeyManagerFactoryAlgorithm, the alias is manipulated from what's in the keystore (for example, "jetty") to an internal format such as "N.0.jetty", where N is an increasing number (in sun.security.ssl.X509KeyManagerImpl.makeAlias()). The problem is that (especially in case of SNI) the KeyManager could be wrapped by a user-written KeyManager that may delegate to the JDK one. When the user-written KeyManager delegates to the JDK instance by calling keyManager.getServerAliases(keyType, issuers), an array of aliases is returned, but the aliases are of the internal format described above. This makes the user-written code fail any logic that is based on the aliases, as comparing these internal formats with the ones present in the KeyStore will fail. Can you please clarify if this is expected behavior and whether user-written code should "unwrap" this internal alias format (is it defined somewhere?), or if this internal format is wrongly leaked to user-written code? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From Xuelei.Fan at Oracle.Com Mon Jun 1 15:22:52 2020 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Mon, 1 Jun 2020 08:22:52 -0700 Subject: Alias internal format leaked to application code? In-Reply-To: References: Message-ID: Good catch, Simone. It is not expected to parser the alias in application code. Would you like file a bug? Thanks, Xuelei > On Jun 1, 2020, at 2:13 AM, Simone Bordet wrote: > > Hi, > > when using "PKIX" as KeyManagerFactoryAlgorithm, the alias is > manipulated from what's in the keystore (for example, "jetty") to an > internal format such as "N.0.jetty", where N is an increasing number > (in sun.security.ssl.X509KeyManagerImpl.makeAlias()). > > The problem is that (especially in case of SNI) the KeyManager could > be wrapped by a user-written KeyManager that may delegate to the JDK > one. > > When the user-written KeyManager delegates to the JDK instance by > calling keyManager.getServerAliases(keyType, issuers), an array of > aliases is returned, but the aliases are of the internal format > described above. > > This makes the user-written code fail any logic that is based on the > aliases, as comparing these internal formats with the ones present in > the KeyStore will fail. > > Can you please clarify if this is expected behavior and whether > user-written code should "unwrap" this internal alias format (is it > defined somewhere?), or if this internal format is wrongly leaked to > user-written code? > > Thanks! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Jun 1 15:33:15 2020 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 1 Jun 2020 17:33:15 +0200 Subject: Alias internal format leaked to application code? In-Reply-To: References: Message-ID: Hi, On Mon, Jun 1, 2020 at 5:24 PM Xuelei Fan wrote: > > Good catch, Simone. It is not expected to parser the alias in application code. Would you like file a bug? https://bugs.openjdk.java.net/browse/JDK-8246262. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From hai-may.chao at oracle.com Mon Jun 1 18:37:04 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Mon, 1 Jun 2020 11:37:04 -0700 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options Message-ID: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> Hi, I?d like to request a review for: JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. Thanks, Hai-May From sean.mullan at oracle.com Mon Jun 1 19:19:22 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 1 Jun 2020 15:19:22 -0400 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: <1f29a11a-40de-2e56-7524-1323d0ed326d@oracle.com> <95519263-3ED3-4D80-AB30-80A86ECAA611@oracle.com> <6d2f9950-5306-b4a9-d62e-688bbac2f989@oracle.com> Message-ID: <56330a3b-6117-0e8d-8b52-bfd6348d4b1d@oracle.com> On 5/31/20 9:26 PM, Weijun Wang wrote: > Replies inline below. I've removed the items I agree with for simplicity. > >> On May 30, 2020, at 3:32 AM, Sean Mullan wrote: >> >> On 5/23/20 4:21 AM, Weijun Wang wrote: >>> CSR updated at https://bugs.openjdk.java.net/browse/JDK-8245274 with the full patch on docs. >> >> - Comments on the Specification section: >> >> Some of this wording where you discuss what is going to be done in jarsigner and the tool doc seems more like it belongs in the Solution section, but it may be ok either way (not sure, I guess Joe will let you know if it is an issue). >> >> +RSASSA-PSS \<= 3072 RSASSA-PSS using SHA-256 >> + \<= 7680 RSASSA-PSS using SHA-384 >> + \> 7680 RSASSA-PSS using SHA-512 >> >> It might be better to be more specific, for example "RSASSA-PSS with the SHA-256 message digest algorithm" I used the term "with" as that is the word we use in the standard signature algorithm strings. > > Can I simply say "RSASSA-PSS with SHA-256"? Otherwise the text is much longer than the other rows. That said, we have enough width and no need to wrap. How about "RSASSA-PSS (with SHA-256)" I think the parentheses helps. > Also, we used to say HASHwithENC, but here it's "ENC with HASH". Hopefully this will not make people laugh. > >> >> >> +for keysize \<= 3072 bits, use a `PSSParameterSpec` with SHA-256 as the hash >> >> s/use a `PSSParameterSpec`/a `PSSParameterSpec` will be used/ >> >> +and MGF1 algorithms; for keysize \<= 7680 bits, use SHA-384; for >> +keysize \>= 7680 bits, use SHA-512. >> >> s/use SHA-384/SHA-384 will be used/ >> s/use SHA-512/SHA-512 will be used/ > > My original text is > > Precisely, for keysize \<= 3072 bits, use a `PSSParameterSpec` with SHA-256 > as the hash and MGF1 algorithms; for keysize \<= 7680 bits, use SHA-384; for > keysize \>= 7680 bits, use SHA-512. > > So the object of "use" here is the PSSParameterSpec. If I change it to passive voice, it will be > > a `PSSParameterSpec` with SHA-256 as the hash and MGF1 algorithms will be used, > > and `PSSParameterSpec` (instead of SHA-256) will be the noun. The "SHA-384 will be used" in the next sentence might not be 100% grammatically correct in this sense but I think it's OK and nobody will misunderstand it. (In fact, there is the same problem in my original text). When you say "use a `PSSParameterSpec` with SHA-256" it sounds to me as you are telling the reader they need to take action to do that. But this is what jarsigner itself will be doing. Another option which I will throw out, is to change the RSASSA-PSS rows in the table above it to be more like the keytool table, so that it includes the keysize ranges, ex: +RSASSA-PSS \<= 3072 RSASSA-PSS (with SHA-256) + \<= 7680 RSASSA-PSS (with SHA-384) + \> 7680 RSASSA-PSS (with SHA-512) Then you could simplify the following text as something like: * If an RSASSA-PSS key is encoded with parameters, then the signature will use the same parameters. Otherwise, the signature will use parameters that are determined by the size of the key as specified in the table above. For example, an 3072-bit RSASSA-PSS key will use RSASSA-PSS as the signature algorithm and SHA-256 as the hash and MGF1 algorithms. I don't think you need to mention PSSParameterSpec at all. It seems like a detail that is more for an application developer and doesn't need to be detailed here. > > Thanks, > Max > > p.s. This is probably the only RFE I can add into jdk15 before rdp1 now. The strong p12 algorithms and new CACERTS keystore type won't be ready. I do have several bug fixes that can wait till rdp2. Yes, I hope there is still time. I have added my name as Reviewer, so you should submit the CSR soon. Also, I view all of my comments as wording changes/tweaks and not changes to the specification which is basically to add support for these algorithms to jarsigner. --Sean From weijun.wang at oracle.com Tue Jun 2 08:07:01 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 2 Jun 2020 16:07:01 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: Message-ID: <50C70B50-9B13-4098-B848-C68A68DC895A@oracle.com> Updated again at https://cr.openjdk.java.net/~weijun/8242068/webrev.02 Major changes this time: 1. Use Signed Attributes in generateNewSignedData(direct==false). This means for Ed448 we will use SHAKE256-LEN so there is no interop issue (BTW, BC recently added support to SHAKE256 in 166b07), hence removed the newly added system property in webrev.01. 2. Better interop with providers using Ed448 and Ed25519 as key algorithm names. Major changes previously: 1. Always encode the whole signature algorithm identifier (instead of encryption algorithmid) in PKCS7 SignerInfo. 2. New SignatureUtil methods Thanks, Max > On May 27, 2020, at 8:21 AM, Weijun Wang wrote: > > Webrev updated at > > http://cr.openjdk.java.net/~weijun/8242068/webrev.01/ > > Two major changes: > > 1. Always use the signature algorithm directly in SignerInfo::signatureAlgorithm: > > In PKCS7 SignerInfo > > SignerInfo ::= SEQUENCE { > version CMSVersion, > sid SignerIdentifier, > digestAlgorithm DigestAlgorithmIdentifier, > signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, > signatureAlgorithm SignatureAlgorithmIdentifier, > signature SignatureValue, > unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } > > We have always been putting "SHA-1" etc into DigestAlgorithmIdentifier, and "RSA", "DSA", "EC" into signatureAlgorithm. > > The latest https://tools.ietf.org/html/rfc5652#section-10.1.2 claims it to be > > The SignatureAlgorithmIdentifier type identifies a signature > algorithm, and it can also identify a message digest algorithm. > Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with > SHA-256. > > It's complicated to always divide a signature algorithm into a digest algorithm and an encryption algorithm (and with the new RSASSA-PSS and EdDSA it's not easy to define it), therefore I decide to use the signature algorithm directly from now on. Fortunately Java has been able to parse this for a very long time so there is no compatibility issue. I noticed BouncyCastle has been doing the same, and OpenSSL too except for RSA. > > 2. Support both SHAKE256 and SHAKE256-LEN while parsing a Ed448 SignerInfo. They are both described in https://www.rfc-editor.org/rfc/rfc8419.html although it's a little complicated. To be standard compliant (https://www.rfc-editor.org/rfc/rfc8419.html#section-3.2 and we don't use Signed Attributes), by default Java will use SHAKE256 as the digestAlgorithm. However I noticed BouncyCastle does not recognize it, so if you set the system property "jdk.security.pkcs7.ed448.digalg.haslen" to "true", it will use SHAKE256-LEN (len == 512). I haven't described this system property in the CSR yet. > > Thanks, > Max > > >> On May 22, 2020, at 10:30 PM, Weijun Wang wrote: >> >> Please take a review at >> >> CSR : https://bugs.openjdk.java.net/browse/JDK-8245274 >> webrev : http://cr.openjdk.java.net/~weijun/8242068/webrev.00/ >> >> Major points in CSR: >> >> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner >> >> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms >> >> major code changes: >> >> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java >> >> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId >> >> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing >> >> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms >> >> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed >> >> Next I'll do some basic interop tests with openssl and BouncyCastle. >> >> Thanks, >> Max >> > From sha.jiang at oracle.com Tue Jun 2 14:05:49 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 2 Jun 2020 22:05:49 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> Message-ID: After discussed with Max, I just updated the patch, http://cr.openjdk.java.net/~jjiang/8244683/webrev.04/ Interface TsaInterceptor is renamed to RespInterceptor. The methods, which affect TSA response fields, are merged into getRespParam(reqParam). Best regards, John Jiang On 2020/5/13 08:18, sha.jiang at oracle.com wrote: > Hi Max, > Thanks for your comments! > Please review the updated webrev: > http://cr.openjdk.java.net/~jjiang/8244683/webrev.02/ > The codes are refactored significantly. > > On 2020/5/11 10:51, Weijun Wang wrote: >> Can you update the existing TimeStampCheck test to use this class? I >> know that test can simulate some error conditions. Maybe you can add >> one or more virtual methods in this class so? TimeStampCheck can >> override them. > This test is updated to use this TSA server. > A new introduced class, namely TsaInterceptor, defines some extension > points for the signing. > >> getDefaultSigAlgo(): Please call AlgorithmId.getDefaultSigAlgForKey() >> instead. It will be enhanced to support new algorithm. > Fixed. > >> Param: How about making it a JDK 14 record? > In the updated webrev, this class has changed to TsaParam. > The fields are not final, and especially this class could be extended > by tests. > With my understanding, this language feature may not be applicable for > this scenario . > > Best regards, > John Jiang >> Thanks, >> Max >> >>> On May 11, 2020, at 9:28 AM,sha.jiang at oracle.com? wrote: >>> >>> Hi, >>> This patch introduces a TSA server, which can work with jarsigner. >>> This server will be used by the following jar signing tests. >>> >>> Issue:https://bugs.openjdk.java.net/browse/JDK-8244683 >>> Webrev:http://cr.openjdk.java.net/~jjiang/8244683/webrev.00/ >>> >>> Best regards, >>> John Jiang >>> From sean.mullan at oracle.com Tue Jun 2 17:22:23 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 2 Jun 2020 13:22:23 -0400 Subject: [RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported In-Reply-To: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> References: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> Message-ID: On 5/27/20 4:22 PM, Anthony Scarpino wrote: > Hi, > > I need a javadoc review for a Signature/SignatureSpi parameters change > that is needed to the spec, which affects EdDSA.? The existing spec was > very strict in the way set and get parameters were handled.? This > modifies that slightly by allowing null to be returned by the get > methods when it is unsupported after the parameters have been set. Since > null was an allowed return value, this minimizes the backwards > compatibility chances. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8243425 > webrev: https://cr.openjdk.java.net/~ascarpino/8243424/webrev/ Here are a few wording/formatting comments on Signature. The same comments apply to SignatureSpi since it contains similar text. 1015 * (by calling the {@code setParameter} method) and the underlying You should distinguish between the two overloaded setParameter methods so it is clear which one you are talking about. I recommend using @link instead of @code: {@link #setParameter(AlgorithmParameterSpec)} 1016 * implementation supports returning the parameters as AlgorithmParameters, I would say "underlying signature implementation" to be consistent with the previous text. Also, change "AlgorithmParameters" (the one above and below) to "{@code AlgorithmParameters}". 1017 * this method returns the same parameters. If parameters are set using 1018 * {@code setParameter}, this method may return those parameters Use "{@link #setParameter(String, Object)}" instead of "{@code setParameter}" 1019 * from the provider as AlgorithmParameters, if supported. The first two sentences are very similar. How about combining them as: "If this signature has been previously initialized with parameters (by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link #setParameter(String, Object)}) and the underlying signature implementation supports returning the parameters as {@code AlgorithmParameters}, this method returns the same parameters." 1020 * parameters were not set, this method may return a combination 1021 * of default and randomly generated parameter values if the 1022 * underlying signature implementation supports it and can successfully 1023 * generate them. Otherwise, {@code null} is returned. --Sean From John.Gray at entrustdatacard.com Tue Jun 2 20:18:10 2020 From: John.Gray at entrustdatacard.com (John Gray) Date: Tue, 2 Jun 2020 20:18:10 +0000 Subject: NullPointer in JceSecurity.getVerificationResult - Affects JDK 11.07, and JDK 12 and later. Message-ID: Hello, At Entrust Datacard, we produce a Java based toolkit that contains our own Security Provider. This toolkit and provider has been around for about 19 years. In JDK version 11.07 (and I also think Java 12 and beyond), our toolkit reports the following error: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: X9_31usingAES256, provider: Entrust, class: com.entrust.toolkit.security.crypto.random.X9_31usingAES256) at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:281) at java.base/java.security.SecureRandom.(SecureRandom.java:219) at java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) ... 41 more Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: X9_31usingAES256, provider: Entrust, class: com.entrust.toolkit.security.crypto.random.X9_31usingAES256) at java.base/java.security.Provider$Service.newInstance(Provider.java:1825) at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at java.base/java.security.SecureRandom.getInstance(SecureRandom.java:365) at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:273) ... 43 more Caused by: java.lang.NullPointerException at java.base/javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:203) at java.base/javax.crypto.Cipher.getInstance(Cipher.java:690) at java.base/javax.crypto.Cipher.getInstance(Cipher.java:625) at com.entrust.toolkit.security.crypto.random.X9_31usingAES256.initialize(X9_31usingAES256.java:524) at com.entrust.toolkit.security.crypto.random.X9_31usingAES256.(X9_31usingAES256.java:102) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.security.Provider.newInstanceUtil(Provider.java:176) at java.base/java.security.Provider$Service.newInstance(Provider.java:1818) I investigated this error, and found it was made possible because of the following change in Java 11.07 which unmasked a bug in the JVM that has probably been around for years. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8228613 It is a problem inside the JceSecurity class. When the class is being loaded, the call to setup a default SecureRandom() instance is invoked. That seems to invoke the JVM to find the first available SecureRandom() instance. This error happens when our Entrust provider is in first position. In previous versions of the JDK it honoured the order of algorithms specified in the providers. In our Entrust Security provider, we have a number of SecureRandom implementations. Now because of the above change, it picks a different SecureRandom instance (the X9_31usingAES256). That should be fine, however the problem is that the SecureRandom() setup calls Cipher.getInstance() and as you can see below, that calls JceSecurity.getVerificationResult() which is static, and uses the verificationResuts Map that has not yet been initialized (becasuse it's declaration is after the SecureRandom setup). That is why there is a NullPointerException. public static final Cipher getInstance(String transformation, Provider provider) throws NoSuchAlgorithmException, NoSuchPaddingException { if ((transformation == null) || transformation.equals("")) { throw new NoSuchAlgorithmException("Null or empty transformation"); } if (provider == null) { throw new IllegalArgumentException("Missing provider"); } Exception failure = null; List transforms = getTransforms(transformation); boolean providerChecked = false; String paddingError = null; for (Transform tr : transforms) { Service s = provider.getService("Cipher", tr.transform); if (s == null) { continue; } if (providerChecked == false) { // for compatibility, first do the lookup and then verify // the provider. this makes the difference between a NSAE // and a SecurityException if the // provider does not support the algorithm. Exception ve = JceSecurity.getVerificationResult(provider); if (ve != null) { String msg = "JCE cannot authenticate the provider " + provider.getName(); throw new SecurityException(msg, ve); } providerChecked = true; } The JceSecurity.getVerificationResult(provider) method is used when initializing the SecureRandom (first highlighted line below) when the classLoader is loading the JceSecurity class itself. >From the JceSecurity class: static final SecureRandom RANDOM = new SecureRandom(); // The defaultPolicy and exemptPolicy will be set up // in the static initializer. private static CryptoPermissions defaultPolicy = null; private static CryptoPermissions exemptPolicy = null; // Map of the providers we already have verified // value == PROVIDER_VERIFIED is successfully verified // value is failure cause Exception in error case private static final Map verificationResults = new IdentityHashMap<>(); It fails when it calls the following code in JceSecurity.java because the verificationResults Map has not been initialized because the SecureRandom() constructor ends up calling the JceSecurity.getVerificationResult() static method that makes use of the Map! That explains the NullPointerException. The fix to the issue should be simple, just move the initialization of the verificationResults Map BEFORE the SecureRandom initialization in JceSecurity.java Because verificationResults is not initialized, the line highlighted below fails (Because the Map has not been initialized). /* * Verify that the provider JAR files are signed properly, which * means the signer's certificate can be traced back to a * JCE trusted CA. * Return null if ok, failure Exception if verification failed. */ static synchronized Exception getVerificationResult(Provider p) { Object o = verificationResults.get(p); if (o == PROVIDER_VERIFIED) { return null; } else if (o != null) { return (Exception)o; } if (verifyingProviders.get(p) != null) { // this method is static synchronized, must be recursion // return failure now but do not save the result return new NoSuchProviderException("Recursion during verification"); } try { verifyingProviders.put(p, Boolean.FALSE); URL providerURL = getCodeBase(p.getClass()); verifyProvider(providerURL, p); // Verified ok, cache result verificationResults.put(p, PROVIDER_VERIFIED); return null; } catch (Exception e) { verificationResults.put(p, e); return e; } finally { verifyingProviders.remove(p); } } Cheers, John Gray -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue Jun 2 22:33:57 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 2 Jun 2020 15:33:57 -0700 Subject: [RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported In-Reply-To: References: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> Message-ID: On 6/2/20 10:22 AM, Sean Mullan wrote: > On 5/27/20 4:22 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a javadoc review for a Signature/SignatureSpi parameters change >> that is needed to the spec, which affects EdDSA.? The existing spec >> was very strict in the way set and get parameters were handled.? This >> modifies that slightly by allowing null to be returned by the get >> methods when it is unsupported after the parameters have been set. >> Since null was an allowed return value, this minimizes the backwards >> compatibility chances. >> >> CSR: https://bugs.openjdk.java.net/browse/JDK-8243425 >> webrev: https://cr.openjdk.java.net/~ascarpino/8243424/webrev/ > > Here are a few wording/formatting comments on Signature. The same > comments apply to SignatureSpi since it contains similar text. > > 1015????? * (by calling the {@code setParameter} method) and the underlying > > You should distinguish between the two overloaded setParameter methods > so it is clear which one you are talking about. I recommend using @link > instead of @code: {@link #setParameter(AlgorithmParameterSpec)} > > 1016????? * implementation supports returning the parameters as > AlgorithmParameters, > > I would say "underlying signature implementation" to be consistent with > the previous text. > > Also, change "AlgorithmParameters" (the one above and below) to "{@code > AlgorithmParameters}". > > 1017????? * this method returns the same parameters.? If parameters are > set using > 1018????? * {@code setParameter}, this method may return those parameters > > Use "{@link #setParameter(String, Object)}" instead of "{@code > setParameter}" > > 1019????? * from the provider as AlgorithmParameters, if supported. > > The first two sentences are very similar. How about combining them as: > > "If this signature has been previously initialized with parameters > (by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link > #setParameter(String, Object)}) and the underlying signature > implementation supports returning the parameters as {@code > AlgorithmParameters}, this method returns the same parameters." If we are going to reexamine this, then I would say "previously initialized" is the wrong wording. it makes it sound like it only applies when the signature is reset(). It should be replaced with "set", regardless if it is the first op or a reset op. Tony > > > 1020????? * parameters were not set, this method may return a combination > 1021????? * of default and randomly generated parameter values if the > 1022????? * underlying signature implementation supports it and can > successfully > 1023????? * generate them. Otherwise, {@code null} is returned. > > --Sean From valerie.peng at oracle.com Tue Jun 2 22:44:41 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 2 Jun 2020 15:44:41 -0700 Subject: [15] RFR JDK-8242897 KeyFactory.generatePublic( x509Spec ) failed with java.security.InvalidKeyException In-Reply-To: References: <73f67be4-9e09-00da-5a87-b2fa4f99bc91@oracle.com> <72eb4030-4a15-3683-fb37-b66e038b5c43@oracle.com> <6893B8FE-5E45-4D48-ABF2-01A2DAEFB9C5@oracle.com> Message-ID: <81aa6d92-2a2c-6f9b-5d4b-a8d0e2370a9d@oracle.com> Sure, thanks for the detailed review~ Valerie On 5/31/2020 9:45 PM, Weijun Wang wrote: > It looks like I am suggesting you to rollback to the old "new RSAXyzKey(AlgorithmId,...)" style, only that the 1st argument is now an RsaId (child class extends AlgorithmId) that remembers the type and spec so you don't need to call RSAUtil methods to translate them back. > > I tried to implement this idea in RSAPublicKeyImpl but found it uncomfortable. Whenever I need that type and spec info from a key class, I'll have to cast algId to RsaId and this really smells bad. Or, I can add a "RsaId rsaId" field there but it's actually the same object as algId, and this is not better than your current webrev that simple store both type and spec into the class. > > So just ignore my suggestion. You current webrev is good. > > Thanks, > Max > >> On Jun 1, 2020, at 11:26 AM, Weijun Wang wrote: >> >> The code change looks fine to me. >> >> One small comment: I notice that "KeyType type" and "AlgorithmParameterSpec keyParams" always go hand in hand, either as fields inside a class, or in the argument list of a method. Does it make sense to combine these 2 guys into a single class? It will look like a child class of AlgorithmId which understand what its alg and params mean. Of course you won't be able to make KeyType an enum anymore. >> >> All up to you. >> >> Thanks, >> Max >> >> >>> On May 30, 2020, at 5:07 AM, Valerie Peng wrote: >>> >>> Re-worked the fix a bit to take in Max's feedback: >>> >>> Webrev updated athttp://cr.openjdk.java.net/~valeriep/8242897/webrev.01/ >>> >>> Instead of completely reverting to the pre-PSS behavior of ignoring the OID in the DER encoding, this updated webrev has special handling to work with the scenario in the bug report. Most changes are code refactoring driven by the argument type change... >>> >>> Thanks, >>> Valerie >>> >>> >>> On 5/7/2020 4:17 PM, Valerie Peng wrote: >>>> Ping? >>>> >>>> On 4/23/2020 3:28 PM, Valerie Peng wrote: >>>>> 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 Tue Jun 2 23:37:04 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 2 Jun 2020 16:37:04 -0700 Subject: NullPointer in JceSecurity.getVerificationResult - Affects JDK 11.07, and JDK 12 and later. In-Reply-To: References: Message-ID: <651b2416-4764-d460-e3f9-56ef073a5c35@oracle.com> Thanks for reporting the bug and the detailed analysis. I have filed https://bugs.openjdk.java.net/browse/JDK-8246383 to keep track of this. Will aim to fix this for 15 and have it backported accordingly. Is it possible to get hold of an test provider to reproduce and verifying the fix? Regards, Valerie On 6/2/2020 1:18 PM, John Gray wrote: > > Hello, > > At Entrust Datacard, we produce a Java based toolkit that contains our > own Security Provider.?? This toolkit and provider ?has been around > for about 19 years. > > In JDK version 11.07 (and I also think Java 12 and beyond), our > toolkit reports the following error: > > java.lang.RuntimeException: java.security.NoSuchAlgorithmException: > Error constructing implementation (algorithm: X9_31usingAES256, > provider: Entrust, class: > com.entrust.toolkit.security.crypto.random.X9_31usingAES256) > at > java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:281) > at java.base/java.security.SecureRandom.(SecureRandom.java:219) > at java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) > ... 41 more > Caused by: java.security.NoSuchAlgorithmException: Error constructing > implementation (algorithm: X9_31usingAES256, provider: Entrust, class: > com.entrust.toolkit.security.crypto.random.X9_31usingAES256) > at > java.base/java.security.Provider$Service.newInstance(Provider.java:1825) > at > java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236) > at > java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164) > at java.base/java.security.SecureRandom.getInstance(SecureRandom.java:365) > at > java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:273) > ... 43 more > Caused by: java.lang.NullPointerException > at > java.base/javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:203) > at java.base/javax.crypto.Cipher.getInstance(Cipher.java:690) > at java.base/javax.crypto.Cipher.getInstance(Cipher.java:625) > at > com.entrust.toolkit.security.crypto.random.X9_31usingAES256.initialize(X9_31usingAES256.java:524) > at > com.entrust.toolkit.security.crypto.random.X9_31usingAES256.(X9_31usingAES256.java:102) > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at java.base/java.security.Provider.newInstanceUtil(Provider.java:176) > at > java.base/java.security.Provider$Service.newInstance(Provider.java:1818) > > I investigated this error, and found it was made possible because of > the following change in Java 11.07 which unmasked a bug in the JVM > that has probably been around for years. > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8228613 > > It is a problem inside the JceSecurity class.? When the class is being > loaded, the call to setup a default SecureRandom() instance is > invoked.?? ?That seems to invoke the JVM to find the first available > SecureRandom() instance.? ??This error happens when our Entrust > provider is in first position.?? In previous versions of the JDK it > honoured the order of algorithms specified in the providers. In our > Entrust Security provider, we have a number of SecureRandom > implementations.?? Now because of the above change, it picks a > different SecureRandom instance (the X9_31usingAES256).?? That should > be fine, however the problem is that the SecureRandom() setup calls > Cipher.getInstance() and as you can see below, that calls > JceSecurity.getVerificationResult() which is static, and uses the > verificationResuts Map that has not yet been initialized (becasuse > it?s declaration is after the SecureRandom setup).??? That is why > there is a NullPointerException. > > *public**static**final*Cipher getInstance(String transformation, > > Provider provider) > > *throws*NoSuchAlgorithmException, NoSuchPaddingException > > ??? { > > *if*((transformation == *null*) || transformation.equals("")) { > > *throw**new*NoSuchAlgorithmException("Null or empty transformation"); > > ??????? } > > *if*(provider == *null*) { > > *throw**new*IllegalArgumentException("Missing provider"); > > ??????? } > > ??????? Exception failure = *null*; > > ??????? List transforms = getTransforms(transformation); > > *boolean*providerChecked = *false*; > > ??????? String paddingError = *null*; > > *for*(Transform tr : transforms) { > > ??????????? Service s = provider.getService("Cipher", tr.transform); > > *if*(s == *null*) { > > *continue*; > > ??????????? } > > *if*(providerChecked == *false*) { > > // for compatibility, first do the lookup and then verify > > // the provider. this makes the difference between a NSAE > > // and a SecurityException if the > > // provider does not support the algorithm. > > Exception ve = JceSecurity.getVerificationResult(provider); > > *if*(ve != *null*) { > > ??????????????????? String msg = "JCE cannot authenticate the provider " > > ??????????????????????? + provider.getName(); > > *throw**new*SecurityException(msg, ve); > > ??????????????? } > > ??????????????? providerChecked = *true*; > > ??????????? } > > The JceSecurity.getVerificationResult(provider) method is used when > initializing the SecureRandom (first highlighted line below) when the > classLoader is loading the JceSecurity class itself. > > From the JceSecurity class: > > *static**final*SecureRandom RANDOM = *new*SecureRandom(); > > // The defaultPolicy and exemptPolicy will be set up > > // in the static initializer. > > *private**static*CryptoPermissions defaultPolicy = *null*; > > *private**static*CryptoPermissions exemptPolicy = *null*; > > // Map of the providers we already have verified > > // value == PROVIDER_VERIFIED is successfully verified > > // value is failure cause Exception in error case > > *private**static**final*Map verificationResults = > > *new*IdentityHashMap<>(); > > It fails when it calls the following code in JceSecurity.java because > the verificationResults Map has not been initialized > because the SecureRandom() constructor ends up calling the > JceSecurity.getVerificationResult() static method that makes use of > the Map!? That explains the NullPointerException. > > The fix to the issue should be simple, just move the initialization of > the verificationResults Map BEFORE the SecureRandom initialization in > JceSecurity.java > > Because verificationResults is not initialized, the line highlighted > below fails (Because the Map has not been initialized). > > /* > > ???? * Verify that the provider JAR files are signed properly, which > > ???? * means the signer's certificate can be traced back to a > > ???? * JCE trusted CA. > > ???? * Return null if ok, failure Exception if verification failed. > > ???? */ > > *static**synchronized*Exception getVerificationResult(Provider p) { > > Object o = verificationResults.get(p); > > *if*(o == PROVIDER_VERIFIED) { > > *return**null*; > > ??????? } *else**if*(o != *null*) { > > *return*(Exception)o; > > ??????? } > > *if*(verifyingProviders.get(p) != *null*) { > > // this method is static synchronized, must be recursion > > // return failure now but do not save the result > > *return**new*NoSuchProviderException("Recursion during verification"); > > ????? ??} > > *try*{ > > ??????????? verifyingProviders.put(p, Boolean.FALSE); > > ??????????? URL providerURL = getCodeBase(p.getClass()); > > verifyProvider(providerURL, p); > > // Verified ok, cache result > > verificationResults.put(p, PROVIDER_VERIFIED); > > *return**null*; > > ??????? } *catch*(Exception e) { > > verificationResults.put(p, e); > > *return*e; > > ??????? } *finally*{ > > verifyingProviders.remove(p); > > ??????? } > > ??? } > > Cheers, > > John Gray > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jun 3 06:06:36 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Jun 2020 16:06:36 +1000 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <2442a046-6640-f759-6330-e971405f0c78@oracle.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> Message-ID: <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> Hi Simon, On 23/05/2020 12:04 am, Sean Mullan wrote: > Cross-posting to hotspot-dev for additional review since the code > changes are in hotspot. > > --Sean > > On 5/21/20 1:24 PM, Simon Tooke wrote: >> Hello, >> >> I'd like to request a review for: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 >> >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/00/00/ >> >> This change implements the given intrinsics on Windows. >> >> The Windows toolchain has no 128 bit integer types, and no inline asm >> (on x64 and Arm).? In addition, 'long' is 4 bytes, not 8, as it is >> with gcc.? This patch had to change some of the linux implementation >> to account for these limitations. I can't really comment on the intrinsics themselves but a couple of suggestions: - use explicitly sized types e.g. uint64_t instead of unsigned long long - use the existing NOINLINE macro for the _declspec(noinline) The conditional compilation in this code has me quite confused. Looking at the existing code we have: 3680 #ifndef _WINDOWS 3681 3682 #define ASM_SUBTRACT 3683 3684 #ifdef ASM_SUBTRACT ... 3702 #else // ASM_SUBTRACT ... 3719 #endif // ! ASM_SUBTRACT So all the above code is only built on not-Windows, and we unconditionally define ASM_SUBTRACT, so lines 3702 to 3719 appear to be dead code! I'm not at all sure whether that is actually a bug and the windows ifndef should have had an endif after line 3682; or whether we can just simplify the code. Thanks, David >> >> My gratitude for Andrew Haley for doing the heavy lifting at the core >> of this patch. >> >> The patch, if accepted, will be offered to 11u as a potential >> backport. The changes apply cleanly modulo some line number changes. >> >> As for the speedup, this test case: >> >> BigInteger base = BigInteger.ONE.shiftLeft(1024); >> long count = LongStream.rangeClosed(2, 100_000) >> ???? .mapToObj(n -> BigInteger.valueOf(n).add(base)) >> ???? .filter(i -> i.isProbablePrime(50)) >> ???? .count(); >> >> goes from 1 minute 20 seconds down to about 35 seconds om my VM, over >> multiple runs.? As is the case on other platforms where the intrinsics >> are supported, they will be enabled by default on Windows. >> >> Thank you for your time, >> >> -Simon Tooke >> >> >> Principle Software Engineer, >> >> Red Hat Canada >> >> >> From weijun.wang at oracle.com Wed Jun 3 06:27:37 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jun 2020 14:27:37 +0800 Subject: RFR 8246397: Use KnownOIDs for known OIDs Message-ID: <208AA8E7-E3A9-4936-9A84-A7C002043D9C@oracle.com> Please review the code change at http://cr.openjdk.java.net/~weijun/8246397/webrev.00/ The following KnownOIDs lines are related, in case you want to compare the values. 59: SubjectKeyID("2.5.29.14"), 60: KeyUsage("2.5.29.15"), 61: PrivateKeyUsage("2.5.29.16"), 62: SubjectAlternativeName("2.5.29.17"), 65: CRLNumber("2.5.29.20"), 68: InvalidityDate("2.5.29.24"), 72: NameConstraints("2.5.29.30"), 74: CertificatePolicies("2.5.29.32"), 75: CE_CERT_POLICIES_ANY("2.5.29.32.0"), 77: AuthorityKeyID("2.5.29.35"), 79: extendedKeyUsage("2.5.29.37"), 372: X25519("1.3.101.110"), 373: X448("1.3.101.111"), Noreg-cleanup. Thanks, Max From weijun.wang at oracle.com Wed Jun 3 07:59:32 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jun 2020 15:59:32 +0800 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> Message-ID: The source change looks fine to me. In TrustedCert.java: - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). - There is no need to recreate root.jks and root.pem. - Why not use -trustcacerts below? 160 kt("-importcert -file server.pem -noprompt", "server.jks"); - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. In TrustedCRL.java: - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. Thanks, Max > On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: > > Hi, > > I?d like to request a review for: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 > CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 > Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ > > The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. > > Thanks, > Hai-May > From weijun.wang at oracle.com Wed Jun 3 09:17:49 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jun 2020 17:17:49 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> Message-ID: <02591481-F24B-49F6-96D0-35EC2EFB4ADC@oracle.com> TimeStampCheck.java: - Can you please inline all those private getXyz() calls in Interceptor into getRespParam()? I would like to see all these customizations in one place. Just add a blank line in between and it will be clean enough for me. TsaParam.java: - Please group the fields into different area. Looks like some are fields in TSTInfo, and some are server internals. The overall design is good, but I have a feeling that the interface and implementation can be further separated. I can see that there are a lot of methods and classes that will not be touched by TimeStampCheck at all. Should these things be taken out to be another implementation which is parallel to the one in TimeStampCheck? Maybe TsaHandler::createSigner will be abstract. There are quite some public constructors in the classes. Are they meant to be called by a user? Or by a child class? Or just internal? Also, for those protected methods (Ex: parseRequestParam and createResponse in TsaSigner), do you meant to override it in the future? Can you give examples on how to use this server? Will it always use DefaultRespInterceptor? If so, will the default impl in RespInterceptor.java ever be used? Thanks, Max > On Jun 2, 2020, at 10:05 PM, sha.jiang at oracle.com wrote: > > After discussed with Max, I just updated the patch, > http://cr.openjdk.java.net/~jjiang/8244683/webrev.04/ > > Interface TsaInterceptor is renamed to RespInterceptor. The methods, which > affect TSA response fields, are merged into getRespParam(reqParam). > > Best regards, > John Jiang > > On 2020/5/13 08:18, sha.jiang at oracle.com wrote: >> Hi Max, >> Thanks for your comments! >> Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8244683/webrev.02/ >> The codes are refactored significantly. >> >> On 2020/5/11 10:51, Weijun Wang wrote: >>> Can you update the existing TimeStampCheck test to use this class? I know that test can simulate some error conditions. Maybe you can add one or more virtual methods in this class so TimeStampCheck can override them. >> This test is updated to use this TSA server. >> A new introduced class, namely TsaInterceptor, defines some extension points for the signing. >> >>> getDefaultSigAlgo(): Please call AlgorithmId.getDefaultSigAlgForKey() instead. It will be enhanced to support new algorithm. >> Fixed. >> >>> Param: How about making it a JDK 14 record? >> In the updated webrev, this class has changed to TsaParam. >> The fields are not final, and especially this class could be extended by tests. >> With my understanding, this language feature may not be applicable for this scenario . >> >> Best regards, >> John Jiang >>> Thanks, >>> Max >>> >>>> On May 11, 2020, at 9:28 AM,sha.jiang at oracle.com wrote: >>>> >>>> Hi, >>>> This patch introduces a TSA server, which can work with jarsigner. >>>> This server will be used by the following jar signing tests. >>>> >>>> Issue:https://bugs.openjdk.java.net/browse/JDK-8244683 >>>> Webrev:http://cr.openjdk.java.net/~jjiang/8244683/webrev.00/ >>>> >>>> Best regards, >>>> John Jiang >>>> From xuelei.fan at oracle.com Wed Jun 3 14:10:41 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 3 Jun 2020 07:10:41 -0700 Subject: RFR 8246397: Use KnownOIDs for known OIDs In-Reply-To: <208AA8E7-E3A9-4936-9A84-A7C002043D9C@oracle.com> References: <208AA8E7-E3A9-4936-9A84-A7C002043D9C@oracle.com> Message-ID: It looks good to me. BTW, I may declare KnownOIDs.oid as final and use it directly, rather than use the value() method. Xuelei On 6/2/2020 11:27 PM, Weijun Wang wrote: > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8246397/webrev.00/ > > The following KnownOIDs lines are related, in case you want to compare the values. > > 59: SubjectKeyID("2.5.29.14"), > 60: KeyUsage("2.5.29.15"), > 61: PrivateKeyUsage("2.5.29.16"), > 62: SubjectAlternativeName("2.5.29.17"), > 65: CRLNumber("2.5.29.20"), > 68: InvalidityDate("2.5.29.24"), > 72: NameConstraints("2.5.29.30"), > 74: CertificatePolicies("2.5.29.32"), > 75: CE_CERT_POLICIES_ANY("2.5.29.32.0"), > 77: AuthorityKeyID("2.5.29.35"), > 79: extendedKeyUsage("2.5.29.37"), > 372: X25519("1.3.101.110"), > 373: X448("1.3.101.111"), > > Noreg-cleanup. > > Thanks, > Max > From sha.jiang at oracle.com Wed Jun 3 14:14:48 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 3 Jun 2020 22:14:48 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: <02591481-F24B-49F6-96D0-35EC2EFB4ADC@oracle.com> References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> <02591481-F24B-49F6-96D0-35EC2EFB4ADC@oracle.com> Message-ID: Hi Max, On 2020/6/3 17:17, Weijun Wang wrote: > TimeStampCheck.java: > > - Can you please inline all those private getXyz() calls in Interceptor into getRespParam()? I would like to see all these customizations in one place. Just add a blank line in between and it will be clean enough for me. OK > > TsaParam.java: > > - Please group the fields into different area. Looks like some are fields in TSTInfo, and some are server internals. One usage of this class is carrying all parameters delivered by HTTP request. Do you mean they should be grouped in different classes? > > The overall design is good, but I have a feeling that the interface and implementation can be further separated. I can see that there are a lot of methods and classes that will not be touched by TimeStampCheck at all. Should these things be taken out to be another implementation which is parallel to the one in TimeStampCheck? Maybe TsaHandler::createSigner will be abstract. All RespInterceptor methods are used by TimeStampCheck. DefaultRespInterceptor is used by standalone TSA server. In this style, no more RespInterceptor implementation is needed. > > There are quite some public constructors in the classes. Are they meant to be called by a user? Or by a child class? Or just internal? The public constructors in TsaServer can be called by applications for making standalone servers. > > Also, for those protected methods (Ex: parseRequestParam and createResponse in TsaSigner), do you meant to override it in the future? Possibly. For example, a sub parseRequestParam() may need to parse extensions from request. A test may directly twist the byte[] returned by createResponse(), or even an overridden createResponse() just returns an empty byte[]. > > Can you give examples on how to use this server? Will it always use DefaultRespInterceptor? If so, will the default impl in RespInterceptor.java ever be used? I'll use this server as standalone-like service. The custom TSA fields just be delivered by HTTP request query string. I won't provide a custom RespInterceptor, and DefaultRespInterceptor is enough to me. Best regards, John Jiang From weijun.wang at oracle.com Wed Jun 3 14:57:30 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jun 2020 22:57:30 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> <02591481-F24B-49F6-96D0-35EC2EFB4ADC@oracle.com> Message-ID: > On Jun 3, 2020, at 10:14 PM, sha.jiang at oracle.com wrote: > > Hi Max, > > On 2020/6/3 17:17, Weijun Wang wrote: >> TimeStampCheck.java: >> >> - Can you please inline all those private getXyz() calls in Interceptor into getRespParam()? I would like to see all these customizations in one place. Just add a blank line in between and it will be clean enough for me. > OK > >> >> TsaParam.java: >> >> - Please group the fields into different area. Looks like some are fields in TSTInfo, and some are server internals. > One usage of this class is carrying all parameters delivered by HTTP > request. Do you mean they should be grouped in different classes? No. Just add some comment lines inside the class and separate them into different groups. > >> >> The overall design is good, but I have a feeling that the interface and implementation can be further separated. I can see that there are a lot of methods and classes that will not be touched by TimeStampCheck at all. Should these things be taken out to be another implementation which is parallel to the one in TimeStampCheck? Maybe TsaHandler::createSigner will be abstract. > All RespInterceptor methods are used by TimeStampCheck. > DefaultRespInterceptor is used by standalone TSA server. In this style, no > more RespInterceptor implementation is needed. See below. > >> >> There are quite some public constructors in the classes. Are they meant to be called by a user? Or by a child class? Or just internal? > The public constructors in TsaServer can be called by applications for > making standalone servers. How about the other classes? > >> >> Also, for those protected methods (Ex: parseRequestParam and createResponse in TsaSigner), do you meant to override it in the future? > Possibly. > For example, a sub parseRequestParam() may need to parse extensions from > request. A test may directly twist the byte[] returned by createResponse(), > or even an overridden createResponse() just returns an empty byte[]. Can we make them internal at the moment until someone really need to extend it? > >> >> Can you give examples on how to use this server? Will it always use DefaultRespInterceptor? If so, will the default impl in RespInterceptor.java ever be used? > I'll use this server as standalone-like service. The custom TSA fields > just be delivered by HTTP request query string. I won't provide a custom > RespInterceptor, and DefaultRespInterceptor is enough to me. You can put DefaultRespInterceptor in the standalone server. If you change TsaSigner.java 80 public TsaSigner(SignerEntry signerEntry, byte[] requestData, 81 TsaParam param) { 82 this(signerEntry, requestData, 83 new DefaultRespInterceptor(param)); to use the even more "default" RespInterceptor, i.e. new RespInterceptor(){}, is it still useable? Thanks, Max > > Best regards, > John Jiang > From weijun.wang at oracle.com Wed Jun 3 15:15:31 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 3 Jun 2020 23:15:31 +0800 Subject: RFR 8246397: Use KnownOIDs for known OIDs In-Reply-To: References: <208AA8E7-E3A9-4936-9A84-A7C002043D9C@oracle.com> Message-ID: > On Jun 3, 2020, at 10:10 PM, Xuelei Fan wrote: > > It looks good to me. Thanks. > > BTW, I may declare KnownOIDs.oid as final and use it directly, rather than use the value() method. I'll keep it flexible at the moment. I dreamed of a day where an OID is only its DER sequence and seldom needs to be converted to its name or numerical format. --Max > > Xuelei > > On 6/2/2020 11:27 PM, Weijun Wang wrote: >> Please review the code change at >> http://cr.openjdk.java.net/~weijun/8246397/webrev.00/ >> The following KnownOIDs lines are related, in case you want to compare the values. >> 59: SubjectKeyID("2.5.29.14"), >> 60: KeyUsage("2.5.29.15"), >> 61: PrivateKeyUsage("2.5.29.16"), >> 62: SubjectAlternativeName("2.5.29.17"), >> 65: CRLNumber("2.5.29.20"), >> 68: InvalidityDate("2.5.29.24"), >> 72: NameConstraints("2.5.29.30"), >> 74: CertificatePolicies("2.5.29.32"), >> 75: CE_CERT_POLICIES_ANY("2.5.29.32.0"), >> 77: AuthorityKeyID("2.5.29.35"), >> 79: extendedKeyUsage("2.5.29.37"), >> 372: X25519("1.3.101.110"), >> 373: X448("1.3.101.111"), >> Noreg-cleanup. >> Thanks, >> Max From xuelei.fan at oracle.com Wed Jun 3 15:53:29 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 3 Jun 2020 08:53:29 -0700 Subject: RFR 8246397: Use KnownOIDs for known OIDs In-Reply-To: References: <208AA8E7-E3A9-4936-9A84-A7C002043D9C@oracle.com> Message-ID: <8b329ba9-93fa-9da2-89b6-828955ff7f47@oracle.com> On 6/3/2020 8:15 AM, Weijun Wang wrote: > > >> On Jun 3, 2020, at 10:10 PM, Xuelei Fan wrote: >> >> It looks good to me. > > Thanks. > >> >> BTW, I may declare KnownOIDs.oid as final and use it directly, rather than use the value() method. > > I'll keep it flexible at the moment. I dreamed of a day where an OID is only its DER sequence and seldom needs to be converted to its name or numerical format. > Okay. I may keep the KnownOIDs.oid and add a KnownOIDs.encodedOid if needed. Xuelei > --Max > >> >> Xuelei >> >> On 6/2/2020 11:27 PM, Weijun Wang wrote: >>> Please review the code change at >>> http://cr.openjdk.java.net/~weijun/8246397/webrev.00/ >>> The following KnownOIDs lines are related, in case you want to compare the values. >>> 59: SubjectKeyID("2.5.29.14"), >>> 60: KeyUsage("2.5.29.15"), >>> 61: PrivateKeyUsage("2.5.29.16"), >>> 62: SubjectAlternativeName("2.5.29.17"), >>> 65: CRLNumber("2.5.29.20"), >>> 68: InvalidityDate("2.5.29.24"), >>> 72: NameConstraints("2.5.29.30"), >>> 74: CertificatePolicies("2.5.29.32"), >>> 75: CE_CERT_POLICIES_ANY("2.5.29.32.0"), >>> 77: AuthorityKeyID("2.5.29.35"), >>> 79: extendedKeyUsage("2.5.29.37"), >>> 372: X25519("1.3.101.110"), >>> 373: X448("1.3.101.111"), >>> Noreg-cleanup. >>> Thanks, >>> Max > From sha.jiang at oracle.com Wed Jun 3 16:02:05 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 4 Jun 2020 00:02:05 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> <02591481-F24B-49F6-96D0-35EC2EFB4ADC@oracle.com> Message-ID: <2e2c3b28-572e-4561-ff38-c1415b23f1d2@oracle.com> On 2020/6/3 22:57, Weijun Wang wrote: >> >>> TsaParam.java: >>> >>> - Please group the fields into different area. Looks like some are fields in TSTInfo, and some are server internals. >> One usage of this class is carrying all parameters delivered by HTTP >> request. Do you mean they should be grouped in different classes? > No. Just add some comment lines inside the class and separate them into different groups. This class is also used for carrying TSA request fields, such as version, digestAlgo and hashedMessage, and especially certReq is in request only. > >>> The overall design is good, but I have a feeling that the interface and implementation can be further separated. I can see that there are a lot of methods and classes that will not be touched by TimeStampCheck at all. Should these things be taken out to be another implementation which is parallel to the one in TimeStampCheck? Maybe TsaHandler::createSigner will be abstract. >> All RespInterceptor methods are used by TimeStampCheck. >> DefaultRespInterceptor is used by standalone TSA server. In this style, no >> more RespInterceptor implementation is needed. > See below. > >>> There are quite some public constructors in the classes. Are they meant to be called by a user? Or by a child class? Or just internal? >> The public constructors in TsaServer can be called by applications for >> making standalone servers. > How about the other classes? TsaSigner has two constructors. One is for applications without new interceptor, the other is used by TimeStampCheck which needs to provide a custom interceptor. Please consider this TSA server will be used as standalone style, namely, no new interceptor is needed. It's not introduced for some specific test, like TimeStampCheck. >>> Also, for those protected methods (Ex: parseRequestParam and createResponse in TsaSigner), do you meant to override it in the future? >> Possibly. >> For example, a sub parseRequestParam() may need to parse extensions from >> request. A test may directly twist the byte[] returned by createResponse(), >> or even an overridden createResponse() just returns an empty byte[]. > Can we make them internal at the moment until someone really need to extend it? Yes, we can. But as a test lib, is it bad to think about a bit further? >>> Can you give examples on how to use this server? Will it always use DefaultRespInterceptor? If so, will the default impl in RespInterceptor.java ever be used? >> I'll use this server as standalone-like service. The custom TSA fields >> just be delivered by HTTP request query string. I won't provide a custom >> RespInterceptor, and DefaultRespInterceptor is enough to me. > You can put DefaultRespInterceptor in the standalone server. An application just needs to new TsaServer() with a keystore and start it, then a standalone server is ready. No more interceptor is needed. Otherwise, every application may need to provide an interceptor like DefaultRespInterceptor. > If you change TsaSigner.java > > 80 public TsaSigner(SignerEntry signerEntry, byte[] requestData, > 81 TsaParam param) { > 82 this(signerEntry, requestData, > 83 new DefaultRespInterceptor(param)); > > to use the even more "default" RespInterceptor, i.e. new RespInterceptor(){}, is it still useable? The param is needed. Or, the TSA fields cannot be changed without introducing a new interceptor. Could I launch a standalone TSA server at first, and then run jarsigner separately for manually checking some cases? For example, jarsigner ... -tsa "http://host:port?version=2" ... In the above command, the standalone TSA server will send a response with version is 2. Best regards, John Jiang From sean.mullan at oracle.com Wed Jun 3 16:23:03 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 3 Jun 2020 12:23:03 -0400 Subject: [RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported In-Reply-To: References: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> Message-ID: On 6/2/20 6:33 PM, Anthony Scarpino wrote: >> "If this signature has been previously initialized with parameters >> (by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link >> #setParameter(String, Object)}) and the underlying signature >> implementation supports returning the parameters as {@code >> AlgorithmParameters}, this method returns the same parameters." > > If we are going to reexamine this, then I would say "previously > initialized" is the wrong wording.? it makes it sound like it only > applies when the signature is reset().?? It should be replaced with > "set", regardless if it is the first op or a reset op. There is no reset() method in Signature. I assume you mean when the sign() or verify() method is complete. setParameter currently uses the following wording: "Initializes this signature engine with the specified parameter set." I don't see a big difference between the words initialize and set. But if you change the wording here, then you should change it in setParameter as well. --Sean From anthony.scarpino at oracle.com Wed Jun 3 22:05:47 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 3 Jun 2020 15:05:47 -0700 Subject: [RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported In-Reply-To: References: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> Message-ID: On 6/3/20 9:23 AM, Sean Mullan wrote: > On 6/2/20 6:33 PM, Anthony Scarpino wrote: >>> "If this signature has been previously initialized with parameters >>> (by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link >>> #setParameter(String, Object)}) and the underlying signature >>> implementation supports returning the parameters as {@code >>> AlgorithmParameters}, this method returns the same parameters." >> >> If we are going to reexamine this, then I would say "previously >> initialized" is the wrong wording.? it makes it sound like it only >> applies when the signature is reset().?? It should be replaced with >> "set", regardless if it is the first op or a reset op. > > There is no reset() method in Signature. I assume you mean when the > sign() or verify() method is complete. Yeah, too much time staring at Cipher and MD. > > setParameter currently uses the following wording: "Initializes this > signature engine with the specified parameter set." > > I don't see a big difference between the words initialize and set. > > But if you change the wording here, then you should change it in > setParameter as well. > > --Sean Since setParameter says "initialized", I think just dropping "previously" keeps the same symmetry. Tony From valerie.peng at oracle.com Wed Jun 3 23:37:16 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 3 Jun 2020 16:37:16 -0700 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> <74378A56-8536-4151-9B5D-257FBD5969EA@oracle.com> <253066b0-4a5f-4311-f3aa-4d6cd2393809@oracle.com> <24F7645C-EBF8-4BD3-A547-32F0E00F132C@oracle.com> Message-ID: <16d86466-5f39-5e32-91b5-c4c45e0359dd@oracle.com> Hi, Max, Overall looks very good. Just one more thing: Different key classes seems to differ in their handling of IOException in their constructor which produces the DER bytes. DSAPrivateKey changed to use AssertionError, XDHPrivateKeyImpl and EdDSAPrivateKeyImpl throws ProviderException. It seems that all other PrivateKey classes use InvalidKeyException. Perhaps it'd be nice to use InvalidKeyException for consistency sake? Thanks, Valerie On 6/1/2020 12:35 AM, Weijun Wang wrote: > Updated webrev at > > https://cr.openjdk.java.net/~weijun/8244565/webrev.03. > > I've inlined more methods that is only called once and inside the same method. > > Thanks, > Max > > >> On May 28, 2020, at 9:16 AM, Weijun Wang wrote: >> >> >> >>> On May 28, 2020, at 8:46 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> I like this new structure better. Much easier to understand. Most of the changes are technical debt that's accumulated inside PKCS8Key class. >>> >>> A few notable differences which I am not so sure about are >>> >>> - the encodedKey is returned by getEncoded() directly w/o cloning, and >> Too bad. I'll fix. >> >>> - the protected parseKeyBits() method being made private. I wonder if the parseKeyBits() method should be made abstract so it's more obvious that the subclasses needs to parse the key bytes into algorithm-specific components. >> Or how about I just inline parseKeyBits in those child classes into their constructors? I don't think the child class will forget it. Otherwise, why write a child class? >> >> Thanks, >> Max >> >>> Thanks, >>> Valerie >>> On 5/26/2020 5:54 PM, Weijun Wang wrote: >>>> Can you please take a look (not a review) at an updated webrev at http://cr.openjdk.java.net/~weijun/8244565/webrev.02/? It contains the code to inspect the extra fields. I haven't deal with the "..." here yet. >>>> >>>> However, when I tried to consolidate the DER parsing into one place, I've made more and more changes everywhere. The major change now is a base constructor PKCS8Key(byte[]) and subclass constructors that call it and no more protected parseKeyBits(). Although I don't think there is any technical error here but at the end of the day I'm asking myself if this is too much code change for such a simple bug. >>>> >>>> Do you like the overall structure? If yes, I'll continue this way. Otherwise, I can restrict the change only inside PKCS8Key. >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> On May 27, 2020, at 7:14 AM, Valerie Peng wrote: >>>>> >>>>> I suppose we can allow trailing data to conform to "..." then. >>>>> >>>>> But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? >>>>> >>>>> Valerie >>>>> >>>>> On 5/25/2020 9:02 PM, Weijun Wang wrote: >>>>>> The new definition at https://tools.ietf.org/html/rfc5958 shows, >>>>>> >>>>>> OneAsymmetricKey ::= SEQUENCE { >>>>>> version Version, >>>>>> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, >>>>>> privateKey PrivateKey, >>>>>> attributes [0] Attributes OPTIONAL, >>>>>> ..., >>>>>> [[2: publicKey [1] PublicKey OPTIONAL ]], >>>>>> ... >>>>>> } >>>>>> >>>>>> According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: >>>>>> >>>>>> The string "..." in ASN.1 is called an extension marker. The extension marker, >>>>>> ellipsis, is an indication that extension additions are expected. It makes no >>>>>> statement as to how such additions should be handled. However they shall not be >>>>>> treated as an error during the decoding process. >>>>>> >>>>>> So there might be more fields in the future. Do you still insist we need more validation? >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> On May 20, 2020, at 1:37 PM, Valerie Peng wrote: >>>>>>> >>>>>>> >>>>>>> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. >>>>>>> >>>>>>> Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> On 5/18/2020 9:36 PM, Weijun Wang wrote: >>>>>>>>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>>>>>>>> >>>>>>>>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>>>>>>>> >>>>>>>>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>>>>>>>> throws IOException { >>>>>>>>> boolean hasAttributes = false; >>>>>>>>> boolean hasPublicKey = false; >>>>>>>>> while (derIn.available () != 0) { >>>>>>>>> // check for OPTIONAL attributes and/or publicKey >>>>>>>>> DerValue tmp = derIn.getDerValue(); >>>>>>>>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>>>>>>>> // OPTIONAL attributes not supported yet >>>>>>>>> // discard for now and move on >>>>>>>>> hasAttributes = true; >>>>>>>>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>>>>>>>> !hasPublicKey) { >>>>>>>>> // OPTIONAL v2 public key not supported yet >>>>>>>>> // discard for now and move on >>>>>>>>> hasPublicKey = true; >>>>>>>>> } else { >>>>>>>>> throw new IOException ("illegal encoding in private key"); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >>>>>>>> >>>>>>>>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >>>>>>>> OK. >>>>>>>> >>>>>>>>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >>>>>>>> Yes. >>>>>>>> >>>>>>>>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >>>>>>>> If you still want checkTrailingBytes, then yes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>>>>>>>> I will take a look. >>>>>>>>>> >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>>>>>>>> Found an existing test I can update. Webrev updated at >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>>>>>>>> >>>>>>>>>>>> Please take a review at >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>>>>>>>> >>>>>>>>>>>> I also take this chance to make some format change. >>>>>>>>>>>> >>>>>>>>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max >>>>>>>>>>>> From valerie.peng at oracle.com Thu Jun 4 00:09:44 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 3 Jun 2020 17:09:44 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable Message-ID: Hi, Anyone can help review this fix? I changed com.sun.crypto.provider.HmacCore class and sun.security.ssl.HandshakeHash class to check for cloneability based on the clone() call instead of the Cloneable interface. Noticed a bug in sun.security.provider.DigestBase class which misses to reset the temporary buffer when cloning and fixed it here as well. Lastly, I also made changes to java.security.MessageDigest and java.security.Signature classes and attempt to match the Delegate wrapper with the underlying spi object, i.e. if the spi implements Cloneable and then Delegate wrapper also implements Cloneable. This part is mostly for non-JDK callers which rely on the instanceof Cloneable check for cloneability. However, for Signature class, if the object is requested using Signature.getInstance(String), then we can't do matching here since the underlying spi is not yet determined at this time. The 3? TestCloneable.java tests are for testing this last part and is NOT for the HmacCore and HandshakeHash changes. I am on the fence about this part and am open to leave this out if minimum fix is preferred. Bug: https://bugs.openjdk.java.net/browse/JDK-8246077 Webrev: http://cr.openjdk.java.net/~valeriep/8246077/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Thu Jun 4 02:40:12 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 3 Jun 2020 19:40:12 -0700 Subject: [15] RFR JDK-8087327: CipherStream produces new byte array on every update or doFinal operation Message-ID: Hi, Anyone can help review this straightforward enhancement? The changes are mostly based on the submitted patch with some minor polishing. Essentially re-using existing buffer instead of relying on the Cipher object to allocate new buffers. RFE: https://bugs.openjdk.java.net/browse/JDK-8087327 Webrev: http://cr.openjdk.java.net/~valeriep/8087327/webrev.00/ Thanks, Valerie From anthony.scarpino at oracle.com Thu Jun 4 02:45:56 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 3 Jun 2020 19:45:56 -0700 Subject: [RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported In-Reply-To: References: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> Message-ID: <0592ee70-37ba-aa3b-7a6b-d441cd829d1b@oracle.com> On 6/3/20 3:05 PM, Anthony Scarpino wrote: > On 6/3/20 9:23 AM, Sean Mullan wrote: >> On 6/2/20 6:33 PM, Anthony Scarpino wrote: >>>> "If this signature has been previously initialized with parameters >>>> (by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link >>>> #setParameter(String, Object)}) and the underlying signature >>>> implementation supports returning the parameters as {@code >>>> AlgorithmParameters}, this method returns the same parameters." >>> >>> If we are going to reexamine this, then I would say "previously >>> initialized" is the wrong wording.? it makes it sound like it only >>> applies when the signature is reset().?? It should be replaced with >>> "set", regardless if it is the first op or a reset op. >> >> There is no reset() method in Signature. I assume you mean when the >> sign() or verify() method is complete. > > Yeah, too much time staring at Cipher and MD. > >> >> setParameter currently uses the following wording: "Initializes this >> signature engine with the specified parameter set." >> >> I don't see a big difference between the words initialize and set. >> >> But if you change the wording here, then you should change it in >> setParameter as well. >> >> --Sean > > Since setParameter says "initialized", I think just dropping > "previously" keeps the same symmetry. > > Tony updated webrev: https://cr.openjdk.java.net/~ascarpino/8243424/webrev.02/ Tony From weijun.wang at oracle.com Thu Jun 4 02:48:08 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 4 Jun 2020 10:48:08 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <16d86466-5f39-5e32-91b5-c4c45e0359dd@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> <74378A56-8536-4151-9B5D-257FBD5969EA@oracle.com> <253066b0-4a5f-4311-f3aa-4d6cd2393809@oracle.com> <24F7645C-EBF8-4BD3-A547-32F0E00F132C@oracle.com> <16d86466-5f39-5e32-91b5-c4c45e0359dd@oracle.com> Message-ID: <89FC7446-3272-433C-9E31-F76413754496@oracle.com> RSAPrivateKeyImpl and RSAPrivateCrtKeyImpl - throws InvalidKeyException when RSAUtil.createAlgorithmId(type, keyParams) fails. I'll keep it. EdDSAPrivateKeyImpl, XDHPrivateKeyImpl and ECPrivateKeyImpl - check the input ECParameterSpec params and might throw an InvalidKeyException. I'll keep it. Some of these constructors now throws ProviderException or InvalidKeyException when DER encoding goes wrong. This should never happen, and I'll throw AssertionError for it. In short, the only possible exception is now InvalidKeyException. I also throw AssertionError but it's not possible and definitely means a programming error somewhere (Ex: DerValue::putInteger goes wrong). So here is the updated webrev http://cr.openjdk.java.net/~weijun/8244565/webrev.04/ Thanks, Max > On Jun 4, 2020, at 7:37 AM, Valerie Peng wrote: > > Hi, Max, > > Overall looks very good. Just one more thing: > > Different key classes seems to differ in their handling of IOException in their constructor which produces the DER bytes. > > DSAPrivateKey changed to use AssertionError, XDHPrivateKeyImpl and EdDSAPrivateKeyImpl throws ProviderException. It seems that all other PrivateKey classes use InvalidKeyException. Perhaps it'd be nice to use InvalidKeyException for consistency sake? > > Thanks, > Valerie > On 6/1/2020 12:35 AM, Weijun Wang wrote: >> Updated webrev at >> >> https://cr.openjdk.java.net/~weijun/8244565/webrev.03. >> >> I've inlined more methods that is only called once and inside the same method. >> >> Thanks, >> Max >> >> >>> On May 28, 2020, at 9:16 AM, Weijun Wang wrote: >>> >>> >>> >>>> On May 28, 2020, at 8:46 AM, Valerie Peng wrote: >>>> >>>> Hi Max, >>>> >>>> I like this new structure better. Much easier to understand. Most of the changes are technical debt that's accumulated inside PKCS8Key class. >>>> >>>> A few notable differences which I am not so sure about are >>>> >>>> - the encodedKey is returned by getEncoded() directly w/o cloning, and >>> Too bad. I'll fix. >>> >>>> - the protected parseKeyBits() method being made private. I wonder if the parseKeyBits() method should be made abstract so it's more obvious that the subclasses needs to parse the key bytes into algorithm-specific components. >>> Or how about I just inline parseKeyBits in those child classes into their constructors? I don't think the child class will forget it. Otherwise, why write a child class? >>> >>> Thanks, >>> Max >>> >>>> Thanks, >>>> Valerie >>>> On 5/26/2020 5:54 PM, Weijun Wang wrote: >>>>> Can you please take a look (not a review) at an updated webrev at http://cr.openjdk.java.net/~weijun/8244565/webrev.02/? It contains the code to inspect the extra fields. I haven't deal with the "..." here yet. >>>>> >>>>> However, when I tried to consolidate the DER parsing into one place, I've made more and more changes everywhere. The major change now is a base constructor PKCS8Key(byte[]) and subclass constructors that call it and no more protected parseKeyBits(). Although I don't think there is any technical error here but at the end of the day I'm asking myself if this is too much code change for such a simple bug. >>>>> >>>>> Do you like the overall structure? If yes, I'll continue this way. Otherwise, I can restrict the change only inside PKCS8Key. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> On May 27, 2020, at 7:14 AM, Valerie Peng wrote: >>>>>> >>>>>> I suppose we can allow trailing data to conform to "..." then. >>>>>> >>>>>> But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? >>>>>> >>>>>> Valerie >>>>>> >>>>>> On 5/25/2020 9:02 PM, Weijun Wang wrote: >>>>>>> The new definition at https://tools.ietf.org/html/rfc5958 shows, >>>>>>> >>>>>>> OneAsymmetricKey ::= SEQUENCE { >>>>>>> version Version, >>>>>>> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, >>>>>>> privateKey PrivateKey, >>>>>>> attributes [0] Attributes OPTIONAL, >>>>>>> ..., >>>>>>> [[2: publicKey [1] PublicKey OPTIONAL ]], >>>>>>> ... >>>>>>> } >>>>>>> >>>>>>> According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: >>>>>>> >>>>>>> The string "..." in ASN.1 is called an extension marker. The extension marker, >>>>>>> ellipsis, is an indication that extension additions are expected. It makes no >>>>>>> statement as to how such additions should be handled. However they shall not be >>>>>>> treated as an error during the decoding process. >>>>>>> >>>>>>> So there might be more fields in the future. Do you still insist we need more validation? >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> On May 20, 2020, at 1:37 PM, Valerie Peng wrote: >>>>>>>> >>>>>>>> >>>>>>>> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. >>>>>>>> >>>>>>>> Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> On 5/18/2020 9:36 PM, Weijun Wang wrote: >>>>>>>>>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>>>>>>>>> >>>>>>>>>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>>>>>>>>> >>>>>>>>>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>>>>>>>>> throws IOException { >>>>>>>>>> boolean hasAttributes = false; >>>>>>>>>> boolean hasPublicKey = false; >>>>>>>>>> while (derIn.available () != 0) { >>>>>>>>>> // check for OPTIONAL attributes and/or publicKey >>>>>>>>>> DerValue tmp = derIn.getDerValue(); >>>>>>>>>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>>>>>>>>> // OPTIONAL attributes not supported yet >>>>>>>>>> // discard for now and move on >>>>>>>>>> hasAttributes = true; >>>>>>>>>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>>>>>>>>> !hasPublicKey) { >>>>>>>>>> // OPTIONAL v2 public key not supported yet >>>>>>>>>> // discard for now and move on >>>>>>>>>> hasPublicKey = true; >>>>>>>>>> } else { >>>>>>>>>> throw new IOException ("illegal encoding in private key"); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >>>>>>>>> >>>>>>>>>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >>>>>>>>> OK. >>>>>>>>> >>>>>>>>>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >>>>>>>>> Yes. >>>>>>>>> >>>>>>>>>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >>>>>>>>> If you still want checkTrailingBytes, then yes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>>>>>>>>> I will take a look. >>>>>>>>>>> >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>>>>>>>>> Found an existing test I can update. Webrev updated at >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Please take a review at >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>>>>>>>>> >>>>>>>>>>>>> I also take this chance to make some format change. >>>>>>>>>>>>> >>>>>>>>>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Max >>>>>>>>>>>>> From weijun.wang at oracle.com Thu Jun 4 07:18:16 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 4 Jun 2020 15:18:16 +0800 Subject: [15] RFR JDK-8087327: CipherStream produces new byte array on every update or doFinal operation In-Reply-To: References: Message-ID: <14571518-6133-46BE-8210-910467CDD798@oracle.com> Looks fine to me. Thanks, Max > On Jun 4, 2020, at 10:40 AM, Valerie Peng wrote: > > Hi, > > Anyone can help review this straightforward enhancement? The changes are mostly based on the submitted patch with some minor polishing. Essentially re-using existing buffer instead of relying on the Cipher object to allocate new buffers. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8087327 > > Webrev: http://cr.openjdk.java.net/~valeriep/8087327/webrev.00/ > > Thanks, > > Valerie > From weijun.wang at oracle.com Thu Jun 4 10:54:23 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 4 Jun 2020 18:54:23 +0800 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: References: Message-ID: HmacCore.java: 78 md = null; 79 String noCloneProv = md.getProvider().getName(); NPE on line 79. Should reverse. > On Jun 4, 2020, at 8:09 AM, Valerie Peng wrote: > > Hi, > > Anyone can help review this fix? I changed com.sun.crypto.provider.HmacCore class and sun.security.ssl.HandshakeHash class to check for cloneability based on the clone() call instead of the Cloneable interface. Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? The test is not complete. There should be non-cloneable hash. Or even better, a hash which is not cloneable from the preferred provider but cloneable from another. Hopefully you can simply reuse an existing implementation with a different algorithm name and override its clone() to throw CNSE. Thanks, Max > Noticed a bug in sun.security.provider.DigestBase class which misses to reset the temporary buffer when cloning and fixed it here as well. > > Lastly, I also made changes to java.security.MessageDigest and java.security.Signature classes and attempt to match the Delegate wrapper with the underlying spi object, i.e. if the spi implements Cloneable and then Delegate wrapper also implements Cloneable. This part is mostly for non-JDK callers which rely on the instanceof Cloneable check for cloneability. However, for Signature class, if the object is requested using Signature.getInstance(String), then we can't do matching here since the underlying spi is not yet determined at this time. The 3 TestCloneable.java tests are for testing this last part and is NOT for the HmacCore and HandshakeHash changes. I am on the fence about this part and am open to leave this out if minimum fix is preferred. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246077 > Webrev: http://cr.openjdk.java.net/~valeriep/8246077/webrev.00/ > > Thanks, > > Valerie > From hai-may.chao at oracle.com Thu Jun 4 11:29:54 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Thu, 4 Jun 2020 04:29:54 -0700 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> Message-ID: <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> Hi Max, > On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: > > The source change looks fine to me. > > In TrustedCert.java: > > - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). This cat() is taken from WealAlg.java. > > - There is no need to recreate root.jks and root.pem. The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. Please also elaborate your comment about no need to recreate root.jks and root.pem. > > - Why not use -trustcacerts below? > > 160 kt("-importcert -file server.pem -noprompt", "server.jks?); Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. > > - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. Ok, will change it. > > In TrustedCRL.java: > > - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. Same reply as above. > > - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. > > Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. Thanks, Hai-May > Thanks, > Max > > >> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >> >> Hi, >> >> I?d like to request a review for: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >> >> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >> >> Thanks, >> Hai-May >> > From weijun.wang at oracle.com Thu Jun 4 12:57:16 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 4 Jun 2020 20:57:16 +0800 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> Message-ID: > On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: > > Hi Max, > >> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >> >> The source change looks fine to me. >> >> In TrustedCert.java: >> >> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). > > This cat() is taken from WealAlg.java. > >> >> - There is no need to recreate root.jks and root.pem. > > The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. > > Please also elaborate your comment about no need to recreate root.jks and root.pem. > >> >> - Why not use -trustcacerts below? >> >> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); > > > Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. OK. Then how about we add a new command before line 155? kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); This would prove the "-trustcacerts" on line 155 is really useful. > >> >> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. > > Ok, will change it. > >> >> In TrustedCRL.java: >> >> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. > > Same reply as above. Same question as above. > >> >> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? > > Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. > >> >> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. > > I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. I meant creating the cacerts in one method, something like void createCacerts(String ks, String... crt); and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. BTW, what does caks.size() == 0 matter here? Thanks, Max > > Thanks, > Hai-May > > >> Thanks, >> Max >> >> >>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>> >>> Hi, >>> >>> I?d like to request a review for: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>> >>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>> >>> Thanks, >>> Hai-May >>> >> > From stooke at redhat.com Thu Jun 4 13:35:07 2020 From: stooke at redhat.com (Simon Tooke) Date: Thu, 4 Jun 2020 09:35:07 -0400 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> Message-ID: Hello, David, and thanks for the review! I've responded to your comments below, and intend to post a new patch for review today or tomorrow. Thanks again, -Simon On 2020-06-03 2:06 a.m., David Holmes wrote: > Hi Simon, > > On 23/05/2020 12:04 am, Sean Mullan wrote: >> Cross-posting to hotspot-dev for additional review since the code >> changes are in hotspot. >> >> --Sean >> >> On 5/21/20 1:24 PM, Simon Tooke wrote: >>> Hello, >>> >>> I'd like to request a review for: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/00/00/ >>> >>> This change implements the given intrinsics on Windows. >>> >>> The Windows toolchain has no 128 bit integer types, and no inline >>> asm (on x64 and Arm).? In addition, 'long' is 4 bytes, not 8, as it >>> is with gcc.? This patch had to change some of the linux >>> implementation to account for these limitations. > > I can't really comment on the intrinsics themselves but a couple of > suggestions: > > - use explicitly sized types e.g. uint64_t instead of unsigned long long Yes, this hurt to type.? A previous review suggested using julong, is that acceptable to you? (an aside: I'm now wondering if there is other code in the JDK that assumes long is 64bits - which is not true on all platforms...) > - use the existing NOINLINE macro for the _declspec(noinline) Thanks, will do. > > The conditional compilation in this code has me quite confused. > Looking at the existing code we have: > > 3680 #ifndef _WINDOWS > 3681 > 3682 #define ASM_SUBTRACT > 3683 > 3684 #ifdef ASM_SUBTRACT > ... > 3702 #else // ASM_SUBTRACT > ... > 3719 #endif // ! ASM_SUBTRACT > > So all the above code is only built on not-Windows, and we > unconditionally define ASM_SUBTRACT, so lines 3702 to 3719 appear to > be dead code! I'm not at all sure whether that is actually a bug and > the windows ifndef should have had an endif after line 3682; or > whether we can just simplify the code. The dead code existed prior to this patch, so I wasn't proposing removing it.? I'm happy to do so if that's for the best.? As far as I can tell, it's for implementing these intrinsics on gcc platforms without assembler. > > Thanks, > David > >>> >>> My gratitude for Andrew Haley for doing the heavy lifting at the >>> core of this patch. >>> >>> The patch, if accepted, will be offered to 11u as a potential >>> backport. The changes apply cleanly modulo some line number changes. >>> >>> As for the speedup, this test case: >>> >>> BigInteger base = BigInteger.ONE.shiftLeft(1024); >>> long count = LongStream.rangeClosed(2, 100_000) >>> ???? .mapToObj(n -> BigInteger.valueOf(n).add(base)) >>> ???? .filter(i -> i.isProbablePrime(50)) >>> ???? .count(); >>> >>> goes from 1 minute 20 seconds down to about 35 seconds om my VM, >>> over multiple runs.? As is the case on other platforms where the >>> intrinsics are supported, they will be enabled by default on Windows. >>> >>> Thank you for your time, >>> >>> -Simon Tooke >>> >>> >>> Principal Software Engineer, >>> >>> Red Hat Canada >>> >>> >>> > From aph at redhat.com Thu Jun 4 14:08:45 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Jun 2020 15:08:45 +0100 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> Message-ID: On 04/06/2020 14:35, Simon Tooke wrote: > Yes, this hurt to type.? A previous review suggested using julong, is > that acceptable to you? > > (an aside: I'm now wondering if there is other code in the JDK that > assumes long is 64bits - which is not true on all platforms...) That was just me, I think. I knew that this code would take some fixing up on Windows so I postponed portability issues until then. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From weijun.wang at oracle.com Thu Jun 4 14:18:21 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 4 Jun 2020 22:18:21 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: <2e2c3b28-572e-4561-ff38-c1415b23f1d2@oracle.com> References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> <02591481-F24B-49F6-96D0-35EC2EFB4ADC@oracle.com> <2e2c3b28-572e-4561-ff38-c1415b23f1d2@oracle.com> Message-ID: <44B6310A-32AC-4C03-B745-ACAEFB2BD170@oracle.com> OK. Please go on. No other comment. > On Jun 4, 2020, at 12:02 AM, sha.jiang at oracle.com wrote: > >> Can we make them internal at the moment until someone really need to extend it? > Yes, we can. > But as a test lib, is it bad to think about a bit further? But think about it carefully when there are new requirements. It's probably not a good idea to make every method overridable at the beginning and say do whatever you want. Thanks, Max From prasadarao.koppula at oracle.com Thu Jun 4 15:13:09 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Thu, 4 Jun 2020 08:13:09 -0700 (PDT) Subject: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test Message-ID: <26ba099b-c324-4492-abfc-ad454041382a@default> Hi, Could you please review this patch. For timeout/interrupts, JDK11u+ releases, SSLSocket:getSession behavior is different, compare to JDK8u. i.e, connection is in open state for timeout/interrupts exception. For comparability reasons, this fix will close connection for getSession timeout/ interrupts. Bug: https://bugs.openjdk.java.net/browse/JDK-8246031 Webrev: http://cr.openjdk.java.net/~pkoppula/8246031/webrev.00/ Thanks, Prasad.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivangi.g.gupta at oracle.com Thu Jun 4 17:29:42 2020 From: shivangi.g.gupta at oracle.com (shivangi.g.gupta at oracle.com) Date: Thu, 4 Jun 2020 22:59:42 +0530 Subject: RFR:8246330:Add TLS Tests for Legacy ECDSA curves Message-ID: <6aa9a1aa-cf2a-b806-1b57-b223752751d8@oracle.com> Hi, May I please find a sponsor for this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8246330 Description:Many of EC named curves has been disabled with security property "jdk.disabled.namedCurves". The purpose of this Test is to verify the behavior of any EC named curve from the disabled list. This Test will address a single name from the disabled list as sect283r1. Webrev: http://cr.openjdk.java.net/~sshivang/reviews/ 8246330/webrev.00/ The patch has been tested on mach5, and the individual test was passed. Thanks Shivangi -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Thu Jun 4 18:15:49 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 4 Jun 2020 18:15:49 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> Message-ID: <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> Hello, Could you please review new version of the patch: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v3/ I?ve moved all logic for creating TLS Channel Binding data out of GssKrb5Client.java file. All data is prepared inside TlsChannelBinding class. Internal property name is renamed to ?com.sun.security.sasl.tlschannelbinding?. TlsChannelBinding object is still used to pass channel binding data from LdapClient to GssKrb5Client. I do not change it to byte[] because of TlsChannelBinding class is still used for internal property name. Also, I?ve updated TlsChannelBinding class to select SHA-256 hash algorithm if it can not be derived from the certificate signature name. Regards Alexey > On 26 May 2020, at 17:50, Weijun Wang wrote: > > I have a question on GssKrb5Client.java: > > Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. > > From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. > > Thanks, > Max > >> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >> >> Hello, >> >> Could you please review the following patch: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> >> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >> (based on the TLS server certificate). The channel binding data is calculated as following : >> ? The client calculates a hash of the TLS server certificate. >> The hash algorithm is selected on the base of the certificate signature algorithm. >> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >> ? initiator and acceptor addresses should be set to NULL >> ? initiator and acceptor address types should be zero. >> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >> instead of GSS_C_AF_UNSPEC=0x00. >> >> This patch introduces changes in the LDAP, SASL and JGSS modules >> to generate channel binding data automatically if requested by an application. >> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >> Right now "tls-server-end-point" Channel Binding type is supported only. >> The client extracts server certificate from the underlying TLS connection and creates >> Channel Binding data for JGSS/Kerberos authentication if application indicates >> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >> >> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >> >> [2] - >> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >> >> Initial discussion of this issue is available at security-dev list: >> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From valerie.peng at oracle.com Thu Jun 4 19:19:01 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 4 Jun 2020 12:19:01 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: References: Message-ID: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> Hi Max, Please find replies in line. On 6/4/2020 3:54 AM, Weijun Wang wrote: > HmacCore.java: > > 78 md = null; > 79 String noCloneProv = md.getProvider().getName(); > > NPE on line 79. Should reverse. Good catch, fixed. >> On Jun 4, 2020, at 8:09 AM, Valerie Peng wrote: >> >> Hi, >> >> Anyone can help review this fix? I changed com.sun.crypto.provider.HmacCore class and sun.security.ssl.HandshakeHash class to check for cloneability based on the clone() call instead of the Cloneable interface. > Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? > The test is not complete. There should be non-cloneable hash. Or even better, a hash which is not cloneable from the preferred provider but cloneable from another. Hopefully you can simply reuse an existing implementation with a different algorithm name and override its clone() to throw CNSE. Right, I will expand the tests. Just want to gauge on people's preference of matching the Cloneable interface (the last part of changes in my earlier email) first, while I explore the existing tests. Thanks, Valerie > > Thanks, > Max > > >> Noticed a bug in sun.security.provider.DigestBase class which misses to reset the temporary buffer when cloning and fixed it here as well. >> >> Lastly, I also made changes to java.security.MessageDigest and java.security.Signature classes and attempt to match the Delegate wrapper with the underlying spi object, i.e. if the spi implements Cloneable and then Delegate wrapper also implements Cloneable. This part is mostly for non-JDK callers which rely on the instanceof Cloneable check for cloneability. However, for Signature class, if the object is requested using Signature.getInstance(String), then we can't do matching here since the underlying spi is not yet determined at this time. The 3 TestCloneable.java tests are for testing this last part and is NOT for the HmacCore and HandshakeHash changes. I am on the fence about this part and am open to leave this out if minimum fix is preferred. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8246077 >> Webrev: http://cr.openjdk.java.net/~valeriep/8246077/webrev.00/ >> >> Thanks, >> >> Valerie >> From valerie.peng at oracle.com Thu Jun 4 19:34:37 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 4 Jun 2020 12:34:37 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering Message-ID: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> Hi, Could someone help reviewing this fix? This change keep tracks of the first registered SecureRandom algorithm and returns it upon the request of SecureRandom class. Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Thu Jun 4 19:51:21 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 4 Jun 2020 12:51:21 -0700 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <89FC7446-3272-433C-9E31-F76413754496@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> <74378A56-8536-4151-9B5D-257FBD5969EA@oracle.com> <253066b0-4a5f-4311-f3aa-4d6cd2393809@oracle.com> <24F7645C-EBF8-4BD3-A547-32F0E00F132C@oracle.com> <16d86466-5f39-5e32-91b5-c4c45e0359dd@oracle.com> <89FC7446-3272-433C-9E31-F76413754496@oracle.com> Message-ID: <22c32c93-5488-c9a0-7d80-88aa21ca1ac4@oracle.com> Sure, I have no more comments. Thanks, Valerie On 6/3/2020 7:48 PM, Weijun Wang wrote: > RSAPrivateKeyImpl and RSAPrivateCrtKeyImpl > > - throws InvalidKeyException when RSAUtil.createAlgorithmId(type, keyParams) fails. I'll keep it. > > EdDSAPrivateKeyImpl, XDHPrivateKeyImpl and ECPrivateKeyImpl > > - check the input ECParameterSpec params and might throw an InvalidKeyException. I'll keep it. > > Some of these constructors now throws ProviderException or InvalidKeyException when DER encoding goes wrong. This should never happen, and I'll throw AssertionError for it. > > In short, the only possible exception is now InvalidKeyException. I also throw AssertionError but it's not possible and definitely means a programming error somewhere (Ex: DerValue::putInteger goes wrong). > > So here is the updated webrev > > http://cr.openjdk.java.net/~weijun/8244565/webrev.04/ > > Thanks, > Max > > > >> On Jun 4, 2020, at 7:37 AM, Valerie Peng wrote: >> >> Hi, Max, >> >> Overall looks very good. Just one more thing: >> >> Different key classes seems to differ in their handling of IOException in their constructor which produces the DER bytes. >> >> DSAPrivateKey changed to use AssertionError, XDHPrivateKeyImpl and EdDSAPrivateKeyImpl throws ProviderException. It seems that all other PrivateKey classes use InvalidKeyException. Perhaps it'd be nice to use InvalidKeyException for consistency sake? >> >> Thanks, >> Valerie >> On 6/1/2020 12:35 AM, Weijun Wang wrote: >>> Updated webrev at >>> >>> https://cr.openjdk.java.net/~weijun/8244565/webrev.03. >>> >>> I've inlined more methods that is only called once and inside the same method. >>> >>> Thanks, >>> Max >>> >>> >>>> On May 28, 2020, at 9:16 AM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On May 28, 2020, at 8:46 AM, Valerie Peng wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> I like this new structure better. Much easier to understand. Most of the changes are technical debt that's accumulated inside PKCS8Key class. >>>>> >>>>> A few notable differences which I am not so sure about are >>>>> >>>>> - the encodedKey is returned by getEncoded() directly w/o cloning, and >>>> Too bad. I'll fix. >>>> >>>>> - the protected parseKeyBits() method being made private. I wonder if the parseKeyBits() method should be made abstract so it's more obvious that the subclasses needs to parse the key bytes into algorithm-specific components. >>>> Or how about I just inline parseKeyBits in those child classes into their constructors? I don't think the child class will forget it. Otherwise, why write a child class? >>>> >>>> Thanks, >>>> Max >>>> >>>>> Thanks, >>>>> Valerie >>>>> On 5/26/2020 5:54 PM, Weijun Wang wrote: >>>>>> Can you please take a look (not a review) at an updated webrev at http://cr.openjdk.java.net/~weijun/8244565/webrev.02/? It contains the code to inspect the extra fields. I haven't deal with the "..." here yet. >>>>>> >>>>>> However, when I tried to consolidate the DER parsing into one place, I've made more and more changes everywhere. The major change now is a base constructor PKCS8Key(byte[]) and subclass constructors that call it and no more protected parseKeyBits(). Although I don't think there is any technical error here but at the end of the day I'm asking myself if this is too much code change for such a simple bug. >>>>>> >>>>>> Do you like the overall structure? If yes, I'll continue this way. Otherwise, I can restrict the change only inside PKCS8Key. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> On May 27, 2020, at 7:14 AM, Valerie Peng wrote: >>>>>>> >>>>>>> I suppose we can allow trailing data to conform to "..." then. >>>>>>> >>>>>>> But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? >>>>>>> >>>>>>> Valerie >>>>>>> >>>>>>> On 5/25/2020 9:02 PM, Weijun Wang wrote: >>>>>>>> The new definition at https://tools.ietf.org/html/rfc5958 shows, >>>>>>>> >>>>>>>> OneAsymmetricKey ::= SEQUENCE { >>>>>>>> version Version, >>>>>>>> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, >>>>>>>> privateKey PrivateKey, >>>>>>>> attributes [0] Attributes OPTIONAL, >>>>>>>> ..., >>>>>>>> [[2: publicKey [1] PublicKey OPTIONAL ]], >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: >>>>>>>> >>>>>>>> The string "..." in ASN.1 is called an extension marker. The extension marker, >>>>>>>> ellipsis, is an indication that extension additions are expected. It makes no >>>>>>>> statement as to how such additions should be handled. However they shall not be >>>>>>>> treated as an error during the decoding process. >>>>>>>> >>>>>>>> So there might be more fields in the future. Do you still insist we need more validation? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>>> On May 20, 2020, at 1:37 PM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. >>>>>>>>> >>>>>>>>> Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> On 5/18/2020 9:36 PM, Weijun Wang wrote: >>>>>>>>>>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>>>>>>>>>> >>>>>>>>>>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>>>>>>>>>> >>>>>>>>>>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>>>>>>>>>> throws IOException { >>>>>>>>>>> boolean hasAttributes = false; >>>>>>>>>>> boolean hasPublicKey = false; >>>>>>>>>>> while (derIn.available () != 0) { >>>>>>>>>>> // check for OPTIONAL attributes and/or publicKey >>>>>>>>>>> DerValue tmp = derIn.getDerValue(); >>>>>>>>>>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>>>>>>>>>> // OPTIONAL attributes not supported yet >>>>>>>>>>> // discard for now and move on >>>>>>>>>>> hasAttributes = true; >>>>>>>>>>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>>>>>>>>>> !hasPublicKey) { >>>>>>>>>>> // OPTIONAL v2 public key not supported yet >>>>>>>>>>> // discard for now and move on >>>>>>>>>>> hasPublicKey = true; >>>>>>>>>>> } else { >>>>>>>>>>> throw new IOException ("illegal encoding in private key"); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >>>>>>>>>> >>>>>>>>>>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >>>>>>>>>> OK. >>>>>>>>>> >>>>>>>>>>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >>>>>>>>>> Yes. >>>>>>>>>> >>>>>>>>>>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >>>>>>>>>> If you still want checkTrailingBytes, then yes. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>>>>>>>>>> I will take a look. >>>>>>>>>>>> >>>>>>>>>>>> Valerie >>>>>>>>>>>> >>>>>>>>>>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>>>>>>>>>> Found an existing test I can update. Webrev updated at >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please take a review at >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I also take this chance to make some format change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> From sean.mullan at oracle.com Thu Jun 4 21:01:31 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 4 Jun 2020 17:01:31 -0400 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> Message-ID: On 6/4/20 3:34 PM, Valerie Peng wrote: > Hi, > > Could someone help reviewing this fix? This change keep tracks of the > first registered SecureRandom algorithm and returns it upon the request > of SecureRandom class. This looks good to me. I would recommend that Max or someone else review it as well. > Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 > > Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ A couple of minor comments, feel free to fix or ignore. * SecureRandom.java 879 // For SUN provider, we use SunEntries.DEFF_SECURE_RANDOM_ALGO Might as well fix the typo while you are in there: s/DEFF/DEF/ * Provider.java 1156 private String parseSecureRandomPut(String name, String value) { Could be static if you also make getTypeAndAlgorithm static, I think. --Sean From valerie.peng at oracle.com Thu Jun 4 21:22:28 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 4 Jun 2020 14:22:28 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> Message-ID: <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> Hi, Sean, Thanks for the review and feedback. Webrev updated: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ getTypeAndAlgorithm(...) was not static due to an instance variable used by debugging output. I have removed it and made both method static. I will wait for others' review comments also. Thanks, Valerie On 6/4/2020 2:01 PM, Sean Mullan wrote: > On 6/4/20 3:34 PM, Valerie Peng wrote: >> Hi, >> >> Could someone help reviewing this fix? This change keep tracks of the >> first registered SecureRandom algorithm and returns it upon the >> request of SecureRandom class. > > This looks good to me. I would recommend that Max or someone else > review it as well. > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ > > A couple of minor comments, feel free to fix or ignore. > > * SecureRandom.java > > 879???????????? // For SUN provider, we use > SunEntries.DEFF_SECURE_RANDOM_ALGO > > Might as well fix the typo while you are in there: s/DEFF/DEF/ > > * Provider.java > > 1156???? private String parseSecureRandomPut(String name, String value) { > > Could be static if you also make getTypeAndAlgorithm static, I think. > > --Sean From weijun.wang at oracle.com Thu Jun 4 23:16:44 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 5 Jun 2020 07:16:44 +0800 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> Message-ID: <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> > ? 2020?6?5??03:19?Valerie Peng ??? > >> Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? > > Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? No. I understand this case, but this has already been fixed. Is there any other example? Or are you only follow the words in the spec? i.e. try clone() to see if it?s cloneable. I am worried that try clone() is much heavier than just check instanof Cloneable. Thanks, Max From sha.jiang at oracle.com Fri Jun 5 00:53:56 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 5 Jun 2020 08:53:56 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: <44B6310A-32AC-4C03-B745-ACAEFB2BD170@oracle.com> References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> <02591481-F24B-49F6-96D0-35EC2EFB4ADC@oracle.com> <2e2c3b28-572e-4561-ff38-c1415b23f1d2@oracle.com> <44B6310A-32AC-4C03-B745-ACAEFB2BD170@oracle.com> Message-ID: <153262fa-ef95-2df2-4d76-1f1ff4bf37d5@oracle.com> Hi Max Please review this webrev: http://cr.openjdk.java.net/~jjiang/8244683/webrev.05/ - TimestampCheck.java The codes in those private methods in Interceptor are merged into getRespParam(). - TsaParam.java Group the fields as signing internals and TSA fields. - TsaSigner.java parseRequestParam() and createResponse() are private now. Best regards, John Jiang On 2020/6/4 22:18, Weijun Wang wrote: > OK. Please go on. No other comment. > >> On Jun 4, 2020, at 12:02 AM, sha.jiang at oracle.com wrote: >> >>> Can we make them internal at the moment until someone really need to extend it? >> Yes, we can. >> But as a test lib, is it bad to think about a bit further? > But think about it carefully when there are new requirements. It's probably not a good idea to make every method overridable at the beginning and say do whatever you want. > > Thanks, > Max > From weijun.wang at oracle.com Fri Jun 5 03:18:33 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 5 Jun 2020 11:18:33 +0800 Subject: RFR 8246640: @systemproperty should be @systemProperty in java.security.jgss Message-ID: <68468BF5-FE73-4F2B-8140-ABB0CB5519CA@oracle.com> Please review the patch below. The tag name should be camelCased. diff --git a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java --- a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java +++ b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java @@ -106,7 +106,7 @@ * *

If the input name does not contain a realm, the default realm * is used. The default realm can be specified either in a Kerberos - * configuration file or via the {@systemproperty java.security.krb5.realm} + * configuration file or via the {@systemProperty java.security.krb5.realm} * system property. For more information, see the * {@extLink security_guide_jgss_tutorial Kerberos Requirements}. * @@ -155,7 +155,7 @@ * *

If the input name does not contain a realm, the default realm * is used. The default realm can be specified either in a Kerberos - * configuration file or via the {@systemproperty java.security.krb5.realm} + * configuration file or via the {@systemProperty java.security.krb5.realm} * system property. For more information, see the * {@extLink security_guide_jgss_tutorial Kerberos Requirements}. * Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivangi.g.gupta at oracle.com Fri Jun 5 03:41:01 2020 From: shivangi.g.gupta at oracle.com (shivangi.g.gupta at oracle.com) Date: Fri, 5 Jun 2020 09:11:01 +0530 Subject: RFR:8246330:Add TLS Tests for Legacy ECDSA curves In-Reply-To: <6aa9a1aa-cf2a-b806-1b57-b223752751d8@oracle.com> References: <6aa9a1aa-cf2a-b806-1b57-b223752751d8@oracle.com> Message-ID: <640f6f35-6ba7-81f6-92cf-b2838a98ca1c@oracle.com> Corrected the links. On 04/06/20 10:59 pm, shivangi.g.gupta at oracle.com wrote: > > Hi, > > May I please find a sponsor for this patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246330 > > Description:Many of EC named curves has been disabled with security > property "jdk.disabled.namedCurves". The purpose of this Test is to > verify the behavior of any EC named curve from the disabled list. > This Test will address a single name from the disabled list as sect283r1. > > > Webrev: http://cr.openjdk.java.net/~sshivang/reviews/8246330/webrev.00/ > > The patch has been tested on mach5, and the individual test was passed. > > Thanks > > Shivangi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Jun 5 03:41:55 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 5 Jun 2020 11:41:55 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> Message-ID: Hi Alexey, It's so unfortunate that different addressType must be used. I'm OK with the new TlsChannelBindingImpl class. One thing I'm not comfortable is the java.security.sasl/share/classes/module-info.java change. We've struggled hard to avoid these kind of secret tunnels. Is it possible to pass the tlsCB.getData() directly to the SASL mechanism? The property name is clear enough to avoid any misuse. Another question: can an application user set the "com.sun.security.sasl.tlschannelbinding" property? and can they read it after it's set internally? I cannot think of a good attack now but at least it seems they have no need to access that property value. If we keep it internal then we also have the chance to modify the approach later. Thanks, Max > On Jun 5, 2020, at 2:15 AM, Alexey Bakhtin wrote: > > Hello, > > Could you please review new version of the patch: > http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v3/ > > I?ve moved all logic for creating TLS Channel Binding data out of GssKrb5Client.java file. > All data is prepared inside TlsChannelBinding class. > Internal property name is renamed to ?com.sun.security.sasl.tlschannelbinding?. > TlsChannelBinding object is still used to pass channel binding data from LdapClient to GssKrb5Client. > I do not change it to byte[] because of TlsChannelBinding class is still used for internal property name. > Also, I?ve updated TlsChannelBinding class to select SHA-256 hash algorithm if it can not be derived > from the certificate signature name. > > Regards > Alexey > > >> On 26 May 2020, at 17:50, Weijun Wang wrote: >> >> I have a question on GssKrb5Client.java: >> >> Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. >> >> From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. >> >> Thanks, >> Max >> >>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >>> >>> Hello, >>> >>> Could you please review the following patch: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >>> >>> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >>> (based on the TLS server certificate). The channel binding data is calculated as following : >>> ? The client calculates a hash of the TLS server certificate. >>> The hash algorithm is selected on the base of the certificate signature algorithm. >>> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >>> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >>> ? initiator and acceptor addresses should be set to NULL >>> ? initiator and acceptor address types should be zero. >>> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >>> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >>> instead of GSS_C_AF_UNSPEC=0x00. >>> >>> This patch introduces changes in the LDAP, SASL and JGSS modules >>> to generate channel binding data automatically if requested by an application. >>> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >>> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >>> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >>> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >>> Right now "tls-server-end-point" Channel Binding type is supported only. >>> The client extracts server certificate from the underlying TLS connection and creates >>> Channel Binding data for JGSS/Kerberos authentication if application indicates >>> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >>> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >>> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >>> >>> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >>> >>> [2] - >>> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >>> >>> Initial discussion of this issue is available at security-dev list: >>> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html > From david.holmes at oracle.com Fri Jun 5 04:35:50 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Jun 2020 14:35:50 +1000 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> Message-ID: <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> Hi Simon, On 4/06/2020 11:35 pm, Simon Tooke wrote: > Hello, David, and thanks for the review! > > I've responded to your comments below, and intend to post a new patch > for review today or tomorrow. > > Thanks again, > > -Simon > > On 2020-06-03 2:06 a.m., David Holmes wrote: >> Hi Simon, >> >> On 23/05/2020 12:04 am, Sean Mullan wrote: >>> Cross-posting to hotspot-dev for additional review since the code >>> changes are in hotspot. >>> >>> --Sean >>> >>> On 5/21/20 1:24 PM, Simon Tooke wrote: >>>> Hello, >>>> >>>> I'd like to request a review for: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/00/00/ >>>> >>>> This change implements the given intrinsics on Windows. >>>> >>>> The Windows toolchain has no 128 bit integer types, and no inline >>>> asm (on x64 and Arm).? In addition, 'long' is 4 bytes, not 8, as it >>>> is with gcc.? This patch had to change some of the linux >>>> implementation to account for these limitations. >> >> I can't really comment on the intrinsics themselves but a couple of >> suggestions: >> >> - use explicitly sized types e.g. uint64_t instead of unsigned long long > > Yes, this hurt to type.? A previous review suggested using julong, is > that acceptable to you? j* types should only be used when dealing with values that come from or go to Java. Obviously julong is a misnomer as Java doesn't have an unsigned type, but in general this is something we are trying to fix up in the codebase. If these arrays are extracted from Java arrays then using a j* type would be appropriate, but then I would expect jlong, unless the algorithm explicitly requires unsigned types? If so julong would be acceptable. > (an aside: I'm now wondering if there is other code in the JDK that > assumes long is 64bits - which is not true on all platforms...) There has been such code, but hopefully there is no remaining actively used code with that bug. There are using of "long" that should be eradicated (there's an open JBS issue for that as I recall) but the remaining uses don't seem to require the long be 64-bit. >> - use the existing NOINLINE macro for the _declspec(noinline) > Thanks, will do. >> >> The conditional compilation in this code has me quite confused. >> Looking at the existing code we have: >> >> 3680 #ifndef _WINDOWS >> 3681 >> 3682 #define ASM_SUBTRACT >> 3683 >> 3684 #ifdef ASM_SUBTRACT >> ... >> 3702 #else // ASM_SUBTRACT >> ... >> 3719 #endif // ! ASM_SUBTRACT >> >> So all the above code is only built on not-Windows, and we >> unconditionally define ASM_SUBTRACT, so lines 3702 to 3719 appear to >> be dead code! I'm not at all sure whether that is actually a bug and >> the windows ifndef should have had an endif after line 3682; or >> whether we can just simplify the code. > The dead code existed prior to this patch, so I wasn't proposing > removing it.? I'm happy to do so if that's for the best.? As far as I > can tell, it's for implementing these intrinsics on gcc platforms > without assembler. AFAICS Andrew originally had the ASM_SUBTRACT parts, with the unconditional #define, but there was no explanation in the review thread as to why the unused code remained present. Then before integration all the code was wrapped by the ifndef Windows to exclude it from Windows. I think it needs to be fixed as you are making changes to the Windows part and it is very hard to establish how the dead code should look in that case. Thanks, David >> >> Thanks, >> David >> >>>> >>>> My gratitude for Andrew Haley for doing the heavy lifting at the >>>> core of this patch. >>>> >>>> The patch, if accepted, will be offered to 11u as a potential >>>> backport. The changes apply cleanly modulo some line number changes. >>>> >>>> As for the speedup, this test case: >>>> >>>> BigInteger base = BigInteger.ONE.shiftLeft(1024); >>>> long count = LongStream.rangeClosed(2, 100_000) >>>> ???? .mapToObj(n -> BigInteger.valueOf(n).add(base)) >>>> ???? .filter(i -> i.isProbablePrime(50)) >>>> ???? .count(); >>>> >>>> goes from 1 minute 20 seconds down to about 35 seconds om my VM, >>>> over multiple runs.? As is the case on other platforms where the >>>> intrinsics are supported, they will be enabled by default on Windows. >>>> >>>> Thank you for your time, >>>> >>>> -Simon Tooke >>>> >>>> >>>> Principal Software Engineer, >>>> >>>> Red Hat Canada >>>> >>>> >>>> >> > From prasadarao.koppula at oracle.com Fri Jun 5 05:44:18 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Thu, 4 Jun 2020 22:44:18 -0700 (PDT) Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> Message-ID: Hi, Looks good to me, one question If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? Thanks, Prasad.K >-----Original Message----- >From: Valerie Peng >Sent: Friday, June 5, 2020 2:52 AM >To: security-dev at openjdk.java.net >Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >based on registration ordering > >Hi, Sean, > >Thanks for the review and feedback. Webrev updated: >http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ > >getTypeAndAlgorithm(...) was not static due to an instance variable used by >debugging output. I have removed it and made both method static. > >I will wait for others' review comments also. > >Thanks, >Valerie >On 6/4/2020 2:01 PM, Sean Mullan wrote: >> On 6/4/20 3:34 PM, Valerie Peng wrote: >>> Hi, >>> >>> Could someone help reviewing this fix? This change keep tracks of the >>> first registered SecureRandom algorithm and returns it upon the >>> request of SecureRandom class. >> >> This looks good to me. I would recommend that Max or someone else >> review it as well. >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >> >> A couple of minor comments, feel free to fix or ignore. >> >> * SecureRandom.java >> >> 879???????????? // For SUN provider, we use >> SunEntries.DEFF_SECURE_RANDOM_ALGO >> >> Might as well fix the typo while you are in there: s/DEFF/DEF/ >> >> * Provider.java >> >> 1156???? private String parseSecureRandomPut(String name, String >> value) { >> >> Could be static if you also make getTypeAndAlgorithm static, I think. >> >> --Sean From xuelei.fan at oracle.com Fri Jun 5 05:55:14 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 4 Jun 2020 22:55:14 -0700 Subject: RFR 8246640: @systemproperty should be @systemProperty in java.security.jgss In-Reply-To: <68468BF5-FE73-4F2B-8140-ABB0CB5519CA@oracle.com> References: <68468BF5-FE73-4F2B-8140-ABB0CB5519CA@oracle.com> Message-ID: <4436ad6f-eb46-b162-625c-2c0d5cc0ef0f@oracle.com> Looks good to me. Xuelei On 6/4/2020 8:18 PM, Weijun Wang wrote: > Please review the patch below. The tag name should be camelCased. > > *diff --git > a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java > b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java* > *--- > a/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java* > *+++ > b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java* > @@ -106,7 +106,7 @@ > ? ? ? * > ? ? ? *

If the input name does not contain a realm, the default realm > ? ? ? * is used. The default realm can be specified either in a Kerberos > - ? ? * configuration file or via the {@systemproperty > java.security.krb5.realm} > + ? ? * configuration file or via the {@systemProperty > java.security.krb5.realm} > ? ? ? * system property. For more information, see the > ? ? ? * {@extLink security_guide_jgss_tutorial Kerberos Requirements}. > ? ? ? * > @@ -155,7 +155,7 @@ > ? ? ? * > ? ? ? *

If the input name does not contain a realm, the default realm > ? ? ? * is used. The default realm can be specified either in a Kerberos > - ? ? * configuration file or via the {@systemproperty > java.security.krb5.realm} > + ? ? * configuration file or via the {@systemProperty > java.security.krb5.realm} > ? ? ? * system property. For more information, see the > ? ? ? * {@extLink security_guide_jgss_tutorial Kerberos Requirements}. > ? ? ? * > > Thanks, > Max > From jamil.j.nimeh at oracle.com Fri Jun 5 05:55:50 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 4 Jun 2020 22:55:50 -0700 Subject: RFR JDK-8239950: Update PKCS9 Attributes to PKCS#9 v2.0 Encodings Message-ID: <424dd805-c3f6-f1de-eee9-0809364e31af@oracle.com> Hello all, This brings a few PKCS#9 attributes (unstructuredName, unstructuredAddress, signingTime) into line with v2.0 of the spec (RFC 2985).? It mostly expands the allowed string or date types for these attributes.? I also came across a corner-case bug where toString calls on PKCS9Attribute objects were throwing NPE if the attribute type was a UniversalString, so that is addressed in this webrev too. Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.01 JBS: https://bugs.openjdk.java.net/browse/JDK-8239950 --Jamil From aph at redhat.com Fri Jun 5 09:02:59 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Jun 2020 10:02:59 +0100 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> Message-ID: <6522bd5e-0a8e-b858-8cba-9ab51ff712a6@redhat.com> On 05/06/2020 05:35, David Holmes wrote: > If these arrays are extracted from Java arrays Yes, they are. > then using a j* type would be appropriate, but then I would expect > jlong, unless the algorithm explicitly requires unsigned types? It does. All of the code handling bignums uses unsigned words. > If so julong would be acceptable. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sean.coffey at oracle.com Fri Jun 5 09:04:52 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Jun 2020 10:04:52 +0100 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> Message-ID: <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> I share the same concern. clone() is a heavy weight operation in constructors that can be called alot during intensive crypto operations. Now that you've done work on Delegate class - why not also keep the (instanceof Cloneable) test ? That can serve as your fastpath for the default JDK configuration AFAIK. regards, Sean. On 05/06/2020 00:16, Weijun Wang wrote: > >> ? 2020?6?5??03:19?Valerie Peng ??? >> >>> Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? >> Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? > No. > > I understand this case, but this has already been fixed. Is there any other example? Or are you only follow the words in the spec? i.e. try clone() to see if it?s cloneable. > > I am worried that try clone() is much heavier than just check instanof Cloneable. > > Thanks, > Max From weijun.wang at oracle.com Fri Jun 5 13:13:08 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 5 Jun 2020 21:13:08 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: <153262fa-ef95-2df2-4d76-1f1ff4bf37d5@oracle.com> References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> <02591481-F24B-49F6-96D0-35EC2EFB4ADC@oracle.com> <2e2c3b28-572e-4561-ff38-c1415b23f1d2@oracle.com> <44B6310A-32AC-4C03-B745-ACAEFB2BD170@oracle.com> <153262fa-ef95-2df2-4d76-1f1ff4bf37d5@oracle.com> Message-ID: Looks fine to me. Thanks, Max > On Jun 5, 2020, at 8:53 AM, sha.jiang at oracle.com wrote: > > Hi Max > Please review this webrev: > http://cr.openjdk.java.net/~jjiang/8244683/webrev.05/ > > - TimestampCheck.java > The codes in those private methods in Interceptor are merged into > getRespParam(). > > - TsaParam.java > Group the fields as signing internals and TSA fields. > > - TsaSigner.java > parseRequestParam() and createResponse() are private now. > > Best regards, > John Jiang > > On 2020/6/4 22:18, Weijun Wang wrote: >> OK. Please go on. No other comment. >> >>> On Jun 4, 2020, at 12:02 AM, sha.jiang at oracle.com wrote: >>> >>>> Can we make them internal at the moment until someone really need to extend it? >>> Yes, we can. >>> But as a test lib, is it bad to think about a bit further? >> But think about it carefully when there are new requirements. It's probably not a good idea to make every method overridable at the beginning and say do whatever you want. >> >> Thanks, >> Max >> From weijun.wang at oracle.com Fri Jun 5 14:54:15 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 5 Jun 2020 22:54:15 +0800 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> Message-ID: I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. Unfortunately there is no ConcurrentLinkedHashMap. --Max > On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: > > Hi, > > Looks good to me, one question > > If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? > > Thanks, > Prasad.K > >> -----Original Message----- >> From: Valerie Peng >> Sent: Friday, June 5, 2020 2:52 AM >> To: security-dev at openjdk.java.net >> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >> based on registration ordering >> >> Hi, Sean, >> >> Thanks for the review and feedback. Webrev updated: >> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >> >> getTypeAndAlgorithm(...) was not static due to an instance variable used by >> debugging output. I have removed it and made both method static. >> >> I will wait for others' review comments also. >> >> Thanks, >> Valerie >> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>> Hi, >>>> >>>> Could someone help reviewing this fix? This change keep tracks of the >>>> first registered SecureRandom algorithm and returns it upon the >>>> request of SecureRandom class. >>> >>> This looks good to me. I would recommend that Max or someone else >>> review it as well. >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>> >>> A couple of minor comments, feel free to fix or ignore. >>> >>> * SecureRandom.java >>> >>> 879 // For SUN provider, we use >>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>> >>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>> >>> * Provider.java >>> >>> 1156 private String parseSecureRandomPut(String name, String >>> value) { >>> >>> Could be static if you also make getTypeAndAlgorithm static, I think. >>> >>> --Sean From prasadarao.koppula at oracle.com Fri Jun 5 15:03:17 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Fri, 5 Jun 2020 08:03:17 -0700 (PDT) Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> Message-ID: <212fd322-ce62-41b4-8c43-3fbf2bc23a65@default> >-----Original Message----- >From: Weijun Wang >Sent: Friday, June 5, 2020 8:24 PM >To: Prasadrao Koppula >Cc: Valerie Peng ; security-dev at openjdk.java.net >Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >based on registration ordering > >I don't know who in this world would want to do that, but Prasad's concern is >technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, >and new SecureRandom() fails with >"java.security.NoSuchAlgorithmException: a SecureRandom not available". I too agree, users may not do this. But technically it causes exception in the flow. > >And people can also remove one entry and add it back in order to move it to >the end. One can even add new implementations this way. > >Unfortunately there is no ConcurrentLinkedHashMap. Yes Max, I'm fine with current approach, if refresh at remove costs performance hit. Thanks, Prasad.K > >--Max > >> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula > wrote: >> >> Hi, >> >> Looks good to me, one question >> >> If first registered SecureRandom algo gets removed, >getDefaultSecureRandomAlgorithm return stale data, a refresh required in >remove? >> >> Thanks, >> Prasad.K >> >>> -----Original Message----- >>> From: Valerie Peng >>> Sent: Friday, June 5, 2020 2:52 AM >>> To: security-dev at openjdk.java.net >>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom >>> algo based on registration ordering >>> >>> Hi, Sean, >>> >>> Thanks for the review and feedback. Webrev updated: >>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>> >>> getTypeAndAlgorithm(...) was not static due to an instance variable >>> used by debugging output. I have removed it and made both method >static. >>> >>> I will wait for others' review comments also. >>> >>> Thanks, >>> Valerie >>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>> Hi, >>>>> >>>>> Could someone help reviewing this fix? This change keep tracks of >>>>> the first registered SecureRandom algorithm and returns it upon the >>>>> request of SecureRandom class. >>>> >>>> This looks good to me. I would recommend that Max or someone else >>>> review it as well. >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>> >>>> A couple of minor comments, feel free to fix or ignore. >>>> >>>> * SecureRandom.java >>>> >>>> 879 // For SUN provider, we use >>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>> >>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>> >>>> * Provider.java >>>> >>>> 1156 private String parseSecureRandomPut(String name, String >>>> value) { >>>> >>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>> >>>> --Sean > From alexey at azul.com Fri Jun 5 15:03:10 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 5 Jun 2020 15:03:10 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> Message-ID: Hello Max, Thank you a lot for review. Could you check the new version of the patch : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ I?ve made the following changes: - TlsChannelBinding class is moved to java.naming module. java.security.sasl module is not affected any more - I pass tlsCB.getData() directly to the SASL mechanism as you suggested - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: - LdapClient verifies if internal property is not set - GssKrb5Client uses props.remove() to read and remove internal property Regards Alexey > On 5 Jun 2020, at 06:41, Weijun Wang wrote: > > Hi Alexey, > > It's so unfortunate that different addressType must be used. I'm OK with the new TlsChannelBindingImpl class. > > One thing I'm not comfortable is the java.security.sasl/share/classes/module-info.java change. We've struggled hard to avoid these kind of secret tunnels. Is it possible to pass the tlsCB.getData() directly to the SASL mechanism? The property name is clear enough to avoid any misuse. > > Another question: can an application user set the "com.sun.security.sasl.tlschannelbinding" property? and can they read it after it's set internally? I cannot think of a good attack now but at least it seems they have no need to access that property value. If we keep it internal then we also have the chance to modify the approach later. > > Thanks, > Max > > >> On Jun 5, 2020, at 2:15 AM, Alexey Bakhtin wrote: >> >> Hello, >> >> Could you please review new version of the patch: >> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v3/ >> >> I?ve moved all logic for creating TLS Channel Binding data out of GssKrb5Client.java file. >> All data is prepared inside TlsChannelBinding class. >> Internal property name is renamed to ?com.sun.security.sasl.tlschannelbinding?. >> TlsChannelBinding object is still used to pass channel binding data from LdapClient to GssKrb5Client. >> I do not change it to byte[] because of TlsChannelBinding class is still used for internal property name. >> Also, I?ve updated TlsChannelBinding class to select SHA-256 hash algorithm if it can not be derived >> from the certificate signature name. >> >> Regards >> Alexey >> >> >>> On 26 May 2020, at 17:50, Weijun Wang wrote: >>> >>> I have a question on GssKrb5Client.java: >>> >>> Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. >>> >>> From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. >>> >>> Thanks, >>> Max >>> >>>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >>>> >>>> Hello, >>>> >>>> Could you please review the following patch: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >>>> >>>> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >>>> (based on the TLS server certificate). The channel binding data is calculated as following : >>>> ? The client calculates a hash of the TLS server certificate. >>>> The hash algorithm is selected on the base of the certificate signature algorithm. >>>> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >>>> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >>>> ? initiator and acceptor addresses should be set to NULL >>>> ? initiator and acceptor address types should be zero. >>>> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >>>> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >>>> instead of GSS_C_AF_UNSPEC=0x00. >>>> >>>> This patch introduces changes in the LDAP, SASL and JGSS modules >>>> to generate channel binding data automatically if requested by an application. >>>> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >>>> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >>>> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >>>> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >>>> Right now "tls-server-end-point" Channel Binding type is supported only. >>>> The client extracts server certificate from the underlying TLS connection and creates >>>> Channel Binding data for JGSS/Kerberos authentication if application indicates >>>> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >>>> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >>>> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >>>> >>>> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >>>> >>>> [2] - >>>> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >>>> >>>> Initial discussion of this issue is available at security-dev list: >>>> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From anders.rundgren.net at gmail.com Fri Jun 5 15:05:28 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 5 Jun 2020 17:05:28 +0200 Subject: Backporting EdDSA support to JDK-11 Message-ID: <77155780-0aad-28ab-87db-a41d1d2ad9b6@gmail.com> Hi JDK maintainers, I must admit that I know very little about the policies for backporting and upgrading LTS versions of JDK but EdDSA is mainstream these days. https://openjdk.java.net/jeps/339 Any suggestions would be welcome! thanx, Anders From daniel.fuchs at oracle.com Fri Jun 5 15:17:42 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 5 Jun 2020 16:17:42 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> Message-ID: <85417480-7ecd-21d9-fb59-ff3d9a442360@oracle.com> Hi Alexey, Could we move the new code from LdapClient.java and LdapCtxt.java into the com.sun.jndi.ldap.sasl package, and possibly delay its execution until the com.sun.jndi.ldap.sasl.LdapSasl.saslBind method is called? The new TlsChannelBinding class should also be preferably moved to com.sun.jndi.ldap.sasl since it's apparently only useful with SASL. Also: 2573 if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { 2574 throw new UnsupportedOperationException( "Channel binding type " + 2575 TlsChannelBindingType.TLS_UNIQUE.getName() + 2576 " is not supported"); 2577 } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { 2578 if (connectTimeout == -1) 2579 throw new IllegalStateException(CHANNEL_BINDING_TYPE + " property requires " + 2580 CONNECT_TIMEOUT + " property is set."); 2581 cbType = TlsChannelBindingType.TLS_SERVER_END_POINT; 2582 } else { 2583 throw new IllegalArgumentException("Illegal value for " + 2584 CHANNEL_BINDING_TYPE + " property."); 2585 } is not correct - as IllegalArgumentException, IllegalStateException and UnsupportedOperationException will percolate up to the calling code, and are not documented at the public API level. These should really be NamingException. best regards, -- daniel On 05/06/2020 16:03, Alexey Bakhtin wrote: > Hello Max, > > Thank you a lot for review. > > Could you check the new version of the patch : > http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ > > I?ve made the following changes: > - TlsChannelBinding class is moved to java.naming module. > java.security.sasl module is not affected any more > - I pass tlsCB.getData() directly to the SASL mechanism as you suggested > - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: > - LdapClient verifies if internal property is not set > - GssKrb5Client uses props.remove() to read and remove internal property > > Regards > Alexey From sean.coffey at oracle.com Fri Jun 5 15:18:08 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 5 Jun 2020 16:18:08 +0100 Subject: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test In-Reply-To: <26ba099b-c324-4492-abfc-ad454041382a@default> References: <26ba099b-c324-4492-abfc-ad454041382a@default> Message-ID: <8e1461b5-69d0-ec6f-9681-5992972bec87@oracle.com> Looks like the right approach to me Prasad. Reviewed. regards, Sean. On 04/06/2020 16:13, Prasadrao Koppula wrote: > > Hi, > > Could you please review this patch. For timeout/interrupts, JDK11u+ > releases, SSLSocket:getSession behavior is different, compare to > JDK8u. i.e, connection is in open state for timeout/interrupts > exception. For comparability reasons, this fix will close connection > for getSession timeout/ interrupts. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246031 > > Webrev: http://cr.openjdk.java.net/~pkoppula/8246031/webrev.00/ > > Thanks, > > Prasad.K > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Fri Jun 5 16:33:57 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 5 Jun 2020 16:33:57 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <85417480-7ecd-21d9-fb59-ff3d9a442360@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <85417480-7ecd-21d9-fb59-ff3d9a442360@oracle.com> Message-ID: <4F4BA16D-C9A4-46DD-A9A9-979E35431600@azul.com> Hi Daniel, Thank you for review Yes, I can move TlsChannelBinding class into the com.sun.jndi.ldap.sasl package and LdapClient related changes into the LdapSasl.saslBind method. Also, you are right with exceptions. I will rename them to the NamingException. However, I?d like to parse TLS Channel Binding property in the LdapCtx class. The reason is ?com.sun.jndi.ldap.connect.timeout? property. This property should be set together with TLS Channel Binding. So, I?d like to verify if both properties are set before connection is started. The best place for it is LdapCtx.initEnv() Is it acceptable ? Thank you Alexey > On 5 Jun 2020, at 18:17, Daniel Fuchs wrote: > > Hi Alexey, > > Could we move the new code from LdapClient.java and LdapCtxt.java > into the com.sun.jndi.ldap.sasl package, and possibly delay > its execution until the com.sun.jndi.ldap.sasl.LdapSasl.saslBind > method is called? > > The new TlsChannelBinding class should also be preferably moved > to com.sun.jndi.ldap.sasl since it's apparently only useful > with SASL. > > Also: > > 2573 if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { > 2574 throw new UnsupportedOperationException( "Channel binding type " + > 2575 TlsChannelBindingType.TLS_UNIQUE.getName() + > 2576 " is not supported"); > 2577 } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { > 2578 if (connectTimeout == -1) > 2579 throw new IllegalStateException(CHANNEL_BINDING_TYPE + " property requires " + > 2580 CONNECT_TIMEOUT + " property is set."); > 2581 cbType = TlsChannelBindingType.TLS_SERVER_END_POINT; > 2582 } else { > 2583 throw new IllegalArgumentException("Illegal value for " + > 2584 CHANNEL_BINDING_TYPE + " property."); > 2585 } > > is not correct - as IllegalArgumentException, IllegalStateException and UnsupportedOperationException will percolate up to the calling code, and > are not documented at the public API level. > These should really be NamingException. > > best regards, > > -- daniel > > > > On 05/06/2020 16:03, Alexey Bakhtin wrote: >> Hello Max, >> Thank you a lot for review. >> Could you check the new version of the patch : >> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >> I?ve made the following changes: >> - TlsChannelBinding class is moved to java.naming module. >> java.security.sasl module is not affected any more >> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >> - LdapClient verifies if internal property is not set >> - GssKrb5Client uses props.remove() to read and remove internal property >> Regards >> Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From daniel.fuchs at oracle.com Fri Jun 5 16:45:30 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 5 Jun 2020 17:45:30 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <4F4BA16D-C9A4-46DD-A9A9-979E35431600@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <85417480-7ecd-21d9-fb59-ff3d9a442360@oracle.com> <4F4BA16D-C9A4-46DD-A9A9-979E35431600@azul.com> Message-ID: <72e50735-e5e1-08d7-f1bf-dfbd340841bb@oracle.com> Hi Alexey, On 05/06/2020 17:33, Alexey Bakhtin wrote: > Hi Daniel, > > Thank you for review > Yes, I can move TlsChannelBinding class into the com.sun.jndi.ldap.sasl package and LdapClient related changes into the LdapSasl.saslBind method. > Also, you are right with exceptions. I will rename them to the NamingException. > > However, I?d like to parse TLS Channel Binding property in the LdapCtx class. The reason is ?com.sun.jndi.ldap.connect.timeout? property. This property should be set together with TLS Channel Binding. So, I?d like to verify if both properties are set before connection is started. The best place for it is LdapCtx.initEnv() > Is it acceptable ? Yes - I am OK with that. Also - you will need a test. Ideally we'd want a test that verifies that setting the new property works as expected. Best regards, -- daniel > > Thank you > Alexey From valerie.peng at oracle.com Fri Jun 5 18:00:32 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 5 Jun 2020 11:00:32 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> Message-ID: Right, I try to keep the impl simple as I am not aware of any property removal usage. Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added. Valerie On 6/5/2020 7:54 AM, Weijun Wang wrote: > I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". > > And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. > > Unfortunately there is no ConcurrentLinkedHashMap. > > --Max > >> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: >> >> Hi, >> >> Looks good to me, one question >> >> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? >> >> Thanks, >> Prasad.K >> >>> -----Original Message----- >>> From: Valerie Peng >>> Sent: Friday, June 5, 2020 2:52 AM >>> To: security-dev at openjdk.java.net >>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >>> based on registration ordering >>> >>> Hi, Sean, >>> >>> Thanks for the review and feedback. Webrev updated: >>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>> >>> getTypeAndAlgorithm(...) was not static due to an instance variable used by >>> debugging output. I have removed it and made both method static. >>> >>> I will wait for others' review comments also. >>> >>> Thanks, >>> Valerie >>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>> Hi, >>>>> >>>>> Could someone help reviewing this fix? This change keep tracks of the >>>>> first registered SecureRandom algorithm and returns it upon the >>>>> request of SecureRandom class. >>>> This looks good to me. I would recommend that Max or someone else >>>> review it as well. >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>> A couple of minor comments, feel free to fix or ignore. >>>> >>>> * SecureRandom.java >>>> >>>> 879 // For SUN provider, we use >>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>> >>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>> >>>> * Provider.java >>>> >>>> 1156 private String parseSecureRandomPut(String name, String >>>> value) { >>>> >>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>> >>>> --Sean From hai-may.chao at oracle.com Fri Jun 5 18:25:10 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 5 Jun 2020 11:25:10 -0700 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> Message-ID: <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> Updated webrev - https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ Added one command line -importcert in TrustCert.java. Added createCacerts() in test/lib SecurityTools.java. Thanks, Hai-May > On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: > > > >> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >> >> Hi Max, >> >>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>> >>> The source change looks fine to me. >>> >>> In TrustedCert.java: >>> >>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >> >> This cat() is taken from WealAlg.java. >> >>> >>> - There is no need to recreate root.jks and root.pem. >> >> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. > > I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. > >> >> Please also elaborate your comment about no need to recreate root.jks and root.pem. >> >>> >>> - Why not use -trustcacerts below? >>> >>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >> >> >> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. > > OK. > > Then how about we add a new command before line 155? > > kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); > > This would prove the "-trustcacerts" on line 155 is really useful. > >> >>> >>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >> >> Ok, will change it. >> >>> >>> In TrustedCRL.java: >>> >>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >> >> Same reply as above. > > Same question as above. > >> >>> >>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >> >> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >> >>> >>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >> >> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. > > I meant creating the cacerts in one method, something like > > void createCacerts(String ks, String... crt); > > and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. > > BTW, what does caks.size() == 0 matter here? > > Thanks, > Max > > >> >> Thanks, >> Hai-May >> >> >>> Thanks, >>> Max >>> >>> >>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>> >>>> Hi, >>>> >>>> I?d like to request a review for: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>> >>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>> >>>> Thanks, >>>> Hai-May -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Jun 5 19:03:51 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 5 Jun 2020 15:03:51 -0400 Subject: [RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported In-Reply-To: <0592ee70-37ba-aa3b-7a6b-d441cd829d1b@oracle.com> References: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> <0592ee70-37ba-aa3b-7a6b-d441cd829d1b@oracle.com> Message-ID: <57f7bf2f-90a1-caea-4a72-83ee89eebc45@oracle.com> On 6/3/20 10:45 PM, Anthony Scarpino wrote: > On 6/3/20 3:05 PM, Anthony Scarpino wrote: >> On 6/3/20 9:23 AM, Sean Mullan wrote: >>> On 6/2/20 6:33 PM, Anthony Scarpino wrote: >>>>> "If this signature has been previously initialized with parameters >>>>> (by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link >>>>> #setParameter(String, Object)}) and the underlying signature >>>>> implementation supports returning the parameters as {@code >>>>> AlgorithmParameters}, this method returns the same parameters." >>>> >>>> If we are going to reexamine this, then I would say "previously >>>> initialized" is the wrong wording.? it makes it sound like it only >>>> applies when the signature is reset().?? It should be replaced with >>>> "set", regardless if it is the first op or a reset op. >>> >>> There is no reset() method in Signature. I assume you mean when the >>> sign() or verify() method is complete. >> >> Yeah, too much time staring at Cipher and MD. >> >>> >>> setParameter currently uses the following wording: "Initializes this >>> signature engine with the specified parameter set." >>> >>> I don't see a big difference between the words initialize and set. >>> >>> But if you change the wording here, then you should change it in >>> setParameter as well. >>> >>> --Sean >> >> Since setParameter says "initialized", I think just dropping >> "previously" keeps the same symmetry. >> >> Tony > > updated webrev: > https://cr.openjdk.java.net/~ascarpino/8243424/webrev.02/ Looks good. I assume we have existing tests for this. You should add a noreg-doc label to the bug. --Sean From stooke at redhat.com Fri Jun 5 20:46:22 2020 From: stooke at redhat.com (Simon Tooke) Date: Fri, 5 Jun 2020 16:46:22 -0400 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> Message-ID: <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> Thanks again for the review. As per your and Andrew Haley's comments, I have updated the webrev: - used NOINLINE - used julong - deleted the block of unused code. Please let me know what you think. updated webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/ Thanks, -Simon On 2020-06-05 12:35 a.m., David Holmes wrote: > Hi Simon, > > On 4/06/2020 11:35 pm, Simon Tooke wrote: >> Hello, David, and thanks for the review! >> >> I've responded to your comments below, and intend to post a new patch >> for review today or tomorrow. >> >> Thanks again, >> >> -Simon >> >> On 2020-06-03 2:06 a.m., David Holmes wrote: >>> Hi Simon, >>> >>> On 23/05/2020 12:04 am, Sean Mullan wrote: >>>> Cross-posting to hotspot-dev for additional review since the code >>>> changes are in hotspot. >>>> >>>> --Sean >>>> >>>> On 5/21/20 1:24 PM, Simon Tooke wrote: >>>>> Hello, >>>>> >>>>> I'd like to request a review for: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/00/00/ >>>>> >>>>> This change implements the given intrinsics on Windows. >>>>> >>>>> The Windows toolchain has no 128 bit integer types, and no inline >>>>> asm (on x64 and Arm).? In addition, 'long' is 4 bytes, not 8, as >>>>> it is with gcc.? This patch had to change some of the linux >>>>> implementation to account for these limitations. >>> >>> I can't really comment on the intrinsics themselves but a couple of >>> suggestions: >>> >>> - use explicitly sized types e.g. uint64_t instead of unsigned long >>> long >> >> Yes, this hurt to type.? A previous review suggested using julong, is >> that acceptable to you? > > j* types should only be used when dealing with values that come from > or go to Java. Obviously julong is a misnomer as Java doesn't have an > unsigned type, but in general this is something we are trying to fix > up in the codebase. If these arrays are extracted from Java arrays > then using a j* type would be appropriate, but then I would expect > jlong, unless the algorithm explicitly requires unsigned types? If so > julong would be acceptable. > >> (an aside: I'm now wondering if there is other code in the JDK that >> assumes long is 64bits - which is not true on all platforms...) > > There has been such code, but hopefully there is no remaining actively > used code with that bug. There are using of "long" that should be > eradicated (there's an open JBS issue for that as I recall) but the > remaining uses don't seem to require the long be 64-bit. > >>> - use the existing NOINLINE macro for the _declspec(noinline) >> Thanks, will do. >>> >>> The conditional compilation in this code has me quite confused. >>> Looking at the existing code we have: >>> >>> 3680 #ifndef _WINDOWS >>> 3681 >>> 3682 #define ASM_SUBTRACT >>> 3683 >>> 3684 #ifdef ASM_SUBTRACT >>> ... >>> 3702 #else // ASM_SUBTRACT >>> ... >>> 3719 #endif // ! ASM_SUBTRACT >>> >>> So all the above code is only built on not-Windows, and we >>> unconditionally define ASM_SUBTRACT, so lines 3702 to 3719 appear to >>> be dead code! I'm not at all sure whether that is actually a bug and >>> the windows ifndef should have had an endif after line 3682; or >>> whether we can just simplify the code. >> The dead code existed prior to this patch, so I wasn't proposing >> removing it.? I'm happy to do so if that's for the best.? As far as I >> can tell, it's for implementing these intrinsics on gcc platforms >> without assembler. > > AFAICS Andrew originally had the ASM_SUBTRACT parts, with the > unconditional #define, but there was no explanation in the review > thread as to why the unused code remained present. Then before > integration all the code was wrapped by the ifndef Windows to exclude > it from Windows. > > I think it needs to be fixed as you are making changes to the Windows > part and it is very hard to establish how the dead code should look in > that case. > > Thanks, > David > >>> >>> Thanks, >>> David >>> >>>>> >>>>> My gratitude for Andrew Haley for doing the heavy lifting at the >>>>> core of this patch. >>>>> >>>>> The patch, if accepted, will be offered to 11u as a potential >>>>> backport. The changes apply cleanly modulo some line number changes. >>>>> >>>>> As for the speedup, this test case: >>>>> >>>>> BigInteger base = BigInteger.ONE.shiftLeft(1024); >>>>> long count = LongStream.rangeClosed(2, 100_000) >>>>> ???? .mapToObj(n -> BigInteger.valueOf(n).add(base)) >>>>> ???? .filter(i -> i.isProbablePrime(50)) >>>>> ???? .count(); >>>>> >>>>> goes from 1 minute 20 seconds down to about 35 seconds om my VM, >>>>> over multiple runs.? As is the case on other platforms where the >>>>> intrinsics are supported, they will be enabled by default on Windows. >>>>> >>>>> Thank you for your time, >>>>> >>>>> -Simon Tooke >>>>> >>>>> >>>>> Principal Software Engineer, >>>>> >>>>> Red Hat Canada >>>>> >>>>> >>>>> >>> >> > From weijun.wang at oracle.com Sat Jun 6 00:55:57 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 6 Jun 2020 08:55:57 +0800 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> Message-ID: <41020CAD-1186-4F62-A3BB-B666324039D8@oracle.com> I don't know how complex this is. Will it become another map (set) that needs to be thread-safe and has an order? If this is not a documented spec and just added for compatibility. How about we just keep the current design but inside getDefaultSecureRandomAlgorithm() if firstPrng is not in the map we return another one? --Max > On Jun 6, 2020, at 2:00 AM, Valerie Peng wrote: > > Right, I try to keep the impl simple as I am not aware of any property removal usage. > > Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added. > > Valerie > > On 6/5/2020 7:54 AM, Weijun Wang wrote: >> I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". >> >> And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. >> >> Unfortunately there is no ConcurrentLinkedHashMap. >> >> --Max >> >>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: >>> >>> Hi, >>> >>> Looks good to me, one question >>> >>> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? >>> >>> Thanks, >>> Prasad.K >>> >>>> -----Original Message----- >>>> From: Valerie Peng >>>> Sent: Friday, June 5, 2020 2:52 AM >>>> To: security-dev at openjdk.java.net >>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >>>> based on registration ordering >>>> >>>> Hi, Sean, >>>> >>>> Thanks for the review and feedback. Webrev updated: >>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>> >>>> getTypeAndAlgorithm(...) was not static due to an instance variable used by >>>> debugging output. I have removed it and made both method static. >>>> >>>> I will wait for others' review comments also. >>>> >>>> Thanks, >>>> Valerie >>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>> Hi, >>>>>> >>>>>> Could someone help reviewing this fix? This change keep tracks of the >>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>> request of SecureRandom class. >>>>> This looks good to me. I would recommend that Max or someone else >>>>> review it as well. >>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>> A couple of minor comments, feel free to fix or ignore. >>>>> >>>>> * SecureRandom.java >>>>> >>>>> 879 // For SUN provider, we use >>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>> >>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>> >>>>> * Provider.java >>>>> >>>>> 1156 private String parseSecureRandomPut(String name, String >>>>> value) { >>>>> >>>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>>> >>>>> --Sean From RAJAN.HALADE at ORACLE.COM Sat Jun 6 02:07:54 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Fri, 5 Jun 2020 19:07:54 -0700 Subject: RFR:8246330:Add TLS Tests for Legacy ECDSA curves In-Reply-To: <640f6f35-6ba7-81f6-92cf-b2838a98ca1c@oracle.com> References: <6aa9a1aa-cf2a-b806-1b57-b223752751d8@oracle.com> <640f6f35-6ba7-81f6-92cf-b2838a98ca1c@oracle.com> Message-ID: <7FDD0C33-ECE1-46E5-AC52-00849F2B8CE5@ORACLE.COM> One minor comment - Can you please put try-catch around "(new DisabledCurve()).run();? instead of over for loop? Otherwise test looks good. Thanks, Rajan > On Jun 4, 2020, at 8:41 PM, shivangi.g.gupta at oracle.com wrote: > > Corrected the links. > > On 04/06/20 10:59 pm, shivangi.g.gupta at oracle.com wrote: >> Hi, >> >> May I please find a sponsor for this patch? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8246330 >> >> Description:Many of EC named curves has been disabled with security property "jdk.disabled.namedCurves". The purpose of this Test is to verify the behavior of any EC named curve from the disabled list. >> This Test will address a single name from the disabled list as sect283r1. >> >> >> Webrev: http://cr.openjdk.java.net/~sshivang/reviews/8246330/webrev.00/ >> The patch has been tested on mach5, and the individual test was passed. >> >> Thanks >> >> Shivangi >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Sat Jun 6 02:58:00 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Sat, 6 Jun 2020 10:58:00 +0800 Subject: RFR[15] JDK-8246709: sun/security/tools/jarsigner/TsacertOptionTest.java compilation failed after JDK-8244683 Message-ID: <4c3043c7-fc92-bccd-f9d9-4f84ca66ec30@oracle.com> Hi, This patch takes TsacertOptionTest.java to use TsaServer directly, and removes some unnecessary constructors in TsaServer. Webrev: http://cr.openjdk.java.net/~jjiang/8246709/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8246709 Best regards, John Jiang From valerie.peng at oracle.com Sat Jun 6 03:54:52 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 5 Jun 2020 20:54:52 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> Message-ID: <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> Thanks for reviewing and sharing the feedbacks on webrev.00. In order to support all existing calls for legacy registration for default secure random, I have to revert some of the JDK-7092821 changes and re-introduce the 'legacyStrings' LinkedHashMap. Updated the regression test with removal test for provider using legacy registrations as well. Although removal is supported, this is still not bullet proof as things may not work as expected if a provider registered their impl in both ways, i.e. legacy String pair and Service, and then remove/replace some entries later. Please comment if you really need this scenario to be supported. Although not explicitly documented, I think the intention is to use one or the other, never both. Webrev update: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ Thanks, Valerie On 6/5/2020 11:00 AM, Valerie Peng wrote: > Right, I try to keep the impl simple as I am not aware of any property > removal usage. > > Oh-well, if we have to cater to the removal scenario, then we'd have > to add a List and keep track of ALL secure random algos instead of > only the FIRST one. Alright, I guess it costs for covering all aspect. > But one extra benefit of this is that it should be easy to handle the > future JDK property such as "jdk.securerandom.disabledAlgorithms" if > it were to be added. > > Valerie > > On 6/5/2020 7:54 AM, Weijun Wang wrote: >> I don't know who in this world would want to do that, but Prasad's >> concern is technically possible. I tried 'p.remove("SecureRandom.a")' >> in the new test, and new SecureRandom() fails with >> "java.security.NoSuchAlgorithmException: a SecureRandom not available". >> >> And people can also remove one entry and add it back in order to move >> it to the end. One can even add new implementations this way. >> >> Unfortunately there is no ConcurrentLinkedHashMap. >> >> --Max >> >>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula >>> wrote: >>> >>> Hi, >>> >>> Looks good to me, one question >>> >>> If first registered SecureRandom algo gets removed, >>> getDefaultSecureRandomAlgorithm return stale data, a refresh >>> required in remove? >>> >>> Thanks, >>> Prasad.K >>> >>>> -----Original Message----- >>>> From: Valerie Peng >>>> Sent: Friday, June 5, 2020 2:52 AM >>>> To: security-dev at openjdk.java.net >>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom >>>> algo >>>> based on registration ordering >>>> >>>> Hi, Sean, >>>> >>>> Thanks for the review and feedback. Webrev updated: >>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>> >>>> getTypeAndAlgorithm(...) was not static due to an instance variable >>>> used by >>>> debugging output. I have removed it and made both method static. >>>> >>>> I will wait for others' review comments also. >>>> >>>> Thanks, >>>> Valerie >>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>> Hi, >>>>>> >>>>>> Could someone help reviewing this fix? This change keep tracks of >>>>>> the >>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>> request of SecureRandom class. >>>>> This looks good to me. I would recommend that Max or someone else >>>>> review it as well. >>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>> A couple of minor comments, feel free to fix or ignore. >>>>> >>>>> * SecureRandom.java >>>>> >>>>> 879???????????? // For SUN provider, we use >>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>> >>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>> >>>>> * Provider.java >>>>> >>>>> 1156???? private String parseSecureRandomPut(String name, String >>>>> value) { >>>>> >>>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>>> >>>>> --Sean From valerie.peng at oracle.com Sat Jun 6 04:02:26 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 5 Jun 2020 21:02:26 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> Message-ID: <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> I am merely following the spec's recommendation of trying the clone() for cloneability check. If you both are ok with it and prefer the instanceof check, I can sure reverting back the changes in HmacCore and HandshakeHash classes. Valerie On 6/5/2020 2:04 AM, Se?n Coffey wrote: > I share the same concern. clone() is a heavy weight operation in > constructors that can be called alot during intensive crypto operations. > > Now that you've done work on Delegate class - why not also keep the > (instanceof Cloneable) test ? That can serve as your fastpath for the > default JDK configuration AFAIK. > > regards, > Sean. > > On 05/06/2020 00:16, Weijun Wang wrote: >> >>> ? 2020?6?5??03:19?Valerie Peng ??? >>> >>>> Can you give an example when these 2 rules have different results? >>>> Is this only true for those implementation that directly subclass >>>> MessageDigest? >>> Before this fix, even the Spi impl implements Cloneable the >>> instanceof check will always fail because the wrapper class, i.e. >>> MessageDigest.Delegate does not. However, if you call the clone() >>> (made public by the MessageDigest class), it will succeed because >>> Delegate.clone() checks to see if the spi object implements the >>> Cloneable interface, if yes, it will proceed to call the spi >>> clone(). So, for this scenario, the results are different, e.g. >>> instanceof returns false, but clone() succeeds. This is just one >>> example. Is this what you are asking? >> No. >> >> I understand this case, but this has already been fixed. Is there any >> other example? Or are you only follow the words in the spec? i.e. try >> clone() to see if it?s cloneable. >> >> I am worried that try clone() is much heavier than just check >> instanof Cloneable. >> >> Thanks, >> Max From weijun.wang at oracle.com Sat Jun 6 05:46:32 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 6 Jun 2020 13:46:32 +0800 Subject: RFR[15] JDK-8246709: sun/security/tools/jarsigner/TsacertOptionTest.java compilation failed after JDK-8244683 In-Reply-To: <4c3043c7-fc92-bccd-f9d9-4f84ca66ec30@oracle.com> References: <4c3043c7-fc92-bccd-f9d9-4f84ca66ec30@oracle.com> Message-ID: <24AECE35-1F3F-4F60-AC4F-1C9A179FAACE@oracle.com> Looks fine to me. Thanks, Max > On Jun 6, 2020, at 10:58 AM, sha.jiang at oracle.com wrote: > > Hi, > This patch takes TsacertOptionTest.java to use TsaServer directly, > and removes some unnecessary constructors in TsaServer. > > Webrev: http://cr.openjdk.java.net/~jjiang/8246709/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8246709 > > Best regards, > John Jiang > From weijun.wang at oracle.com Sat Jun 6 05:54:00 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 6 Jun 2020 13:54:00 +0800 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> Message-ID: Is it possible to try "md instanceof Cloneable || md.clone() returns"? Hopefully this is fast enough in most cases and also has the chance to recognize more actually-cloneable ones. I'm also OK with simply using "md instanceof Cloneable". --Max > On Jun 6, 2020, at 12:02 PM, Valerie Peng wrote: > > > I am merely following the spec's recommendation of trying the clone() for cloneability check. > > If you both are ok with it and prefer the instanceof check, I can sure reverting back the changes in HmacCore and HandshakeHash classes. > > Valerie > > On 6/5/2020 2:04 AM, Se?n Coffey wrote: >> I share the same concern. clone() is a heavy weight operation in constructors that can be called alot during intensive crypto operations. >> >> Now that you've done work on Delegate class - why not also keep the (instanceof Cloneable) test ? That can serve as your fastpath for the default JDK configuration AFAIK. >> >> regards, >> Sean. >> >> On 05/06/2020 00:16, Weijun Wang wrote: >>> >>>> ? 2020?6?5??03:19?Valerie Peng ??? >>>> >>>>> Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? >>>> Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? >>> No. >>> >>> I understand this case, but this has already been fixed. Is there any other example? Or are you only follow the words in the spec? i.e. try clone() to see if it?s cloneable. >>> >>> I am worried that try clone() is much heavier than just check instanof Cloneable. >>> >>> Thanks, >>> Max From weijun.wang at oracle.com Sat Jun 6 06:04:25 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 5 Jun 2020 23:04:25 -0700 (PDT) Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> Message-ID: <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. Same for line 80 and line 96 of TrustedCRL.java. Everything else is fine. Thanks, Max > On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: > > Updated webrev - > > https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ > > Added one command line -importcert in TrustCert.java. > Added createCacerts() in test/lib SecurityTools.java. > > Thanks, > Hai-May > > > >> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >> >> >> >>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>> >>> Hi Max, >>> >>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>> >>>> The source change looks fine to me. >>>> >>>> In TrustedCert.java: >>>> >>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>> >>> This cat() is taken from WealAlg.java. >>> >>>> >>>> - There is no need to recreate root.jks and root.pem. >>> >>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >> >> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >> >>> >>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>> >>>> >>>> - Why not use -trustcacerts below? >>>> >>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>> >>> >>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >> >> OK. >> >> Then how about we add a new command before line 155? >> >> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >> >> This would prove the "-trustcacerts" on line 155 is really useful. >> >>> >>>> >>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>> >>> Ok, will change it. >>> >>>> >>>> In TrustedCRL.java: >>>> >>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>> >>> Same reply as above. >> >> Same question as above. >> >>> >>>> >>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>> >>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>> >>>> >>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>> >>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >> >> I meant creating the cacerts in one method, something like >> >> void createCacerts(String ks, String... crt); >> >> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >> >> BTW, what does caks.size() == 0 matter here? >> >> Thanks, >> Max >> >> >>> >>> Thanks, >>> Hai-May >>> >>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>> >>>>> Hi, >>>>> >>>>> I?d like to request a review for: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>> >>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>> >>>>> Thanks, >>>>> Hai-May > From weijun.wang at oracle.com Sat Jun 6 06:41:28 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 6 Jun 2020 14:41:28 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> Message-ID: > On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: > > Hello Max, > > Thank you a lot for review. > > Could you check the new version of the patch : > http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ > > I?ve made the following changes: > - TlsChannelBinding class is moved to java.naming module. > java.security.sasl module is not affected any more > - I pass tlsCB.getData() directly to the SASL mechanism as you suggested > - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: > - LdapClient verifies if internal property is not set 245 // Prepare TLS Channel Binding data 246 if (conn.sock instanceof SSLSocket) { 247 // Internal property cannot be set explicitly 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + 250 " property cannot be set explicitly"); 251 } If not TLS, this property value be kept there and visible inside the SASL mech. > - GssKrb5Client uses props.remove() to read and remove internal property Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. Thanks, Max p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. > > Regards > Alexey > >> On 5 Jun 2020, at 06:41, Weijun Wang wrote: >> >> Hi Alexey, >> >> It's so unfortunate that different addressType must be used. I'm OK with the new TlsChannelBindingImpl class. >> >> One thing I'm not comfortable is the java.security.sasl/share/classes/module-info.java change. We've struggled hard to avoid these kind of secret tunnels. Is it possible to pass the tlsCB.getData() directly to the SASL mechanism? The property name is clear enough to avoid any misuse. >> >> Another question: can an application user set the "com.sun.security.sasl.tlschannelbinding" property? and can they read it after it's set internally? I cannot think of a good attack now but at least it seems they have no need to access that property value. If we keep it internal then we also have the chance to modify the approach later. >> >> Thanks, >> Max >> >> >>> On Jun 5, 2020, at 2:15 AM, Alexey Bakhtin wrote: >>> >>> Hello, >>> >>> Could you please review new version of the patch: >>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v3/ >>> >>> I?ve moved all logic for creating TLS Channel Binding data out of GssKrb5Client.java file. >>> All data is prepared inside TlsChannelBinding class. >>> Internal property name is renamed to ?com.sun.security.sasl.tlschannelbinding?. >>> TlsChannelBinding object is still used to pass channel binding data from LdapClient to GssKrb5Client. >>> I do not change it to byte[] because of TlsChannelBinding class is still used for internal property name. >>> Also, I?ve updated TlsChannelBinding class to select SHA-256 hash algorithm if it can not be derived >>> from the certificate signature name. >>> >>> Regards >>> Alexey >>> >>> >>>> On 26 May 2020, at 17:50, Weijun Wang wrote: >>>> >>>> I have a question on GssKrb5Client.java: >>>> >>>> Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. >>>> >>>> From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. >>>> >>>> Thanks, >>>> Max >>>> >>>>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you please review the following patch: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>>>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >>>>> >>>>> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >>>>> (based on the TLS server certificate). The channel binding data is calculated as following : >>>>> ? The client calculates a hash of the TLS server certificate. >>>>> The hash algorithm is selected on the base of the certificate signature algorithm. >>>>> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >>>>> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >>>>> ? initiator and acceptor addresses should be set to NULL >>>>> ? initiator and acceptor address types should be zero. >>>>> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >>>>> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >>>>> instead of GSS_C_AF_UNSPEC=0x00. >>>>> >>>>> This patch introduces changes in the LDAP, SASL and JGSS modules >>>>> to generate channel binding data automatically if requested by an application. >>>>> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >>>>> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >>>>> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >>>>> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >>>>> Right now "tls-server-end-point" Channel Binding type is supported only. >>>>> The client extracts server certificate from the underlying TLS connection and creates >>>>> Channel Binding data for JGSS/Kerberos authentication if application indicates >>>>> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >>>>> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >>>>> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >>>>> >>>>> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >>>>> >>>>> [2] - >>>>> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >>>>> >>>>> Initial discussion of this issue is available at security-dev list: >>>>> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >>>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >>>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >>>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html >>> > From weijun.wang at oracle.com Sat Jun 6 06:44:55 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 6 Jun 2020 14:44:55 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> Message-ID: <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> > On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: > > > >> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >> >> Hello Max, >> >> Thank you a lot for review. >> >> Could you check the new version of the patch : >> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >> >> I?ve made the following changes: >> - TlsChannelBinding class is moved to java.naming module. >> java.security.sasl module is not affected any more >> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >> - LdapClient verifies if internal property is not set > > 245 // Prepare TLS Channel Binding data > 246 if (conn.sock instanceof SSLSocket) { > 247 // Internal property cannot be set explicitly > 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { > 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + > 250 " property cannot be set explicitly"); > 251 } > > If not TLS, this property value be kept there and visible inside the SASL mech. > >> - GssKrb5Client uses props.remove() to read and remove internal property Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. --Max > > Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. > > > Thanks, > Max > > p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. > >> >> Regards >> Alexey >> >>> On 5 Jun 2020, at 06:41, Weijun Wang wrote: >>> >>> Hi Alexey, >>> >>> It's so unfortunate that different addressType must be used. I'm OK with the new TlsChannelBindingImpl class. >>> >>> One thing I'm not comfortable is the java.security.sasl/share/classes/module-info.java change. We've struggled hard to avoid these kind of secret tunnels. Is it possible to pass the tlsCB.getData() directly to the SASL mechanism? The property name is clear enough to avoid any misuse. >>> >>> Another question: can an application user set the "com.sun.security.sasl.tlschannelbinding" property? and can they read it after it's set internally? I cannot think of a good attack now but at least it seems they have no need to access that property value. If we keep it internal then we also have the chance to modify the approach later. >>> >>> Thanks, >>> Max >>> >>> >>>> On Jun 5, 2020, at 2:15 AM, Alexey Bakhtin wrote: >>>> >>>> Hello, >>>> >>>> Could you please review new version of the patch: >>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v3/ >>>> >>>> I?ve moved all logic for creating TLS Channel Binding data out of GssKrb5Client.java file. >>>> All data is prepared inside TlsChannelBinding class. >>>> Internal property name is renamed to ?com.sun.security.sasl.tlschannelbinding?. >>>> TlsChannelBinding object is still used to pass channel binding data from LdapClient to GssKrb5Client. >>>> I do not change it to byte[] because of TlsChannelBinding class is still used for internal property name. >>>> Also, I?ve updated TlsChannelBinding class to select SHA-256 hash algorithm if it can not be derived >>>> from the certificate signature name. >>>> >>>> Regards >>>> Alexey >>>> >>>> >>>>> On 26 May 2020, at 17:50, Weijun Wang wrote: >>>>> >>>>> I have a question on GssKrb5Client.java: >>>>> >>>>> Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. >>>>> >>>>> From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you please review the following patch: >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>>>>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >>>>>> >>>>>> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >>>>>> (based on the TLS server certificate). The channel binding data is calculated as following : >>>>>> ? The client calculates a hash of the TLS server certificate. >>>>>> The hash algorithm is selected on the base of the certificate signature algorithm. >>>>>> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >>>>>> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >>>>>> ? initiator and acceptor addresses should be set to NULL >>>>>> ? initiator and acceptor address types should be zero. >>>>>> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >>>>>> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >>>>>> instead of GSS_C_AF_UNSPEC=0x00. >>>>>> >>>>>> This patch introduces changes in the LDAP, SASL and JGSS modules >>>>>> to generate channel binding data automatically if requested by an application. >>>>>> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >>>>>> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >>>>>> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >>>>>> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >>>>>> Right now "tls-server-end-point" Channel Binding type is supported only. >>>>>> The client extracts server certificate from the underlying TLS connection and creates >>>>>> Channel Binding data for JGSS/Kerberos authentication if application indicates >>>>>> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >>>>>> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >>>>>> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >>>>>> >>>>>> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >>>>>> >>>>>> [2] - >>>>>> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >>>>>> >>>>>> Initial discussion of this issue is available at security-dev list: >>>>>> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >>>>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >>>>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >>>>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html From turbanoff at gmail.com Sat Jun 6 16:03:01 2020 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sat, 6 Jun 2020 19:03:01 +0300 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration Message-ID: >List.of(KnownOIDs.values()).forEach(o -> { > register(o); >}); I wonder if this 'forEach' is better than plain old 'for' in some ways? ``` for (KnownOIDs oid : KnownOIDs.values()) { register(oid); } ``` I think a variant with plain 'for' generates a bit less garbage. Andrey Turbanov From xuelei.fan at oracle.com Sat Jun 6 16:10:53 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 6 Jun 2020 09:10:53 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> Message-ID: <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> As the the Delegate class takes care of the Cloneable SPI implementation, it should be sufficient to use "md instanceof Cloneable" only. It is not a expected behavior that a provider implements Cloneable but does not really support it. Xuelei On 6/5/2020 10:54 PM, Weijun Wang wrote: > Is it possible to try "md instanceof Cloneable || md.clone() returns"? Hopefully this is fast enough in most cases and also has the chance to recognize more actually-cloneable ones. > > I'm also OK with simply using "md instanceof Cloneable". > > --Max > >> On Jun 6, 2020, at 12:02 PM, Valerie Peng wrote: >> >> >> I am merely following the spec's recommendation of trying the clone() for cloneability check. >> >> If you both are ok with it and prefer the instanceof check, I can sure reverting back the changes in HmacCore and HandshakeHash classes. >> >> Valerie >> >> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>> I share the same concern. clone() is a heavy weight operation in constructors that can be called alot during intensive crypto operations. >>> >>> Now that you've done work on Delegate class - why not also keep the (instanceof Cloneable) test ? That can serve as your fastpath for the default JDK configuration AFAIK. >>> >>> regards, >>> Sean. >>> >>> On 05/06/2020 00:16, Weijun Wang wrote: >>>> >>>>> ? 2020?6?5??03:19?Valerie Peng ??? >>>>> >>>>>> Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? >>>>> Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? >>>> No. >>>> >>>> I understand this case, but this has already been fixed. Is there any other example? Or are you only follow the words in the spec? i.e. try clone() to see if it?s cloneable. >>>> >>>> I am worried that try clone() is much heavier than just check instanof Cloneable. >>>> >>>> Thanks, >>>> Max > From alexey at azul.com Sat Jun 6 19:45:28 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Sat, 6 Jun 2020 19:45:28 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> Message-ID: <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> Hello Max, Daniel, Thank you for review. Please review new version of the patch : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ In this version: - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method - verification and removal of internal property is also moved to LdapSasl.saslBind method - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType The test for this issue is not ready yet. I did not find any suitable test case that can be reused. Thank you Alexey > On 6 Jun 2020, at 09:44, Weijun Wang wrote: > > > >> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >> >> >> >>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>> >>> Hello Max, >>> >>> Thank you a lot for review. >>> >>> Could you check the new version of the patch : >>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>> >>> I?ve made the following changes: >>> - TlsChannelBinding class is moved to java.naming module. >>> java.security.sasl module is not affected any more >>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>> - LdapClient verifies if internal property is not set >> >> 245 // Prepare TLS Channel Binding data >> 246 if (conn.sock instanceof SSLSocket) { >> 247 // Internal property cannot be set explicitly >> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >> 250 " property cannot be set explicitly"); >> 251 } >> >> If not TLS, this property value be kept there and visible inside the SASL mech. >> >>> - GssKrb5Client uses props.remove() to read and remove internal property > > Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. > > --Max > >> >> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >> >> >> Thanks, >> Max >> >> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From weijun.wang at oracle.com Sun Jun 7 01:47:32 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 7 Jun 2020 09:47:32 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> Message-ID: <013290B8-67BE-4CD5-804C-FC882CD23CFE@oracle.com> Some comments: 1. I just noticed your 2 new files are using the plain GPU license, it should be GPL + Classpath. Read another source file for an example. 2. Please add some comments in InitialToken.java on what happens to the default type. 3. I still think "com.sun.security.sasl.tlschannelbinding" sounds like sun.com will support it. 4. If an automatic test is not feasible, please provide some instructions so our SQE can see if we can setup some internal tests. Then we can add noreg-hard with some justification to the test and go on. I cannot comment on LdapCtx.java, but the others look fine to me. Thanks, Max > On Jun 7, 2020, at 3:45 AM, Alexey Bakhtin wrote: > > Hello Max, Daniel, > > Thank you for review. > > Please review new version of the patch : > http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ > > In this version: > - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package > - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method > - verification and removal of internal property is also moved to LdapSasl.saslBind method > - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType > > The test for this issue is not ready yet. I did not find any suitable test case that can be reused. > > Thank you > Alexey > >> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >> >> >> >>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>> >>> >>> >>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>> >>>> Hello Max, >>>> >>>> Thank you a lot for review. >>>> >>>> Could you check the new version of the patch : >>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>> >>>> I?ve made the following changes: >>>> - TlsChannelBinding class is moved to java.naming module. >>>> java.security.sasl module is not affected any more >>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>> - LdapClient verifies if internal property is not set >>> >>> 245 // Prepare TLS Channel Binding data >>> 246 if (conn.sock instanceof SSLSocket) { >>> 247 // Internal property cannot be set explicitly >>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>> 250 " property cannot be set explicitly"); >>> 251 } >>> >>> If not TLS, this property value be kept there and visible inside the SASL mech. >>> >>>> - GssKrb5Client uses props.remove() to read and remove internal property >> >> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >> >> --Max >> >>> >>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>> >>> >>> Thanks, >>> Max >>> >>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. > From hai-may.chao at oracle.com Sun Jun 7 20:01:59 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Sun, 7 Jun 2020 13:01:59 -0700 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> Message-ID: <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> Updated webrev - https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ Thanks, Hai-May > On Jun 5, 2020, at 11:04 PM, Weijun Wang wrote: > > I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. > > Same for line 80 and line 96 of TrustedCRL.java. > > Everything else is fine. > > Thanks, > Max > > >> On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: >> >> Updated webrev - >> >> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >> >> Added one command line -importcert in TrustCert.java. >> Added createCacerts() in test/lib SecurityTools.java. >> >> Thanks, >> Hai-May >> >> >> >>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>> >>> >>> >>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>> >>>> Hi Max, >>>> >>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>> >>>>> The source change looks fine to me. >>>>> >>>>> In TrustedCert.java: >>>>> >>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>> >>>> This cat() is taken from WealAlg.java. >>>> >>>>> >>>>> - There is no need to recreate root.jks and root.pem. >>>> >>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>> >>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>> >>>> >>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>> >>>>> >>>>> - Why not use -trustcacerts below? >>>>> >>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>> >>>> >>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>> >>> OK. >>> >>> Then how about we add a new command before line 155? >>> >>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>> >>> This would prove the "-trustcacerts" on line 155 is really useful. >>> >>>> >>>>> >>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>> >>>> Ok, will change it. >>>> >>>>> >>>>> In TrustedCRL.java: >>>>> >>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>> >>>> Same reply as above. >>> >>> Same question as above. >>> >>>> >>>>> >>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>> >>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>> >>>>> >>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>> >>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>> >>> I meant creating the cacerts in one method, something like >>> >>> void createCacerts(String ks, String... crt); >>> >>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>> >>> BTW, what does caks.size() == 0 matter here? >>> >>> Thanks, >>> Max >>> >>> >>>> >>>> Thanks, >>>> Hai-May >>>> >>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I?d like to request a review for: >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>> >>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>> >>>>>> Thanks, >>>>>> Hai-May >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Jun 8 01:08:38 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 8 Jun 2020 09:08:38 +0800 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> Message-ID: <77CE09E4-0A4F-41D1-A950-9CAF71F2317B@oracle.com> Looks fine to me. For CSR, since there is already a "Note" there for these 2 options, you can add a few words about what -keystore and -trustcacerts can do. Thanks, Max > On Jun 8, 2020, at 4:01 AM, Hai-May Chao wrote: > > Updated webrev - > > https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ > > Thanks, > Hai-May > > >> On Jun 5, 2020, at 11:04 PM, Weijun Wang wrote: >> >> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. >> >> Same for line 80 and line 96 of TrustedCRL.java. >> >> Everything else is fine. >> >> Thanks, >> Max >> >> >>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: >>> >>> Updated webrev - >>> >>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>> >>> Added one command line -importcert in TrustCert.java. >>> Added createCacerts() in test/lib SecurityTools.java. >>> >>> Thanks, >>> Hai-May >>> >>> >>> >>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>>> >>>>> Hi Max, >>>>> >>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>>> >>>>>> The source change looks fine to me. >>>>>> >>>>>> In TrustedCert.java: >>>>>> >>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>>> >>>>> This cat() is taken from WealAlg.java. >>>>> >>>>>> >>>>>> - There is no need to recreate root.jks and root.pem. >>>>> >>>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>>> >>>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>>> >>>>> >>>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>>> >>>>>> >>>>>> - Why not use -trustcacerts below? >>>>>> >>>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>>> >>>>> >>>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>>> >>>> OK. >>>> >>>> Then how about we add a new command before line 155? >>>> >>>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>> >>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>> >>>>> >>>>>> >>>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>>> >>>>> Ok, will change it. >>>>> >>>>>> >>>>>> In TrustedCRL.java: >>>>>> >>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>>> >>>>> Same reply as above. >>>> >>>> Same question as above. >>>> >>>>> >>>>>> >>>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>>> >>>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>>> >>>>>> >>>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>>> >>>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>>> >>>> I meant creating the cacerts in one method, something like >>>> >>>> void createCacerts(String ks, String... crt); >>>> >>>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>>> >>>> BTW, what does caks.size() == 0 matter here? >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I?d like to request a review for: >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>> >>>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>>> >>>>>>> Thanks, >>>>>>> Hai-May >>> >> > From weijun.wang at oracle.com Mon Jun 8 01:14:30 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 8 Jun 2020 09:14:30 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <50C70B50-9B13-4098-B848-C68A68DC895A@oracle.com> References: <50C70B50-9B13-4098-B848-C68A68DC895A@oracle.com> Message-ID: <25B54DF5-9A6C-44CF-9E3A-AF6E4D8B06FE@oracle.com> Ping again. CSR already approved and rdp1 is near... Thanks, Max > On Jun 2, 2020, at 4:07 PM, Weijun Wang wrote: > > Updated again at > > https://cr.openjdk.java.net/~weijun/8242068/webrev.02 > > Major changes this time: > > 1. Use Signed Attributes in generateNewSignedData(direct==false). This means for Ed448 we will use SHAKE256-LEN so there is no interop issue (BTW, BC recently added support to SHAKE256 in 166b07), hence removed the newly added system property in webrev.01. > > 2. Better interop with providers using Ed448 and Ed25519 as key algorithm names. > > Major changes previously: > > 1. Always encode the whole signature algorithm identifier (instead of encryption algorithmid) in PKCS7 SignerInfo. > > 2. New SignatureUtil methods > > Thanks, > Max > >> On May 27, 2020, at 8:21 AM, Weijun Wang wrote: >> >> Webrev updated at >> >> http://cr.openjdk.java.net/~weijun/8242068/webrev.01/ >> >> Two major changes: >> >> 1. Always use the signature algorithm directly in SignerInfo::signatureAlgorithm: >> >> In PKCS7 SignerInfo >> >> SignerInfo ::= SEQUENCE { >> version CMSVersion, >> sid SignerIdentifier, >> digestAlgorithm DigestAlgorithmIdentifier, >> signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, >> signatureAlgorithm SignatureAlgorithmIdentifier, >> signature SignatureValue, >> unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } >> >> We have always been putting "SHA-1" etc into DigestAlgorithmIdentifier, and "RSA", "DSA", "EC" into signatureAlgorithm. >> >> The latest https://tools.ietf.org/html/rfc5652#section-10.1.2 claims it to be >> >> The SignatureAlgorithmIdentifier type identifies a signature >> algorithm, and it can also identify a message digest algorithm. >> Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with >> SHA-256. >> >> It's complicated to always divide a signature algorithm into a digest algorithm and an encryption algorithm (and with the new RSASSA-PSS and EdDSA it's not easy to define it), therefore I decide to use the signature algorithm directly from now on. Fortunately Java has been able to parse this for a very long time so there is no compatibility issue. I noticed BouncyCastle has been doing the same, and OpenSSL too except for RSA. >> >> 2. Support both SHAKE256 and SHAKE256-LEN while parsing a Ed448 SignerInfo. They are both described in https://www.rfc-editor.org/rfc/rfc8419.html although it's a little complicated. To be standard compliant (https://www.rfc-editor.org/rfc/rfc8419.html#section-3.2 and we don't use Signed Attributes), by default Java will use SHAKE256 as the digestAlgorithm. However I noticed BouncyCastle does not recognize it, so if you set the system property "jdk.security.pkcs7.ed448.digalg.haslen" to "true", it will use SHAKE256-LEN (len == 512). I haven't described this system property in the CSR yet. >> >> Thanks, >> Max >> >> >>> On May 22, 2020, at 10:30 PM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> CSR : https://bugs.openjdk.java.net/browse/JDK-8245274 >>> webrev : http://cr.openjdk.java.net/~weijun/8242068/webrev.00/ >>> >>> Major points in CSR: >>> >>> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner >>> >>> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms >>> >>> major code changes: >>> >>> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java >>> >>> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId >>> >>> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing >>> >>> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms >>> >>> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed >>> >>> Next I'll do some basic interop tests with openssl and BouncyCastle. >>> >>> Thanks, >>> Max >>> >> > From david.holmes at oracle.com Mon Jun 8 09:33:23 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Jun 2020 19:33:23 +1000 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> Message-ID: <2b3e7ee7-185e-3140-583f-3c0a39fbe8b5@oracle.com> Hi Simon, On 6/06/2020 6:46 am, Simon Tooke wrote: > Thanks again for the review. > > As per your and Andrew Haley's comments, I have updated the webrev: > > - used NOINLINE > > - used julong > > - deleted the block of unused code. > > Please let me know what you think. > > updated webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/ All my comments have been addressed - thanks. David > Thanks, > > -Simon > > > > On 2020-06-05 12:35 a.m., David Holmes wrote: >> Hi Simon, >> >> On 4/06/2020 11:35 pm, Simon Tooke wrote: >>> Hello, David, and thanks for the review! >>> >>> I've responded to your comments below, and intend to post a new patch >>> for review today or tomorrow. >>> >>> Thanks again, >>> >>> -Simon >>> >>> On 2020-06-03 2:06 a.m., David Holmes wrote: >>>> Hi Simon, >>>> >>>> On 23/05/2020 12:04 am, Sean Mullan wrote: >>>>> Cross-posting to hotspot-dev for additional review since the code >>>>> changes are in hotspot. >>>>> >>>>> --Sean >>>>> >>>>> On 5/21/20 1:24 PM, Simon Tooke wrote: >>>>>> Hello, >>>>>> >>>>>> I'd like to request a review for: >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/00/00/ >>>>>> >>>>>> This change implements the given intrinsics on Windows. >>>>>> >>>>>> The Windows toolchain has no 128 bit integer types, and no inline >>>>>> asm (on x64 and Arm).? In addition, 'long' is 4 bytes, not 8, as >>>>>> it is with gcc.? This patch had to change some of the linux >>>>>> implementation to account for these limitations. >>>> >>>> I can't really comment on the intrinsics themselves but a couple of >>>> suggestions: >>>> >>>> - use explicitly sized types e.g. uint64_t instead of unsigned long >>>> long >>> >>> Yes, this hurt to type.? A previous review suggested using julong, is >>> that acceptable to you? >> >> j* types should only be used when dealing with values that come from >> or go to Java. Obviously julong is a misnomer as Java doesn't have an >> unsigned type, but in general this is something we are trying to fix >> up in the codebase. If these arrays are extracted from Java arrays >> then using a j* type would be appropriate, but then I would expect >> jlong, unless the algorithm explicitly requires unsigned types? If so >> julong would be acceptable. >> >>> (an aside: I'm now wondering if there is other code in the JDK that >>> assumes long is 64bits - which is not true on all platforms...) >> >> There has been such code, but hopefully there is no remaining actively >> used code with that bug. There are using of "long" that should be >> eradicated (there's an open JBS issue for that as I recall) but the >> remaining uses don't seem to require the long be 64-bit. >> >>>> - use the existing NOINLINE macro for the _declspec(noinline) >>> Thanks, will do. >>>> >>>> The conditional compilation in this code has me quite confused. >>>> Looking at the existing code we have: >>>> >>>> 3680 #ifndef _WINDOWS >>>> 3681 >>>> 3682 #define ASM_SUBTRACT >>>> 3683 >>>> 3684 #ifdef ASM_SUBTRACT >>>> ... >>>> 3702 #else // ASM_SUBTRACT >>>> ... >>>> 3719 #endif // ! ASM_SUBTRACT >>>> >>>> So all the above code is only built on not-Windows, and we >>>> unconditionally define ASM_SUBTRACT, so lines 3702 to 3719 appear to >>>> be dead code! I'm not at all sure whether that is actually a bug and >>>> the windows ifndef should have had an endif after line 3682; or >>>> whether we can just simplify the code. >>> The dead code existed prior to this patch, so I wasn't proposing >>> removing it.? I'm happy to do so if that's for the best.? As far as I >>> can tell, it's for implementing these intrinsics on gcc platforms >>> without assembler. >> >> AFAICS Andrew originally had the ASM_SUBTRACT parts, with the >> unconditional #define, but there was no explanation in the review >> thread as to why the unused code remained present. Then before >> integration all the code was wrapped by the ifndef Windows to exclude >> it from Windows. >> >> I think it needs to be fixed as you are making changes to the Windows >> part and it is very hard to establish how the dead code should look in >> that case. >> >> Thanks, >> David >> >>>> >>>> Thanks, >>>> David >>>> >>>>>> >>>>>> My gratitude for Andrew Haley for doing the heavy lifting at the >>>>>> core of this patch. >>>>>> >>>>>> The patch, if accepted, will be offered to 11u as a potential >>>>>> backport. The changes apply cleanly modulo some line number changes. >>>>>> >>>>>> As for the speedup, this test case: >>>>>> >>>>>> BigInteger base = BigInteger.ONE.shiftLeft(1024); >>>>>> long count = LongStream.rangeClosed(2, 100_000) >>>>>> ???? .mapToObj(n -> BigInteger.valueOf(n).add(base)) >>>>>> ???? .filter(i -> i.isProbablePrime(50)) >>>>>> ???? .count(); >>>>>> >>>>>> goes from 1 minute 20 seconds down to about 35 seconds om my VM, >>>>>> over multiple runs.? As is the case on other platforms where the >>>>>> intrinsics are supported, they will be enabled by default on Windows. >>>>>> >>>>>> Thank you for your time, >>>>>> >>>>>> -Simon Tooke >>>>>> >>>>>> >>>>>> Principal Software Engineer, >>>>>> >>>>>> Red Hat Canada >>>>>> >>>>>> >>>>>> >>>> >>> >> > From weijun.wang at oracle.com Mon Jun 8 09:34:36 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 8 Jun 2020 17:34:36 +0800 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> Message-ID: Looks like this should work, but still find it complicated. 1. Do we need to care about thread safety when managing legacyStrings? 2. Does implReplaceAll() need to set legacyChanged = true? 3. How about using prngAlgorithms.iterator().next() below? 1416 return prngAlgorithms.toArray(new String[0])[0]; --Max > On Jun 6, 2020, at 11:54 AM, Valerie Peng wrote: > > Thanks for reviewing and sharing the feedbacks on webrev.00. > > In order to support all existing calls for legacy registration for default secure random, I have to revert some of the JDK-7092821 changes and re-introduce the 'legacyStrings' LinkedHashMap. Updated the regression test with removal test for provider using legacy registrations as well. Although removal is supported, this is still not bullet proof as things may not work as expected if a provider registered their impl in both ways, i.e. legacy String pair and Service, and then remove/replace some entries later. Please comment if you really need this scenario to be supported. Although not explicitly documented, I think the intention is to use one or the other, never both. > > Webrev update: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ > > Thanks, > Valerie > On 6/5/2020 11:00 AM, Valerie Peng wrote: >> Right, I try to keep the impl simple as I am not aware of any property removal usage. >> >> Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added. >> >> Valerie >> >> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>> I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". >>> >>> And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. >>> >>> Unfortunately there is no ConcurrentLinkedHashMap. >>> >>> --Max >>> >>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: >>>> >>>> Hi, >>>> >>>> Looks good to me, one question >>>> >>>> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? >>>> >>>> Thanks, >>>> Prasad.K >>>> >>>>> -----Original Message----- >>>>> From: Valerie Peng >>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>> To: security-dev at openjdk.java.net >>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >>>>> based on registration ordering >>>>> >>>>> Hi, Sean, >>>>> >>>>> Thanks for the review and feedback. Webrev updated: >>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>> >>>>> getTypeAndAlgorithm(...) was not static due to an instance variable used by >>>>> debugging output. I have removed it and made both method static. >>>>> >>>>> I will wait for others' review comments also. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could someone help reviewing this fix? This change keep tracks of the >>>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>>> request of SecureRandom class. >>>>>> This looks good to me. I would recommend that Max or someone else >>>>>> review it as well. >>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>> >>>>>> * SecureRandom.java >>>>>> >>>>>> 879 // For SUN provider, we use >>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>> >>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>> >>>>>> * Provider.java >>>>>> >>>>>> 1156 private String parseSecureRandomPut(String name, String >>>>>> value) { >>>>>> >>>>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>>>> >>>>>> --Sean From aph at redhat.com Mon Jun 8 11:19:59 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Jun 2020 12:19:59 +0100 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> Message-ID: On 05/06/2020 21:46, Simon Tooke wrote: > As per your and Andrew Haley's comments, I have updated the webrev: > > - used NOINLINE > > - used julong > > - deleted the block of unused code. > > Please let me know what you think. > > updated webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/ That looks clean, especially since it adds support for Windows with essentially no impact on the Linux code. I'm not sure I can Review it, though, because I'm one of the co-authors. It'd be nice if someone else familiar with the arithmetic (someone on security-dev?) could take a quick look. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shivangi.g.gupta at oracle.com Mon Jun 8 11:34:04 2020 From: shivangi.g.gupta at oracle.com (shivangi.g.gupta at oracle.com) Date: Mon, 8 Jun 2020 17:04:04 +0530 Subject: RFR:8246330:Add TLS Tests for Legacy ECDSA curves In-Reply-To: <7FDD0C33-ECE1-46E5-AC52-00849F2B8CE5@ORACLE.COM> References: <6aa9a1aa-cf2a-b806-1b57-b223752751d8@oracle.com> <640f6f35-6ba7-81f6-92cf-b2838a98ca1c@oracle.com> <7FDD0C33-ECE1-46E5-AC52-00849F2B8CE5@ORACLE.COM> Message-ID: <975e3e28-18de-69bb-e399-24db373bac07@oracle.com> Thanks Rajan. I changed the webrev and ran Mach5 too. Here is the new webrev link: - http://cr.openjdk.java.net/~sshivang/reviews/8246330/webrev.01/ Thanks Shivangi On 06/06/20 7:37 am, Rajan Halade wrote: > One minor comment - > > Can you please put try-catch around "(new > DisabledCurve()).run();??instead of over for loop? > > Otherwise test looks good. > > Thanks, > Rajan > >> On Jun 4, 2020, at 8:41 PM, shivangi.g.gupta at oracle.com >> wrote: >> >> Corrected the links. >> >> On 04/06/20 10:59 pm, shivangi.g.gupta at oracle.com wrote: >>> >>> Hi, >>> >>> May I please find a sponsor for this patch? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246330 >>> >>> Description:Many of EC named curves has been disabled with security >>> property "jdk.disabled.namedCurves". The purpose of this Test is to >>> verify the behavior of any EC named curve from the disabled list. >>> This Test will address a single name from the disabled list as >>> sect283r1. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~sshivang/reviews/8246330/webrev.00/ >>> >>> The patch has been tested on mach5, and the individual test was passed. >>> >>> Thanks >>> >>> Shivangi >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Jun 8 12:25:04 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 8 Jun 2020 20:25:04 +0800 Subject: RFR 8245679: KeyStore cannot probe PKCS12 keystore if BouncyCastle is the top security provider Message-ID: Please take a look at https://cr.openjdk.java.net/~weijun/8245679/webrev.00/ If two providers support the same keystore type, we only try engineProbe() on the 1st one, and fail if it hasn't implemented it. The correct way is to try KeyStoreSpi from all providers. I also fixed an error that engineProbe() of both JKS and CaseExactJKS would return true on a JKS keystore, since the method is implemented in their common base class. This means there's a chance that a JKS keystore would be recognized as a CaseExactJKS keystore. This is seen after my code change in KeyStore. Thanks, Max From aleksej.efimov at oracle.com Mon Jun 8 13:07:21 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 8 Jun 2020 14:07:21 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> Message-ID: Hi Alexey, I've looked through LdapCtx/LdapClient/SaslBind changes: Do we need to check if CHANNEL_BINDING is set explicitly for all connection types? Maybe we can move the check inside 'if (conn.sock instanceof SSLSocket) {' block. Also, instead of setting CHANNEL_BINDING in context environment and then removing it in finally block, it would be better to clone the environment, put calculated CHANNEL_BINDING into it, and pass the cloned one to Sasl.createSaslClient. Another suggestion about the code that verifies if both properties are set before connection is started: As you've already mentioned the new code in LdapCtx is only needed for checking if timeout is set. Could we try to remove LdapCtx::cbType field and all related methods from LdapCtx (this class is already over-complicated and hard to read) and replace it with some static method in LdapSasl? It will help to localize all changes to LdapSasl except for one line in LdapCtx. I mean something like this: Replace + +??????????? // verify LDAP channel binding property +??????????? if (cbType != null && connectTimeout == -1) +??????????????????? throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + +??????????????????????????? " property requires " + +??????????????????????????? CONNECT_TIMEOUT + +??????????????????????????? " property is set."); With + LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), connectTimeout); And add something like that to LdapSasl (or maybe pass the full env here): + public static void checkCbParameters(String cbTypePropertyValue, int connectTimeout) throws NamingException { +???? TlsChannelBindingType cbType = TlsChannelBinding.parseType(cbTypePropertyValue); +???? // verify LDAP channel binding property +???? if (cbType != null && connectTimeout == -1) { +???????? throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + +???????????????? " property requires com.sun.jndi.ldap.connect.timeout" + +???????????????? " property is set."); +???? } + } Other LdapCtx/LdapClient/SaslBind? changes look fine to me. With Kind Regards, Aleksei On 06/06/2020 20:45, Alexey Bakhtin wrote: > Hello Max, Daniel, > > Thank you for review. > > Please review new version of the patch : > http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ > > In this version: > - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package > - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method > - verification and removal of internal property is also moved to LdapSasl.saslBind method > - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType > > The test for this issue is not ready yet. I did not find any suitable test case that can be reused. > > Thank you > Alexey > >> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >> >> >> >>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>> >>> >>> >>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>> >>>> Hello Max, >>>> >>>> Thank you a lot for review. >>>> >>>> Could you check the new version of the patch : >>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>> >>>> I?ve made the following changes: >>>> - TlsChannelBinding class is moved to java.naming module. >>>> java.security.sasl module is not affected any more >>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>> - LdapClient verifies if internal property is not set >>> 245 // Prepare TLS Channel Binding data >>> 246 if (conn.sock instanceof SSLSocket) { >>> 247 // Internal property cannot be set explicitly >>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>> 250 " property cannot be set explicitly"); >>> 251 } >>> >>> If not TLS, this property value be kept there and visible inside the SASL mech. >>> >>>> - GssKrb5Client uses props.remove() to read and remove internal property >> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >> >> --Max >> >>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>> >>> >>> Thanks, >>> Max >>> >>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. From anthony.scarpino at oracle.com Mon Jun 8 18:15:49 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 8 Jun 2020 11:15:49 -0700 Subject: [RFR] 8241680: KeyPairGen & Signature microbenchmarks need updating for disabled EC curves Message-ID: Hi, I need a quick code review of updates to the microbenchmarks tests for EC. These tests used curves that are now disabled by default in 15. https://cr.openjdk.java.net/~ascarpino/8241680/webrev/ thanks Tony From eric.caspole at oracle.com Mon Jun 8 18:27:17 2020 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Mon, 8 Jun 2020 14:27:17 -0400 Subject: [RFR] 8241680: KeyPairGen & Signature microbenchmarks need updating for disabled EC curves In-Reply-To: References: Message-ID: Looks fine to me. Eric On 6/8/20 2:15 PM, Anthony Scarpino wrote: > Hi, > > I need a quick code review of updates to the microbenchmarks tests for > EC.? These tests used curves that are now disabled by default in 15. > > https://cr.openjdk.java.net/~ascarpino/8241680/webrev/ > > thanks > > Tony From claes.redestad at oracle.com Mon Jun 8 18:28:13 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Jun 2020 20:28:13 +0200 Subject: [RFR] 8241680: KeyPairGen & Signature microbenchmarks need updating for disabled EC curves In-Reply-To: References: Message-ID: <19302bd1-1ace-f9b5-2b1e-adbe369adf8e@oracle.com> +1 /Claes On 2020-06-08 20:27, eric.caspole at oracle.com wrote: > Looks fine to me. > Eric > > > On 6/8/20 2:15 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a quick code review of updates to the microbenchmarks tests for >> EC.? These tests used curves that are now disabled by default in 15. >> >> https://cr.openjdk.java.net/~ascarpino/8241680/webrev/ >> >> thanks >> >> Tony From sean.mullan at oracle.com Mon Jun 8 18:55:11 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Jun 2020 14:55:11 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <72e50735-e5e1-08d7-f1bf-dfbd340841bb@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <85417480-7ecd-21d9-fb59-ff3d9a442360@oracle.com> <4F4BA16D-C9A4-46DD-A9A9-979E35431600@azul.com> <72e50735-e5e1-08d7-f1bf-dfbd340841bb@oracle.com> Message-ID: I'm just catching up a bit on this review. Sorry if this has mentioned before, but are you planning to write a CSR and release note? I think this is needed for the com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this property should be documented in the javadocs, and why it is not a standard property (i.e. "java.naming.ldap.tls.cbtype"). I was also wondering what relation this has to the "G2" standard SASL mechanisms defined in RFC 5801 [1], and whether that is something we should be using to negotiate this channel binding, and if not, why not. Or if this is something that is implementation-specific and will only work with Microsoft LDAP technology, in which case, we might want to make that more explicit, perhaps by including "microsoft" or something like that in the property name. Thanks, Sean [1] https://tools.ietf.org/html/rfc5801 On 6/5/20 12:45 PM, Daniel Fuchs wrote: > Hi Alexey, > > On 05/06/2020 17:33, Alexey Bakhtin wrote: >> Hi Daniel, >> >> Thank you for review >> Yes, I can move TlsChannelBinding class into the >> com.sun.jndi.ldap.sasl package and LdapClient related changes into the >> LdapSasl.saslBind method. >> Also, you are right with exceptions. I will rename them to the >> NamingException. >> >> However, I?d like to parse TLS Channel Binding property in the LdapCtx >> class. The reason is ?com.sun.jndi.ldap.connect.timeout? property. >> This property should be set together with TLS Channel Binding. So, I?d >> like to verify if both properties are set before connection is >> started. The best place for it is LdapCtx.initEnv() >> Is it acceptable ? > > Yes - I am OK with that. > > Also - you will need a test. Ideally we'd want a test that verifies > that setting the new property works as expected. > > Best regards, > > -- daniel > >> >> Thank you >> Alexey From sean.mullan at oracle.com Mon Jun 8 19:03:15 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Jun 2020 15:03:15 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> Message-ID: <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> (resending to all lists on the review) I'm just catching up a bit on this review. Sorry if this has mentioned before, but are you planning to write a CSR and release note? I think this is needed for the com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this property should be documented in the javadocs, and why it is not a standard property (i.e. "java.naming.ldap.tls.cbtype"). I was also wondering what relation this has to the "G2" standard SASL mechanisms defined in RFC 5801 [1], and whether that is something we should be using to negotiate this channel binding, and if not, why not. Or if this is something that is implementation-specific and will only work with Microsoft LDAP technology, in which case, we might want to make that more explicit, perhaps by including "microsoft" or something like that in the property name. Thanks, Sean [1] https://tools.ietf.org/html/rfc5801 On 6/8/20 9:07 AM, Aleks Efimov wrote: > Hi Alexey, > > I've looked through LdapCtx/LdapClient/SaslBind changes: > > Do we need to check if CHANNEL_BINDING is set explicitly for all > connection types? Maybe we can move the check inside 'if (conn.sock > instanceof SSLSocket) {' block. > > Also, instead of setting CHANNEL_BINDING in context environment and then > removing it in finally block, it would be better to clone the > environment, put calculated CHANNEL_BINDING into it, and pass the cloned > one to Sasl.createSaslClient. > > Another suggestion about the code that verifies if both properties are > set before connection is started: > As you've already mentioned the new code in LdapCtx is only needed for > checking if timeout is set. Could we try to remove LdapCtx::cbType field > and all related methods from LdapCtx (this class is already > over-complicated and hard to read) and replace it with some static > method in LdapSasl? It will help to localize all changes to LdapSasl > except for one line in LdapCtx. > > I mean something like this: > Replace > + > +??????????? // verify LDAP channel binding property > +??????????? if (cbType != null && connectTimeout == -1) > +??????????????????? throw new > NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + > +??????????????????????????? " property requires " + > +??????????????????????????? CONNECT_TIMEOUT + > +??????????????????????????? " property is set."); > With > + > LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), > connectTimeout); > > And add something like that to LdapSasl (or maybe pass the full env here): > + public static void checkCbParameters(String cbTypePropertyValue, int > connectTimeout) throws NamingException { > +???? TlsChannelBindingType cbType = > TlsChannelBinding.parseType(cbTypePropertyValue); > +???? // verify LDAP channel binding property > +???? if (cbType != null && connectTimeout == -1) { > +???????? throw new > NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + > +???????????????? " property requires com.sun.jndi.ldap.connect.timeout" + > +???????????????? " property is set."); > +???? } > + } > > Other LdapCtx/LdapClient/SaslBind? changes look fine to me. > > With Kind Regards, > Aleksei > > On 06/06/2020 20:45, Alexey Bakhtin wrote: >> Hello Max, Daniel, >> >> Thank you for review. >> >> Please review new version of the patch : >> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >> >> In this version: >> - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl >> package >> - SSL Ceritificate related code is moved from LdapClient? into the >> LdapSasl.saslBind method >> - verification and removal of internal property is also moved to >> LdapSasl.saslBind method >> - verification of connectTimeout property is moved to LdapCtx.connect. >> I?ve found that connectionTimeout could be assigned later then cbType >> >> The test for this issue is not ready yet. I did not find any suitable >> test case that can be reused. >> >> Thank you >> Alexey >> >>> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >>> >>> >>> >>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>>> >>>>> Hello Max, >>>>> >>>>> Thank you a lot for review. >>>>> >>>>> Could you check the new version of the patch : >>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>> >>>>> I?ve made the following changes: >>>>> - TlsChannelBinding class is moved to java.naming module. >>>>> java.security.sasl module is not affected any more >>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you >>>>> suggested >>>>> - I?ve made some guards to prevent application from using >>>>> "com.sun.security.sasl.tlschannelbinding? property directly: >>>>> ????- LdapClient verifies if internal property is not set >>>> 245???????????????????? // Prepare TLS Channel Binding data >>>> 246???????????????????? if (conn.sock instanceof SSLSocket) { >>>> 247???????????????????????? // Internal property cannot be set >>>> explicitly >>>> 248???????????????????????? if >>>> (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>> 249???????????????????????????? throw new >>>> NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>> 250???????????????????????????????????? " property cannot be set >>>> explicitly"); >>>> 251???????????????????????? } >>>> >>>> If not TLS, this property value be kept there and visible inside the >>>> SASL mech. >>>> >>>>> ????- GssKrb5Client uses props.remove() to read and remove internal >>>>> property >>> Maybe you can remove the value in LdapClient.java, in case the mech >>> used is not GSSAPI. You can remove it in a finally block after line 303. >>> >>> --Max >>> >>>> Traditionally, we use "com.sun..." name which is a JDK supported >>>> name (although not at Java SE level), you might want to use a name >>>> which is even more internal. >>>> >>>> >>>> Thanks, >>>> Max >>>> >>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can >>>> improve the NTLM SASL mech to support it. > From sergey.kuksenko at oracle.com Mon Jun 8 19:22:41 2020 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Mon, 8 Jun 2020 12:22:41 -0700 Subject: [RFR] 8241680: KeyPairGen & Signature microbenchmarks need updating for disabled EC curves In-Reply-To: References: Message-ID: Looks fine to me. On 6/8/20 11:15 AM, Anthony Scarpino wrote: > Hi, > > I need a quick code review of updates to the microbenchmarks tests for > EC.? These tests used curves that are now disabled by default in 15. > > https://cr.openjdk.java.net/~ascarpino/8241680/webrev/ > > thanks > > Tony From valerie.peng at oracle.com Mon Jun 8 20:34:26 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jun 2020 13:34:26 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> Message-ID: <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> Hmm, I checked all MessageDigestSpi impls of JDK providers... The story is more complicated than we expect. For SUN provider which implement the digest spi, implementing Cloneable means it supports clone functionality. However, for SunPKCS11 provider which wraps native PKCS11 library, it always implements Cloneable interface, but when clone() is called, it will then perform the equivalent PKCS11 calls and throw CNSE if any PKCS11 error is observed. So, there is a possibility that the instanceof check and the clone() check leads to different result in this particular scenario. The chance of 3rd non-PKCS11 party provider whose MessageDigest/MessageDigestSpi impl implements Cloneable but throws CNSE when clone() is called should be very low? So, I think it should be sufficient to use "md instanceof Cloneable && md is not from PKCS11"? Valerie On 6/6/2020 9:10 AM, Xuelei Fan wrote: > As the the Delegate class takes care of the Cloneable SPI > implementation, it should be sufficient to use "md instanceof > Cloneable" only.? It is not a expected behavior that a provider > implements Cloneable but does not really support it. > > Xuelei > > On 6/5/2020 10:54 PM, Weijun Wang wrote: >> Is it possible to try "md instanceof Cloneable || md.clone() >> returns"? Hopefully this is fast enough in most cases and also has >> the chance to recognize more actually-cloneable ones. >> >> I'm also OK with simply using "md instanceof Cloneable". >> >> --Max >> >>> On Jun 6, 2020, at 12:02 PM, Valerie Peng >>> wrote: >>> >>> >>> I am merely following the spec's recommendation of trying the >>> clone() for cloneability check. >>> >>> If you both are ok with it and prefer the instanceof check, I can >>> sure reverting back the changes in HmacCore and HandshakeHash classes. >>> >>> Valerie >>> >>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>> I share the same concern. clone() is a heavy weight operation in >>>> constructors that can be called alot during intensive crypto >>>> operations. >>>> >>>> Now that you've done work on Delegate class - why not also keep the >>>> (instanceof Cloneable) test ? That can serve as your fastpath for >>>> the default JDK configuration AFAIK. >>>> >>>> regards, >>>> Sean. >>>> >>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>> >>>>>> ? 2020?6?5??03:19?Valerie Peng ??? >>>>>> >>>>>> >>>>>>> Can you give an example when these 2 rules have different >>>>>>> results? Is this only true for those implementation that >>>>>>> directly subclass MessageDigest? >>>>>> Before this fix, even the Spi impl implements Cloneable the >>>>>> instanceof check will always fail because the wrapper class, i.e. >>>>>> MessageDigest.Delegate does not. However, if you call the clone() >>>>>> (made public by the MessageDigest class), it will succeed because >>>>>> Delegate.clone() checks to see if the spi object implements the >>>>>> Cloneable interface, if yes, it will proceed to call the spi >>>>>> clone(). So, for this scenario, the results are different, e.g. >>>>>> instanceof returns false, but clone() succeeds. This is just one >>>>>> example. Is this what you are asking? >>>>> No. >>>>> >>>>> I understand this case, but this has already been fixed. Is there >>>>> any other example? Or are you only follow the words in the spec? >>>>> i.e. try clone() to see if it?s cloneable. >>>>> >>>>> I am worried that try clone() is much heavier than just check >>>>> instanof Cloneable. >>>>> >>>>> Thanks, >>>>> Max >> From valerie.peng at oracle.com Mon Jun 8 20:42:23 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jun 2020 13:42:23 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> Message-ID: <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> "md instanceof Cloneable && md is not from PKCS11" is not entirely precise. What I mean is that for MessageDigestSpi impls from PKCS11 provider, we will need to call the clone() to know for sure whether cloning is supported. If we decide to employ these extra logic for saving clone() call, it's better to do it inside the MessageDigest.of(...) so the callers don't have to repeat the same logic. Comments? Valerie On 6/8/2020 1:34 PM, Valerie Peng wrote: > Hmm, I checked all MessageDigestSpi impls of JDK providers... The > story is more complicated than we expect. > > For SUN provider which implement the digest spi, implementing > Cloneable means it supports clone functionality. > > However, for SunPKCS11 provider which wraps native PKCS11 library, it > always implements Cloneable interface, but when clone() is called, it > will then perform the equivalent PKCS11 calls and throw CNSE if any > PKCS11 error is observed. > > So, there is a possibility that the instanceof check and the clone() > check leads to different result in this particular scenario. > > The chance of 3rd non-PKCS11 party provider whose > MessageDigest/MessageDigestSpi impl implements Cloneable but throws > CNSE when clone() is called should be very low? So, I think it should > be sufficient to use "md instanceof Cloneable && md is not from PKCS11"? > > Valerie > > On 6/6/2020 9:10 AM, Xuelei Fan wrote: >> As the the Delegate class takes care of the Cloneable SPI >> implementation, it should be sufficient to use "md instanceof >> Cloneable" only.? It is not a expected behavior that a provider >> implements Cloneable but does not really support it. >> >> Xuelei >> >> On 6/5/2020 10:54 PM, Weijun Wang wrote: >>> Is it possible to try "md instanceof Cloneable || md.clone() >>> returns"? Hopefully this is fast enough in most cases and also has >>> the chance to recognize more actually-cloneable ones. >>> >>> I'm also OK with simply using "md instanceof Cloneable". >>> >>> --Max >>> >>>> On Jun 6, 2020, at 12:02 PM, Valerie Peng >>>> wrote: >>>> >>>> >>>> I am merely following the spec's recommendation of trying the >>>> clone() for cloneability check. >>>> >>>> If you both are ok with it and prefer the instanceof check, I can >>>> sure reverting back the changes in HmacCore and HandshakeHash classes. >>>> >>>> Valerie >>>> >>>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>>> I share the same concern. clone() is a heavy weight operation in >>>>> constructors that can be called alot during intensive crypto >>>>> operations. >>>>> >>>>> Now that you've done work on Delegate class - why not also keep >>>>> the (instanceof Cloneable) test ? That can serve as your fastpath >>>>> for the default JDK configuration AFAIK. >>>>> >>>>> regards, >>>>> Sean. >>>>> >>>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>>> >>>>>>> ? 2020?6?5??03:19?Valerie Peng >>>>>>> ??? >>>>>>> >>>>>>>> Can you give an example when these 2 rules have different >>>>>>>> results? Is this only true for those implementation that >>>>>>>> directly subclass MessageDigest? >>>>>>> Before this fix, even the Spi impl implements Cloneable the >>>>>>> instanceof check will always fail because the wrapper class, >>>>>>> i.e. MessageDigest.Delegate does not. However, if you call the >>>>>>> clone() (made public by the MessageDigest class), it will >>>>>>> succeed because Delegate.clone() checks to see if the spi object >>>>>>> implements the Cloneable interface, if yes, it will proceed to >>>>>>> call the spi clone(). So, for this scenario, the results are >>>>>>> different, e.g. instanceof returns false, but clone() succeeds. >>>>>>> This is just one example. Is this what you are asking? >>>>>> No. >>>>>> >>>>>> I understand this case, but this has already been fixed. Is there >>>>>> any other example? Or are you only follow the words in the spec? >>>>>> i.e. try clone() to see if it?s cloneable. >>>>>> >>>>>> I am worried that try clone() is much heavier than just check >>>>>> instanof Cloneable. >>>>>> >>>>>> Thanks, >>>>>> Max >>> From valerie.peng at oracle.com Mon Jun 8 20:52:20 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jun 2020 13:52:20 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: Message-ID: <8e9b2fd0-f0fd-39b4-5ace-e11d4f2cf740@oracle.com> Hi Audrey, Thanks for the comment, we can apply your suggestion in the next update of KnownOIDs class. Valerie On 6/6/2020 9:03 AM, Andrey Turbanov wrote: >> List.of(KnownOIDs.values()).forEach(o -> { >> register(o); >> }); > I wonder if this 'forEach' is better than plain old 'for' in some ways? > ``` > for (KnownOIDs oid : KnownOIDs.values()) { > register(oid); > } > ``` > I think a variant with plain 'for' generates a bit less garbage. > > > > Andrey Turbanov From alexey at azul.com Mon Jun 8 21:01:13 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 8 Jun 2020 21:01:13 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <013290B8-67BE-4CD5-804C-FC882CD23CFE@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <013290B8-67BE-4CD5-804C-FC882CD23CFE@oracle.com> Message-ID: Hello Max, Daniel, Thank you for review and suggestions. Could you please check the updated webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v6/ This version contains the following changes: 1. Updated license for new files 2. Comments about default address type usage in the InitialToken.java and GSSLibStub.c 3. internal property is renamed to ?jdk.internal.sasl.tlschannelbinding" 4. I did not create test but provided detailed reproducer in the bug description 5. Property verification is moved from LdapCTX into LdapSasl as suggested by Aleks 6. Use clone of enviroment properties as suggested by Aleks I did not move internal property check under 'if (conn.sock instanceof SSLSocket) {' block. It was already discussed in [1] : "If not TLS, this property value be kept there and visible inside the SASL mech." [1] - https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067042.html Thank you Alexey > On 7 Jun 2020, at 04:47, Weijun Wang wrote: > > Some comments: > > 1. I just noticed your 2 new files are using the plain GPU license, it should be GPL + Classpath. Read another source file for an example. > > 2. Please add some comments in InitialToken.java on what happens to the default type. > > 3. I still think "com.sun.security.sasl.tlschannelbinding" sounds like sun.com will support it. > > 4. If an automatic test is not feasible, please provide some instructions so our SQE can see if we can setup some internal tests. Then we can add noreg-hard with some justification to the test and go on. > > I cannot comment on LdapCtx.java, but the others look fine to me. > > Thanks, > Max > >> On Jun 7, 2020, at 3:45 AM, Alexey Bakhtin wrote: >> >> Hello Max, Daniel, >> >> Thank you for review. >> >> Please review new version of the patch : >> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >> >> In this version: >> - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package >> - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method >> - verification and removal of internal property is also moved to LdapSasl.saslBind method >> - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType >> >> The test for this issue is not ready yet. I did not find any suitable test case that can be reused. >> >> Thank you >> Alexey >> >>> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >>> >>> >>> >>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>>> >>>>> Hello Max, >>>>> >>>>> Thank you a lot for review. >>>>> >>>>> Could you check the new version of the patch : >>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>> >>>>> I?ve made the following changes: >>>>> - TlsChannelBinding class is moved to java.naming module. >>>>> java.security.sasl module is not affected any more >>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>>> - LdapClient verifies if internal property is not set >>>> >>>> 245 // Prepare TLS Channel Binding data >>>> 246 if (conn.sock instanceof SSLSocket) { >>>> 247 // Internal property cannot be set explicitly >>>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>> 250 " property cannot be set explicitly"); >>>> 251 } >>>> >>>> If not TLS, this property value be kept there and visible inside the SASL mech. >>>> >>>>> - GssKrb5Client uses props.remove() to read and remove internal property >>> >>> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >>> >>> --Max >>> >>>> >>>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>>> >>>> >>>> Thanks, >>>> Max >>>> >>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From valerie.peng at oracle.com Mon Jun 8 21:33:07 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jun 2020 14:33:07 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> Message-ID: <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> Hi Max, Please find comments in line. On 6/8/2020 2:34 AM, Weijun Wang wrote: > Looks like this should work, but still find it complicated. > > 1. Do we need to care about thread safety when managing legacyStrings? Right, it's more complicated than I like as well. As for thread safety, the legacy relevant data are all synchronized under the current provider object, i.e. this. Is there a particular call path not doing this? This is the same as the pre-7092821 code. > 2. Does implReplaceAll() need to set legacyChanged = true? Correct, the removal is by accident. Thanks for catching this. > 3. How about using prngAlgorithms.iterator().next() below? > > 1416 return prngAlgorithms.toArray(new String[0])[0]; Sure, changed. Valerie > > --Max > > >> On Jun 6, 2020, at 11:54 AM, Valerie Peng wrote: >> >> Thanks for reviewing and sharing the feedbacks on webrev.00. >> >> In order to support all existing calls for legacy registration for default secure random, I have to revert some of the JDK-7092821 changes and re-introduce the 'legacyStrings' LinkedHashMap. Updated the regression test with removal test for provider using legacy registrations as well. Although removal is supported, this is still not bullet proof as things may not work as expected if a provider registered their impl in both ways, i.e. legacy String pair and Service, and then remove/replace some entries later. Please comment if you really need this scenario to be supported. Although not explicitly documented, I think the intention is to use one or the other, never both. >> >> Webrev update: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >> >> Thanks, >> Valerie >> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>> Right, I try to keep the impl simple as I am not aware of any property removal usage. >>> >>> Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added. >>> >>> Valerie >>> >>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>> I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". >>>> >>>> And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. >>>> >>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>> >>>> --Max >>>> >>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: >>>>> >>>>> Hi, >>>>> >>>>> Looks good to me, one question >>>>> >>>>> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? >>>>> >>>>> Thanks, >>>>> Prasad.K >>>>> >>>>>> -----Original Message----- >>>>>> From: Valerie Peng >>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>> To: security-dev at openjdk.java.net >>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >>>>>> based on registration ordering >>>>>> >>>>>> Hi, Sean, >>>>>> >>>>>> Thanks for the review and feedback. Webrev updated: >>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>> >>>>>> getTypeAndAlgorithm(...) was not static due to an instance variable used by >>>>>> debugging output. I have removed it and made both method static. >>>>>> >>>>>> I will wait for others' review comments also. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Could someone help reviewing this fix? This change keep tracks of the >>>>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>>>> request of SecureRandom class. >>>>>>> This looks good to me. I would recommend that Max or someone else >>>>>>> review it as well. >>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>> >>>>>>> * SecureRandom.java >>>>>>> >>>>>>> 879 // For SUN provider, we use >>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>> >>>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>>> >>>>>>> * Provider.java >>>>>>> >>>>>>> 1156 private String parseSecureRandomPut(String name, String >>>>>>> value) { >>>>>>> >>>>>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>>>>> >>>>>>> --Sean From alexey at azul.com Mon Jun 8 21:33:02 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 8 Jun 2020 21:33:02 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> Message-ID: Hello Sean, Yes, I think we'll need CSR and release notes as soon as this patch adds new property. I do not know exact process for it, so I will be grateful if you could explain me exact steps. This patch was developed to address compatibility issue with new LDAP authentication over SSL/TLS announced by Microsoft [1]. It is not related to RFC 5801. In my opinion ?com.sun.jndi.ldap.tls.cbtype? name looks more suitable for this property and should allow backport it to early JDK versions. [1] - https://support.microsoft.com/en-au/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry Regards Alexey > On 8 Jun 2020, at 22:03, Sean Mullan wrote: > > (resending to all lists on the review) > > I'm just catching up a bit on this review. > > Sorry if this has mentioned before, but are you planning to write a CSR and release note? I think this is needed for the com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this property should be documented in the javadocs, and why it is not a standard property (i.e. "java.naming.ldap.tls.cbtype"). > > I was also wondering what relation this has to the "G2" standard SASL mechanisms defined in RFC 5801 [1], and whether that is something we should be using to negotiate this channel binding, and if not, why not. Or if this is something that is implementation-specific and will only work with Microsoft LDAP technology, in which case, we might want to make that more explicit, perhaps by including "microsoft" or something like that in the property name. > > Thanks, > Sean > > [1] https://tools.ietf.org/html/rfc5801 > > On 6/8/20 9:07 AM, Aleks Efimov wrote: >> Hi Alexey, >> I've looked through LdapCtx/LdapClient/SaslBind changes: >> Do we need to check if CHANNEL_BINDING is set explicitly for all connection types? Maybe we can move the check inside 'if (conn.sock instanceof SSLSocket) {' block. >> Also, instead of setting CHANNEL_BINDING in context environment and then removing it in finally block, it would be better to clone the environment, put calculated CHANNEL_BINDING into it, and pass the cloned one to Sasl.createSaslClient. >> Another suggestion about the code that verifies if both properties are set before connection is started: >> As you've already mentioned the new code in LdapCtx is only needed for checking if timeout is set. Could we try to remove LdapCtx::cbType field and all related methods from LdapCtx (this class is already over-complicated and hard to read) and replace it with some static method in LdapSasl? It will help to localize all changes to LdapSasl except for one line in LdapCtx. >> I mean something like this: >> Replace >> + >> + // verify LDAP channel binding property >> + if (cbType != null && connectTimeout == -1) >> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >> + " property requires " + >> + CONNECT_TIMEOUT + >> + " property is set."); >> With >> + LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), connectTimeout); >> And add something like that to LdapSasl (or maybe pass the full env here): >> + public static void checkCbParameters(String cbTypePropertyValue, int connectTimeout) throws NamingException { >> + TlsChannelBindingType cbType = TlsChannelBinding.parseType(cbTypePropertyValue); >> + // verify LDAP channel binding property >> + if (cbType != null && connectTimeout == -1) { >> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >> + " property requires com.sun.jndi.ldap.connect.timeout" + >> + " property is set."); >> + } >> + } >> Other LdapCtx/LdapClient/SaslBind changes look fine to me. >> With Kind Regards, >> Aleksei >> On 06/06/2020 20:45, Alexey Bakhtin wrote: >>> Hello Max, Daniel, >>> >>> Thank you for review. >>> >>> Please review new version of the patch : >>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >>> >>> In this version: >>> - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package >>> - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method >>> - verification and removal of internal property is also moved to LdapSasl.saslBind method >>> - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType >>> >>> The test for this issue is not ready yet. I did not find any suitable test case that can be reused. >>> >>> Thank you >>> Alexey >>> >>>> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>>>> >>>>> >>>>> >>>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>>>> >>>>>> Hello Max, >>>>>> >>>>>> Thank you a lot for review. >>>>>> >>>>>> Could you check the new version of the patch : >>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>>> >>>>>> I?ve made the following changes: >>>>>> - TlsChannelBinding class is moved to java.naming module. >>>>>> java.security.sasl module is not affected any more >>>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>>>> - LdapClient verifies if internal property is not set >>>>> 245 // Prepare TLS Channel Binding data >>>>> 246 if (conn.sock instanceof SSLSocket) { >>>>> 247 // Internal property cannot be set explicitly >>>>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>>> 250 " property cannot be set explicitly"); >>>>> 251 } >>>>> >>>>> If not TLS, this property value be kept there and visible inside the SASL mech. >>>>> >>>>>> - GssKrb5Client uses props.remove() to read and remove internal property >>>> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >>>> >>>> --Max >>>> >>>>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>>>> >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From xuelei.fan at oracle.com Mon Jun 8 21:55:21 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 8 Jun 2020 14:55:21 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> Message-ID: <13521a01-16a7-07d7-0942-a7e4250abeac@oracle.com> On 6/8/2020 1:42 PM, Valerie Peng wrote: > "md instanceof Cloneable && md is not from PKCS11" is not entirely > precise. What I mean is that for MessageDigestSpi impls from PKCS11 > provider, we will need to call the clone() to know for sure whether > cloning is supported. If we decide to employ these extra logic for > saving clone() call, it's better to do it inside the > MessageDigest.of(...) so the callers don't have to repeat the same > logic. Comments? > It sounds like a good idea to me if the repeatedly checking could be avoid. Xuelei > Valerie > > On 6/8/2020 1:34 PM, Valerie Peng wrote: >> Hmm, I checked all MessageDigestSpi impls of JDK providers... The >> story is more complicated than we expect. >> >> For SUN provider which implement the digest spi, implementing >> Cloneable means it supports clone functionality. >> >> However, for SunPKCS11 provider which wraps native PKCS11 library, it >> always implements Cloneable interface, but when clone() is called, it >> will then perform the equivalent PKCS11 calls and throw CNSE if any >> PKCS11 error is observed. >> >> So, there is a possibility that the instanceof check and the clone() >> check leads to different result in this particular scenario. >> >> The chance of 3rd non-PKCS11 party provider whose >> MessageDigest/MessageDigestSpi impl implements Cloneable but throws >> CNSE when clone() is called should be very low? So, I think it should >> be sufficient to use "md instanceof Cloneable && md is not from PKCS11"? >> >> Valerie >> >> On 6/6/2020 9:10 AM, Xuelei Fan wrote: >>> As the the Delegate class takes care of the Cloneable SPI >>> implementation, it should be sufficient to use "md instanceof >>> Cloneable" only.? It is not a expected behavior that a provider >>> implements Cloneable but does not really support it. >>> >>> Xuelei >>> >>> On 6/5/2020 10:54 PM, Weijun Wang wrote: >>>> Is it possible to try "md instanceof Cloneable || md.clone() >>>> returns"? Hopefully this is fast enough in most cases and also has >>>> the chance to recognize more actually-cloneable ones. >>>> >>>> I'm also OK with simply using "md instanceof Cloneable". >>>> >>>> --Max >>>> >>>>> On Jun 6, 2020, at 12:02 PM, Valerie Peng >>>>> wrote: >>>>> >>>>> >>>>> I am merely following the spec's recommendation of trying the >>>>> clone() for cloneability check. >>>>> >>>>> If you both are ok with it and prefer the instanceof check, I can >>>>> sure reverting back the changes in HmacCore and HandshakeHash classes. >>>>> >>>>> Valerie >>>>> >>>>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>>>> I share the same concern. clone() is a heavy weight operation in >>>>>> constructors that can be called alot during intensive crypto >>>>>> operations. >>>>>> >>>>>> Now that you've done work on Delegate class - why not also keep >>>>>> the (instanceof Cloneable) test ? That can serve as your fastpath >>>>>> for the default JDK configuration AFAIK. >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>>>> >>>>>>>> ? 2020?6?5??03:19?Valerie Peng >>>>>>>> ??? >>>>>>>> >>>>>>>>> Can you give an example when these 2 rules have different >>>>>>>>> results? Is this only true for those implementation that >>>>>>>>> directly subclass MessageDigest? >>>>>>>> Before this fix, even the Spi impl implements Cloneable the >>>>>>>> instanceof check will always fail because the wrapper class, >>>>>>>> i.e. MessageDigest.Delegate does not. However, if you call the >>>>>>>> clone() (made public by the MessageDigest class), it will >>>>>>>> succeed because Delegate.clone() checks to see if the spi object >>>>>>>> implements the Cloneable interface, if yes, it will proceed to >>>>>>>> call the spi clone(). So, for this scenario, the results are >>>>>>>> different, e.g. instanceof returns false, but clone() succeeds. >>>>>>>> This is just one example. Is this what you are asking? >>>>>>> No. >>>>>>> >>>>>>> I understand this case, but this has already been fixed. Is there >>>>>>> any other example? Or are you only follow the words in the spec? >>>>>>> i.e. try clone() to see if it?s cloneable. >>>>>>> >>>>>>> I am worried that try clone() is much heavier than just check >>>>>>> instanof Cloneable. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>> From valerie.peng at oracle.com Mon Jun 8 22:31:36 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 8 Jun 2020 15:31:36 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> Message-ID: <386f23a8-023d-200a-04ee-545677f95614@oracle.com> Webrev updated: http://cr.openjdk.java.net/~valeriep/8246613/webrev.02/ Besides addressing Max's comments, I also made updateSecureRandomEntries(...) method private and removed the synchronized keyword as all of its accesses are synchronized. Thanks, Valerie On 6/8/2020 2:33 PM, Valerie Peng wrote: > Hi Max, > > Please find comments in line. > > On 6/8/2020 2:34 AM, Weijun Wang wrote: >> Looks like this should work, but still find it complicated. >> >> 1. Do we need to care about thread safety when managing legacyStrings? > > Right, it's more complicated than I like as well. > > As for thread safety, the legacy relevant data are all synchronized > under the current provider object, i.e. this. Is there a particular > call path not doing this? This is the same as the pre-7092821 code. > >> 2. Does implReplaceAll() need to set legacyChanged = true? > Correct, the removal is by accident. Thanks for catching this. >> 3. How about using prngAlgorithms.iterator().next() below? >> >> ?? 1416???? return prngAlgorithms.toArray(new String[0])[0]; > > Sure, changed. > > Valerie > >> >> --Max >> >> >>> On Jun 6, 2020, at 11:54 AM, Valerie Peng >>> wrote: >>> >>> Thanks for reviewing and sharing the feedbacks on webrev.00. >>> >>> In order to support all existing calls for legacy registration for >>> default secure random, I have to revert some of the JDK-7092821 >>> changes and re-introduce the 'legacyStrings' LinkedHashMap. Updated >>> the regression test with removal test for provider using legacy >>> registrations as well. Although removal is supported, this is still >>> not bullet proof as things may not work as expected if a provider >>> registered their impl in both ways, i.e. legacy String pair and >>> Service, and then remove/replace some entries later. Please comment >>> if you really need this scenario to be supported. Although not >>> explicitly documented, I think the intention is to use one or the >>> other, never both. >>> >>> Webrev update: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>> >>> Thanks, >>> Valerie >>> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>>> Right, I try to keep the impl simple as I am not aware of any >>>> property removal usage. >>>> >>>> Oh-well, if we have to cater to the removal scenario, then we'd >>>> have to add a List and keep track of ALL secure random algos >>>> instead of only the FIRST one. Alright, I guess it costs for >>>> covering all aspect. But one extra benefit of this is that it >>>> should be easy to handle the future JDK property such as >>>> "jdk.securerandom.disabledAlgorithms" if it were to be added. >>>> >>>> Valerie >>>> >>>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>>> I don't know who in this world would want to do that, but Prasad's >>>>> concern is technically possible. I tried >>>>> 'p.remove("SecureRandom.a")' in the new test, and new >>>>> SecureRandom() fails with "java.security.NoSuchAlgorithmException: >>>>> a SecureRandom not available". >>>>> >>>>> And people can also remove one entry and add it back in order to >>>>> move it to the end. One can even add new implementations this way. >>>>> >>>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>>> >>>>> --Max >>>>> >>>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Looks good to me, one question >>>>>> >>>>>> If first registered SecureRandom algo gets removed, >>>>>> getDefaultSecureRandomAlgorithm return stale data, a refresh >>>>>> required in remove? >>>>>> >>>>>> Thanks, >>>>>> Prasad.K >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Valerie Peng >>>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>>> To: security-dev at openjdk.java.net >>>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default >>>>>>> SecureRandom algo >>>>>>> based on registration ordering >>>>>>> >>>>>>> Hi, Sean, >>>>>>> >>>>>>> Thanks for the review and feedback. Webrev updated: >>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>> >>>>>>> getTypeAndAlgorithm(...) was not static due to an instance >>>>>>> variable used by >>>>>>> debugging output. I have removed it and made both method static. >>>>>>> >>>>>>> I will wait for others' review comments also. >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Could someone help reviewing this fix? This change keep tracks >>>>>>>>> of the >>>>>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>>>>> request of SecureRandom class. >>>>>>>> This looks good to me. I would recommend that Max or someone else >>>>>>>> review it as well. >>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>>> >>>>>>>> * SecureRandom.java >>>>>>>> >>>>>>>> 879???????????? // For SUN provider, we use >>>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>>> >>>>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>>>> >>>>>>>> * Provider.java >>>>>>>> >>>>>>>> 1156???? private String parseSecureRandomPut(String name, String >>>>>>>> value) { >>>>>>>> >>>>>>>> Could be static if you also make getTypeAndAlgorithm static, I >>>>>>>> think. >>>>>>>> >>>>>>>> --Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Jun 9 01:11:16 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 9 Jun 2020 09:11:16 +0800 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <386f23a8-023d-200a-04ee-545677f95614@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> <386f23a8-023d-200a-04ee-545677f95614@oracle.com> Message-ID: <8BAA3715-11BC-4A39-8C96-FD04CFE1BC84@oracle.com> Code change looks fine to me. I re-look at every place where legacyStrings and prngAlgorithms are used and they are all synchronized. Last time I thought some were not. Sorry. Only one comment: I like the isProviderInfo() name better, but I notice it was the old name pre-7092821. Thanks, Max > On Jun 9, 2020, at 6:31 AM, Valerie Peng wrote: > > Webrev updated: http://cr.openjdk.java.net/~valeriep/8246613/webrev.02/ > > Besides addressing Max's comments, I also made updateSecureRandomEntries(...) method private and removed the synchronized keyword as all of its accesses are synchronized. > > Thanks, > Valerie > On 6/8/2020 2:33 PM, Valerie Peng wrote: >> Hi Max, >> >> Please find comments in line. >> >> On 6/8/2020 2:34 AM, Weijun Wang wrote: >>> Looks like this should work, but still find it complicated. >>> >>> 1. Do we need to care about thread safety when managing legacyStrings? >> >> Right, it's more complicated than I like as well. >> >> As for thread safety, the legacy relevant data are all synchronized under the current provider object, i.e. this. Is there a particular call path not doing this? This is the same as the pre-7092821 code. >> >>> 2. Does implReplaceAll() need to set legacyChanged = true? >> Correct, the removal is by accident. Thanks for catching this. >>> 3. How about using prngAlgorithms.iterator().next() below? >>> >>> 1416 return prngAlgorithms.toArray(new String[0])[0]; >> >> Sure, changed. >> >> Valerie >> >>> >>> --Max >>> >>> >>>> On Jun 6, 2020, at 11:54 AM, Valerie Peng wrote: >>>> >>>> Thanks for reviewing and sharing the feedbacks on webrev.00. >>>> >>>> In order to support all existing calls for legacy registration for default secure random, I have to revert some of the JDK-7092821 changes and re-introduce the 'legacyStrings' LinkedHashMap. Updated the regression test with removal test for provider using legacy registrations as well. Although removal is supported, this is still not bullet proof as things may not work as expected if a provider registered their impl in both ways, i.e. legacy String pair and Service, and then remove/replace some entries later. Please comment if you really need this scenario to be supported. Although not explicitly documented, I think the intention is to use one or the other, never both. >>>> >>>> Webrev update: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>> >>>> Thanks, >>>> Valerie >>>> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>>>> Right, I try to keep the impl simple as I am not aware of any property removal usage. >>>>> >>>>> Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added. >>>>> >>>>> Valerie >>>>> >>>>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>>>> I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". >>>>>> >>>>>> And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. >>>>>> >>>>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>>>> >>>>>> --Max >>>>>> >>>>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Looks good to me, one question >>>>>>> >>>>>>> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? >>>>>>> >>>>>>> Thanks, >>>>>>> Prasad.K >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Valerie Peng >>>>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>>>> To: security-dev at openjdk.java.net >>>>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >>>>>>>> based on registration ordering >>>>>>>> >>>>>>>> Hi, Sean, >>>>>>>> >>>>>>>> Thanks for the review and feedback. Webrev updated: >>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>> >>>>>>>> getTypeAndAlgorithm(...) was not static due to an instance variable used by >>>>>>>> debugging output. I have removed it and made both method static. >>>>>>>> >>>>>>>> I will wait for others' review comments also. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Could someone help reviewing this fix? This change keep tracks of the >>>>>>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>>>>>> request of SecureRandom class. >>>>>>>>> This looks good to me. I would recommend that Max or someone else >>>>>>>>> review it as well. >>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>>>> >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>>>> >>>>>>>>> * SecureRandom.java >>>>>>>>> >>>>>>>>> 879 // For SUN provider, we use >>>>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>>>> >>>>>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>>>>> >>>>>>>>> * Provider.java >>>>>>>>> >>>>>>>>> 1156 private String parseSecureRandomPut(String name, String >>>>>>>>> value) { >>>>>>>>> >>>>>>>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>>>>>>> >>>>>>>>> --Sean From RAJAN.HALADE at ORACLE.COM Tue Jun 9 05:38:09 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Mon, 8 Jun 2020 22:38:09 -0700 Subject: RFR:8246330:Add TLS Tests for Legacy ECDSA curves In-Reply-To: <975e3e28-18de-69bb-e399-24db373bac07@oracle.com> References: <6aa9a1aa-cf2a-b806-1b57-b223752751d8@oracle.com> <640f6f35-6ba7-81f6-92cf-b2838a98ca1c@oracle.com> <7FDD0C33-ECE1-46E5-AC52-00849F2B8CE5@ORACLE.COM> <975e3e28-18de-69bb-e399-24db373bac07@oracle.com> Message-ID: Looks good to me. Thanks, Rajan > On Jun 8, 2020, at 4:34 AM, shivangi.g.gupta at oracle.com wrote: > > Thanks Rajan. I changed the webrev and ran Mach5 too. Here is the new webrev link: - > > http://cr.openjdk.java.net/~sshivang/reviews/8246330/webrev.01/ > > Thanks > > Shivangi > > > > On 06/06/20 7:37 am, Rajan Halade wrote: >> One minor comment - >> >> Can you please put try-catch around "(new DisabledCurve()).run();? instead of over for loop? >> >> Otherwise test looks good. >> >> Thanks, >> Rajan >> >>> On Jun 4, 2020, at 8:41 PM, shivangi.g.gupta at oracle.com wrote: >>> >>> Corrected the links. >>> >>> On 04/06/20 10:59 pm, shivangi.g.gupta at oracle.com wrote: >>>> Hi, >>>> >>>> May I please find a sponsor for this patch? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246330 >>>> >>>> Description:Many of EC named curves has been disabled with security property "jdk.disabled.namedCurves". The purpose of this Test is to verify the behavior of any EC named curve from the disabled list. >>>> This Test will address a single name from the disabled list as sect283r1. >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~sshivang/reviews/8246330/webrev.00/ >>>> The patch has been tested on mach5, and the individual test was passed. >>>> >>>> Thanks >>>> >>>> Shivangi >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksej.efimov at oracle.com Tue Jun 9 12:59:09 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 9 Jun 2020 13:59:09 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> Message-ID: <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> Hi Alexey, Thank you for incorporating LdapCtx and LdapSasl changes. I've reviewed both classes and they look good to me, with few minor comments in LdapSasl.java: ????? missing spaces in the following lines: 78, 152 ????? With your last changes we can remove explicit cast of 'envProps' on line 176 I've also run your changes through our CI and one test is failing due to the changes in GssKrb5Client: The failed test name: sun/security/krb5/auto/SaslMutual.java The observed failure: java.lang.UnsupportedOperationException ??? at java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:127) ??? at java.base/java.util.ImmutableCollections$AbstractImmutableMap.remove(ImmutableCollections.java:910) ??? at jdk.security.jgss/com.sun.security.sasl.gsskerb.GssKrb5Client.(GssKrb5Client.java:156) ??? at jdk.security.jgss/com.sun.security.sasl.gsskerb.FactoryImpl.createSaslClient(FactoryImpl.java:63) ??? at java.security.sasl/javax.security.sasl.Sasl.createSaslClient(Sasl.java:433) ??? at SaslMutual.main(SaslMutual.java:50) ??? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ??? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) ??? at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ??? at java.base/java.lang.reflect.Method.invoke(Method.java:564) ??? at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) ??? at java.base/java.lang.Thread.run(Thread.java:832) For information about CSR process you can start from this wiki page: https://wiki.openjdk.java.net/display/csr Best Regards, Aleksei On 08/06/2020 22:33, Alexey Bakhtin wrote: > Hello Sean, > > Yes, I think we'll need CSR and release notes as soon as this patch adds new property. > I do not know exact process for it, so I will be grateful if you could explain me exact steps. > > This patch was developed to address compatibility issue with new LDAP authentication over SSL/TLS announced by Microsoft [1]. It is not related to RFC 5801. In my opinion ?com.sun.jndi.ldap.tls.cbtype? name looks more suitable for this property and should allow backport it to early JDK versions. > > [1] - https://support.microsoft.com/en-au/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry > Regards > Alexey > >> On 8 Jun 2020, at 22:03, Sean Mullan wrote: >> >> (resending to all lists on the review) >> >> I'm just catching up a bit on this review. >> >> Sorry if this has mentioned before, but are you planning to write a CSR and release note? I think this is needed for the com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this property should be documented in the javadocs, and why it is not a standard property (i.e. "java.naming.ldap.tls.cbtype"). >> >> I was also wondering what relation this has to the "G2" standard SASL mechanisms defined in RFC 5801 [1], and whether that is something we should be using to negotiate this channel binding, and if not, why not. Or if this is something that is implementation-specific and will only work with Microsoft LDAP technology, in which case, we might want to make that more explicit, perhaps by including "microsoft" or something like that in the property name. >> >> Thanks, >> Sean >> >> [1] https://tools.ietf.org/html/rfc5801 >> >> On 6/8/20 9:07 AM, Aleks Efimov wrote: >>> Hi Alexey, >>> I've looked through LdapCtx/LdapClient/SaslBind changes: >>> Do we need to check if CHANNEL_BINDING is set explicitly for all connection types? Maybe we can move the check inside 'if (conn.sock instanceof SSLSocket) {' block. >>> Also, instead of setting CHANNEL_BINDING in context environment and then removing it in finally block, it would be better to clone the environment, put calculated CHANNEL_BINDING into it, and pass the cloned one to Sasl.createSaslClient. >>> Another suggestion about the code that verifies if both properties are set before connection is started: >>> As you've already mentioned the new code in LdapCtx is only needed for checking if timeout is set. Could we try to remove LdapCtx::cbType field and all related methods from LdapCtx (this class is already over-complicated and hard to read) and replace it with some static method in LdapSasl? It will help to localize all changes to LdapSasl except for one line in LdapCtx. >>> I mean something like this: >>> Replace >>> + >>> + // verify LDAP channel binding property >>> + if (cbType != null && connectTimeout == -1) >>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>> + " property requires " + >>> + CONNECT_TIMEOUT + >>> + " property is set."); >>> With >>> + LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), connectTimeout); >>> And add something like that to LdapSasl (or maybe pass the full env here): >>> + public static void checkCbParameters(String cbTypePropertyValue, int connectTimeout) throws NamingException { >>> + TlsChannelBindingType cbType = TlsChannelBinding.parseType(cbTypePropertyValue); >>> + // verify LDAP channel binding property >>> + if (cbType != null && connectTimeout == -1) { >>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>> + " property requires com.sun.jndi.ldap.connect.timeout" + >>> + " property is set."); >>> + } >>> + } >>> Other LdapCtx/LdapClient/SaslBind changes look fine to me. >>> With Kind Regards, >>> Aleksei >>> On 06/06/2020 20:45, Alexey Bakhtin wrote: >>>> Hello Max, Daniel, >>>> >>>> Thank you for review. >>>> >>>> Please review new version of the patch : >>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >>>> >>>> In this version: >>>> - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package >>>> - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method >>>> - verification and removal of internal property is also moved to LdapSasl.saslBind method >>>> - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType >>>> >>>> The test for this issue is not ready yet. I did not find any suitable test case that can be reused. >>>> >>>> Thank you >>>> Alexey >>>> >>>>> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >>>>> >>>>> >>>>> >>>>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>>>>> >>>>>>> Hello Max, >>>>>>> >>>>>>> Thank you a lot for review. >>>>>>> >>>>>>> Could you check the new version of the patch : >>>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>>>> >>>>>>> I?ve made the following changes: >>>>>>> - TlsChannelBinding class is moved to java.naming module. >>>>>>> java.security.sasl module is not affected any more >>>>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>>>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>>>>> - LdapClient verifies if internal property is not set >>>>>> 245 // Prepare TLS Channel Binding data >>>>>> 246 if (conn.sock instanceof SSLSocket) { >>>>>> 247 // Internal property cannot be set explicitly >>>>>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>>>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>>>> 250 " property cannot be set explicitly"); >>>>>> 251 } >>>>>> >>>>>> If not TLS, this property value be kept there and visible inside the SASL mech. >>>>>> >>>>>>> - GssKrb5Client uses props.remove() to read and remove internal property >>>>> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >>>>> >>>>> --Max >>>>> >>>>>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hai-may.chao at oracle.com Tue Jun 9 14:51:09 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Tue, 9 Jun 2020 07:51:09 -0700 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <77CE09E4-0A4F-41D1-A950-9CAF71F2317B@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> <77CE09E4-0A4F-41D1-A950-9CAF71F2317B@oracle.com> Message-ID: > On Jun 7, 2020, at 6:08 PM, Weijun Wang wrote: > > Looks fine to me. > > For CSR, since there is already a "Note" there for these 2 options, you can add a few words about what -keystore and -trustcacerts can do. Updated CSR as suggested. Thanks, Hai-May > > Thanks, > Max > >> On Jun 8, 2020, at 4:01 AM, Hai-May Chao wrote: >> >> Updated webrev - >> >> https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ >> >> Thanks, >> Hai-May >> >> >>> On Jun 5, 2020, at 11:04 PM, Weijun Wang wrote: >>> >>> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. >>> >>> Same for line 80 and line 96 of TrustedCRL.java. >>> >>> Everything else is fine. >>> >>> Thanks, >>> Max >>> >>> >>>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: >>>> >>>> Updated webrev - >>>> >>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>>> >>>> Added one command line -importcert in TrustCert.java. >>>> Added createCacerts() in test/lib SecurityTools.java. >>>> >>>> Thanks, >>>> Hai-May >>>> >>>> >>>> >>>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>>> >>>>> >>>>> >>>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>>>> >>>>>>> The source change looks fine to me. >>>>>>> >>>>>>> In TrustedCert.java: >>>>>>> >>>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>>>> >>>>>> This cat() is taken from WealAlg.java. >>>>>> >>>>>>> >>>>>>> - There is no need to recreate root.jks and root.pem. >>>>>> >>>>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>>>> >>>>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>>>> >>>>>> >>>>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>>>> >>>>>>> >>>>>>> - Why not use -trustcacerts below? >>>>>>> >>>>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>>>> >>>>>> >>>>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>>>> >>>>> OK. >>>>> >>>>> Then how about we add a new command before line 155? >>>>> >>>>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>>> >>>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>>> >>>>>> >>>>>>> >>>>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>>>> >>>>>> Ok, will change it. >>>>>> >>>>>>> >>>>>>> In TrustedCRL.java: >>>>>>> >>>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>>>> >>>>>> Same reply as above. >>>>> >>>>> Same question as above. >>>>> >>>>>> >>>>>>> >>>>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>>>> >>>>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>>>> >>>>>>> >>>>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>>>> >>>>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>>>> >>>>> I meant creating the cacerts in one method, something like >>>>> >>>>> void createCacerts(String ks, String... crt); >>>>> >>>>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>>>> >>>>> BTW, what does caks.size() == 0 matter here? >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Hai-May >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I?d like to request a review for: >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>>> >>>>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hai-May >>>> >>> >> > From sean.mullan at oracle.com Tue Jun 9 15:35:47 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 9 Jun 2020 11:35:47 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> Message-ID: <9dc3aa80-cce1-e1c2-d50b-d7cfe570c652@oracle.com> On 6/8/20 5:33 PM, Alexey Bakhtin wrote: > Hello Sean, > > Yes, I think we'll need CSR and release notes as soon as this patch adds new property. > I do not know exact process for it, so I will be grateful if you could explain me exact steps. The CSR process is documented at https://wiki.openjdk.java.net/display/csr/Main. It should be fairly self-explanatory but let me know if you have questions. For the release note, we can tackle that later once the CSR is approved now I have tagged the issue with the "release-note=yes" label so we don't forget it. > This patch was developed to address compatibility issue with new LDAP authentication over SSL/TLS announced by Microsoft [1]. It is not related to RFC 5801. In my opinion ?com.sun.jndi.ldap.tls.cbtype? name looks more suitable for this property and should allow backport it to early JDK versions. Good point about backporting. What RFC or specification defines the format you are using for the channel binding in TlsChannelBinding.java, specifically where the type prefix is encoded as "tls-server-end-point:" followed by the binding data? I have looked through various RFCs but I can't find exactly where this format is defined, so I am wondering if this is a standard encoding or not. Thanks, Sean > > [1] - https://support.microsoft.com/en-au/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry > Regards > Alexey > >> On 8 Jun 2020, at 22:03, Sean Mullan wrote: >> >> (resending to all lists on the review) >> >> I'm just catching up a bit on this review. >> >> Sorry if this has mentioned before, but are you planning to write a CSR and release note? I think this is needed for the com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this property should be documented in the javadocs, and why it is not a standard property (i.e. "java.naming.ldap.tls.cbtype"). >> >> I was also wondering what relation this has to the "G2" standard SASL mechanisms defined in RFC 5801 [1], and whether that is something we should be using to negotiate this channel binding, and if not, why not. Or if this is something that is implementation-specific and will only work with Microsoft LDAP technology, in which case, we might want to make that more explicit, perhaps by including "microsoft" or something like that in the property name. >> >> Thanks, >> Sean >> >> [1] https://tools.ietf.org/html/rfc5801 >> >> On 6/8/20 9:07 AM, Aleks Efimov wrote: >>> Hi Alexey, >>> I've looked through LdapCtx/LdapClient/SaslBind changes: >>> Do we need to check if CHANNEL_BINDING is set explicitly for all connection types? Maybe we can move the check inside 'if (conn.sock instanceof SSLSocket) {' block. >>> Also, instead of setting CHANNEL_BINDING in context environment and then removing it in finally block, it would be better to clone the environment, put calculated CHANNEL_BINDING into it, and pass the cloned one to Sasl.createSaslClient. >>> Another suggestion about the code that verifies if both properties are set before connection is started: >>> As you've already mentioned the new code in LdapCtx is only needed for checking if timeout is set. Could we try to remove LdapCtx::cbType field and all related methods from LdapCtx (this class is already over-complicated and hard to read) and replace it with some static method in LdapSasl? It will help to localize all changes to LdapSasl except for one line in LdapCtx. >>> I mean something like this: >>> Replace >>> + >>> + // verify LDAP channel binding property >>> + if (cbType != null && connectTimeout == -1) >>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>> + " property requires " + >>> + CONNECT_TIMEOUT + >>> + " property is set."); >>> With >>> + LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), connectTimeout); >>> And add something like that to LdapSasl (or maybe pass the full env here): >>> + public static void checkCbParameters(String cbTypePropertyValue, int connectTimeout) throws NamingException { >>> + TlsChannelBindingType cbType = TlsChannelBinding.parseType(cbTypePropertyValue); >>> + // verify LDAP channel binding property >>> + if (cbType != null && connectTimeout == -1) { >>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>> + " property requires com.sun.jndi.ldap.connect.timeout" + >>> + " property is set."); >>> + } >>> + } >>> Other LdapCtx/LdapClient/SaslBind changes look fine to me. >>> With Kind Regards, >>> Aleksei >>> On 06/06/2020 20:45, Alexey Bakhtin wrote: >>>> Hello Max, Daniel, >>>> >>>> Thank you for review. >>>> >>>> Please review new version of the patch : >>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >>>> >>>> In this version: >>>> - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package >>>> - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method >>>> - verification and removal of internal property is also moved to LdapSasl.saslBind method >>>> - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType >>>> >>>> The test for this issue is not ready yet. I did not find any suitable test case that can be reused. >>>> >>>> Thank you >>>> Alexey >>>> >>>>> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >>>>> >>>>> >>>>> >>>>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>>>>> >>>>>>> Hello Max, >>>>>>> >>>>>>> Thank you a lot for review. >>>>>>> >>>>>>> Could you check the new version of the patch : >>>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>>>> >>>>>>> I?ve made the following changes: >>>>>>> - TlsChannelBinding class is moved to java.naming module. >>>>>>> java.security.sasl module is not affected any more >>>>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>>>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>>>>> - LdapClient verifies if internal property is not set >>>>>> 245 // Prepare TLS Channel Binding data >>>>>> 246 if (conn.sock instanceof SSLSocket) { >>>>>> 247 // Internal property cannot be set explicitly >>>>>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>>>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>>>> 250 " property cannot be set explicitly"); >>>>>> 251 } >>>>>> >>>>>> If not TLS, this property value be kept there and visible inside the SASL mech. >>>>>> >>>>>>> - GssKrb5Client uses props.remove() to read and remove internal property >>>>> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >>>>> >>>>> --Max >>>>> >>>>>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. > From alexey at azul.com Tue Jun 9 15:52:48 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 9 Jun 2020 15:52:48 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9dc3aa80-cce1-e1c2-d50b-d7cfe570c652@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <9dc3aa80-cce1-e1c2-d50b-d7cfe570c652@oracle.com> Message-ID: <9B6A7339-F729-41EB-8245-CB6EA03A8D31@azul.com> Hello Sean, Thank you for the link. I?ll follow it to create CSR I could not find any clear document or specification for this Channel Binding format. The only document I found that describes this format is the following: https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication So, it is hard to say - is it a standard or Microsoft implementation specific Regards Alexey > On 9 Jun 2020, at 18:35, Sean Mullan wrote: > > On 6/8/20 5:33 PM, Alexey Bakhtin wrote: >> Hello Sean, >> Yes, I think we'll need CSR and release notes as soon as this patch adds new property. >> I do not know exact process for it, so I will be grateful if you could explain me exact steps. > > The CSR process is documented at https://wiki.openjdk.java.net/display/csr/Main. It should be fairly self-explanatory but let me know if you have questions. > > For the release note, we can tackle that later once the CSR is approved now I have tagged the issue with the "release-note=yes" label so we don't forget it. > >> This patch was developed to address compatibility issue with new LDAP authentication over SSL/TLS announced by Microsoft [1]. It is not related to RFC 5801. In my opinion ?com.sun.jndi.ldap.tls.cbtype? name looks more suitable for this property and should allow backport it to early JDK versions. > > Good point about backporting. > > What RFC or specification defines the format you are using for the channel binding in TlsChannelBinding.java, specifically where the type prefix is encoded as "tls-server-end-point:" followed by the binding data? I have looked through various RFCs but I can't find exactly where this format is defined, so I am wondering if this is a standard encoding or not. > > Thanks, > Sean > >> [1] - https://support.microsoft.com/en-au/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry >> Regards >> Alexey >>> On 8 Jun 2020, at 22:03, Sean Mullan wrote: >>> >>> (resending to all lists on the review) >>> >>> I'm just catching up a bit on this review. >>> >>> Sorry if this has mentioned before, but are you planning to write a CSR and release note? I think this is needed for the com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this property should be documented in the javadocs, and why it is not a standard property (i.e. "java.naming.ldap.tls.cbtype"). >>> >>> I was also wondering what relation this has to the "G2" standard SASL mechanisms defined in RFC 5801 [1], and whether that is something we should be using to negotiate this channel binding, and if not, why not. Or if this is something that is implementation-specific and will only work with Microsoft LDAP technology, in which case, we might want to make that more explicit, perhaps by including "microsoft" or something like that in the property name. >>> >>> Thanks, >>> Sean >>> >>> [1] https://tools.ietf.org/html/rfc5801 >>> >>> On 6/8/20 9:07 AM, Aleks Efimov wrote: >>>> Hi Alexey, >>>> I've looked through LdapCtx/LdapClient/SaslBind changes: >>>> Do we need to check if CHANNEL_BINDING is set explicitly for all connection types? Maybe we can move the check inside 'if (conn.sock instanceof SSLSocket) {' block. >>>> Also, instead of setting CHANNEL_BINDING in context environment and then removing it in finally block, it would be better to clone the environment, put calculated CHANNEL_BINDING into it, and pass the cloned one to Sasl.createSaslClient. >>>> Another suggestion about the code that verifies if both properties are set before connection is started: >>>> As you've already mentioned the new code in LdapCtx is only needed for checking if timeout is set. Could we try to remove LdapCtx::cbType field and all related methods from LdapCtx (this class is already over-complicated and hard to read) and replace it with some static method in LdapSasl? It will help to localize all changes to LdapSasl except for one line in LdapCtx. >>>> I mean something like this: >>>> Replace >>>> + >>>> + // verify LDAP channel binding property >>>> + if (cbType != null && connectTimeout == -1) >>>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>>> + " property requires " + >>>> + CONNECT_TIMEOUT + >>>> + " property is set."); >>>> With >>>> + LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), connectTimeout); >>>> And add something like that to LdapSasl (or maybe pass the full env here): >>>> + public static void checkCbParameters(String cbTypePropertyValue, int connectTimeout) throws NamingException { >>>> + TlsChannelBindingType cbType = TlsChannelBinding.parseType(cbTypePropertyValue); >>>> + // verify LDAP channel binding property >>>> + if (cbType != null && connectTimeout == -1) { >>>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>>> + " property requires com.sun.jndi.ldap.connect.timeout" + >>>> + " property is set."); >>>> + } >>>> + } >>>> Other LdapCtx/LdapClient/SaslBind changes look fine to me. >>>> With Kind Regards, >>>> Aleksei >>>> On 06/06/2020 20:45, Alexey Bakhtin wrote: >>>>> Hello Max, Daniel, >>>>> >>>>> Thank you for review. >>>>> >>>>> Please review new version of the patch : >>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >>>>> >>>>> In this version: >>>>> - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package >>>>> - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method >>>>> - verification and removal of internal property is also moved to LdapSasl.saslBind method >>>>> - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType >>>>> >>>>> The test for this issue is not ready yet. I did not find any suitable test case that can be reused. >>>>> >>>>> Thank you >>>>> Alexey >>>>> >>>>>> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>>>>>> >>>>>>>> Hello Max, >>>>>>>> >>>>>>>> Thank you a lot for review. >>>>>>>> >>>>>>>> Could you check the new version of the patch : >>>>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>>>>> >>>>>>>> I?ve made the following changes: >>>>>>>> - TlsChannelBinding class is moved to java.naming module. >>>>>>>> java.security.sasl module is not affected any more >>>>>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>>>>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>>>>>> - LdapClient verifies if internal property is not set >>>>>>> 245 // Prepare TLS Channel Binding data >>>>>>> 246 if (conn.sock instanceof SSLSocket) { >>>>>>> 247 // Internal property cannot be set explicitly >>>>>>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>>>>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>>>>> 250 " property cannot be set explicitly"); >>>>>>> 251 } >>>>>>> >>>>>>> If not TLS, this property value be kept there and visible inside the SASL mech. >>>>>>> >>>>>>>> - GssKrb5Client uses props.remove() to read and remove internal property >>>>>> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >>>>>> >>>>>> --Max >>>>>> >>>>>>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From xuelei.fan at oracle.com Tue Jun 9 16:40:33 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jun 2020 09:40:33 -0700 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9B6A7339-F729-41EB-8245-CB6EA03A8D31@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <9dc3aa80-cce1-e1c2-d50b-d7cfe570c652@oracle.com> <9B6A7339-F729-41EB-8245-CB6EA03A8D31@azul.com> Message-ID: <21ab9cf7-2d48-f5de-3586-78b40c1d0c12@oracle.com> About the prefix, it may follow RFC 5056 (See page 7, section 2.1). o Specifications of channel bindings for any secure channels MUST provide for a single, canonical octet string encoding of the channel bindings. Under this framework, channel bindings MUST start with the channel binding unique prefix followed by a colon (ASCII 0x3A). Xuelei On 6/9/2020 8:52 AM, Alexey Bakhtin wrote: > Hello Sean, > > Thank you for the link. I?ll follow it to create CSR > > I could not find any clear document or specification for this Channel Binding format. > The only document I found that describes this format is the following: > https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication > So, it is hard to say - is it a standard or Microsoft implementation specific > > Regards > Alexey > >> On 9 Jun 2020, at 18:35, Sean Mullan wrote: >> >> On 6/8/20 5:33 PM, Alexey Bakhtin wrote: >>> Hello Sean, >>> Yes, I think we'll need CSR and release notes as soon as this patch adds new property. >>> I do not know exact process for it, so I will be grateful if you could explain me exact steps. >> >> The CSR process is documented at https://wiki.openjdk.java.net/display/csr/Main. It should be fairly self-explanatory but let me know if you have questions. >> >> For the release note, we can tackle that later once the CSR is approved now I have tagged the issue with the "release-note=yes" label so we don't forget it. >> >>> This patch was developed to address compatibility issue with new LDAP authentication over SSL/TLS announced by Microsoft [1]. It is not related to RFC 5801. In my opinion ?com.sun.jndi.ldap.tls.cbtype? name looks more suitable for this property and should allow backport it to early JDK versions. >> >> Good point about backporting. >> >> What RFC or specification defines the format you are using for the channel binding in TlsChannelBinding.java, specifically where the type prefix is encoded as "tls-server-end-point:" followed by the binding data? I have looked through various RFCs but I can't find exactly where this format is defined, so I am wondering if this is a standard encoding or not. >> >> Thanks, >> Sean >> >>> [1] - https://support.microsoft.com/en-au/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry >>> Regards >>> Alexey >>>> On 8 Jun 2020, at 22:03, Sean Mullan wrote: >>>> >>>> (resending to all lists on the review) >>>> >>>> I'm just catching up a bit on this review. >>>> >>>> Sorry if this has mentioned before, but are you planning to write a CSR and release note? I think this is needed for the com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this property should be documented in the javadocs, and why it is not a standard property (i.e. "java.naming.ldap.tls.cbtype"). >>>> >>>> I was also wondering what relation this has to the "G2" standard SASL mechanisms defined in RFC 5801 [1], and whether that is something we should be using to negotiate this channel binding, and if not, why not. Or if this is something that is implementation-specific and will only work with Microsoft LDAP technology, in which case, we might want to make that more explicit, perhaps by including "microsoft" or something like that in the property name. >>>> >>>> Thanks, >>>> Sean >>>> >>>> [1] https://tools.ietf.org/html/rfc5801 >>>> >>>> On 6/8/20 9:07 AM, Aleks Efimov wrote: >>>>> Hi Alexey, >>>>> I've looked through LdapCtx/LdapClient/SaslBind changes: >>>>> Do we need to check if CHANNEL_BINDING is set explicitly for all connection types? Maybe we can move the check inside 'if (conn.sock instanceof SSLSocket) {' block. >>>>> Also, instead of setting CHANNEL_BINDING in context environment and then removing it in finally block, it would be better to clone the environment, put calculated CHANNEL_BINDING into it, and pass the cloned one to Sasl.createSaslClient. >>>>> Another suggestion about the code that verifies if both properties are set before connection is started: >>>>> As you've already mentioned the new code in LdapCtx is only needed for checking if timeout is set. Could we try to remove LdapCtx::cbType field and all related methods from LdapCtx (this class is already over-complicated and hard to read) and replace it with some static method in LdapSasl? It will help to localize all changes to LdapSasl except for one line in LdapCtx. >>>>> I mean something like this: >>>>> Replace >>>>> + >>>>> + // verify LDAP channel binding property >>>>> + if (cbType != null && connectTimeout == -1) >>>>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>>>> + " property requires " + >>>>> + CONNECT_TIMEOUT + >>>>> + " property is set."); >>>>> With >>>>> + LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), connectTimeout); >>>>> And add something like that to LdapSasl (or maybe pass the full env here): >>>>> + public static void checkCbParameters(String cbTypePropertyValue, int connectTimeout) throws NamingException { >>>>> + TlsChannelBindingType cbType = TlsChannelBinding.parseType(cbTypePropertyValue); >>>>> + // verify LDAP channel binding property >>>>> + if (cbType != null && connectTimeout == -1) { >>>>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>>>> + " property requires com.sun.jndi.ldap.connect.timeout" + >>>>> + " property is set."); >>>>> + } >>>>> + } >>>>> Other LdapCtx/LdapClient/SaslBind changes look fine to me. >>>>> With Kind Regards, >>>>> Aleksei >>>>> On 06/06/2020 20:45, Alexey Bakhtin wrote: >>>>>> Hello Max, Daniel, >>>>>> >>>>>> Thank you for review. >>>>>> >>>>>> Please review new version of the patch : >>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >>>>>> >>>>>> In this version: >>>>>> - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package >>>>>> - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method >>>>>> - verification and removal of internal property is also moved to LdapSasl.saslBind method >>>>>> - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType >>>>>> >>>>>> The test for this issue is not ready yet. I did not find any suitable test case that can be reused. >>>>>> >>>>>> Thank you >>>>>> Alexey >>>>>> >>>>>>> On 6 Jun 2020, at 09:44, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin wrote: >>>>>>>>> >>>>>>>>> Hello Max, >>>>>>>>> >>>>>>>>> Thank you a lot for review. >>>>>>>>> >>>>>>>>> Could you check the new version of the patch : >>>>>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>>>>>> >>>>>>>>> I?ve made the following changes: >>>>>>>>> - TlsChannelBinding class is moved to java.naming module. >>>>>>>>> java.security.sasl module is not affected any more >>>>>>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>>>>>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>>>>>>> - LdapClient verifies if internal property is not set >>>>>>>> 245 // Prepare TLS Channel Binding data >>>>>>>> 246 if (conn.sock instanceof SSLSocket) { >>>>>>>> 247 // Internal property cannot be set explicitly >>>>>>>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>>>>>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>>>>>> 250 " property cannot be set explicitly"); >>>>>>>> 251 } >>>>>>>> >>>>>>>> If not TLS, this property value be kept there and visible inside the SASL mech. >>>>>>>> >>>>>>>>> - GssKrb5Client uses props.remove() to read and remove internal property >>>>>>> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. > From sean.mullan at oracle.com Tue Jun 9 16:50:05 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 9 Jun 2020 12:50:05 -0400 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <21ab9cf7-2d48-f5de-3586-78b40c1d0c12@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <9dc3aa80-cce1-e1c2-d50b-d7cfe570c652@oracle.com> <9B6A7339-F729-41EB-8245-CB6EA03A8D31@azul.com> <21ab9cf7-2d48-f5de-3586-78b40c1d0c12@oracle.com> Message-ID: <192f1214-fe26-32b5-0243-8d6b90803181@oracle.com> On 6/9/20 12:40 PM, Xuelei Fan wrote: > About the prefix, it may follow RFC 5056 (See page 7, section 2.1). > ?? o? Specifications of channel bindings for any secure channels MUST > ????? provide for a single, canonical octet string encoding of the > ????? channel bindings.? Under this framework, channel bindings MUST > ????? start with the channel binding unique prefix followed by a colon > ????? (ASCII 0x3A). Thanks! Easy to miss. I would recommend adding more comments in the code (ex, in TLSChannelBinding) pointing to that RFC section, and other RFCs such 5929 for the tls cbtypes. Also, this RFC (and other specifications such as RFC 5959) should be listed in the CSR so that we document precisely what encodings and types the JDK implementation supports and is using. --Sean > Xuelei > > > On 6/9/2020 8:52 AM, Alexey Bakhtin wrote: >> Hello Sean, >> >> Thank you for the link. I?ll follow it to create CSR >> >> I could not find any clear document or specification for this Channel >> Binding format. >> The only document I found that describes this format is the following: >> https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication >> >> So, it is hard to say - is it a standard or Microsoft implementation >> specific >> >> Regards >> Alexey >> >>> On 9 Jun 2020, at 18:35, Sean Mullan wrote: >>> >>> On 6/8/20 5:33 PM, Alexey Bakhtin wrote: >>>> Hello Sean, >>>> Yes, I think we'll need CSR and release notes as soon as this patch >>>> adds new property. >>>> I do not know exact process for it, so I will be grateful if you >>>> could explain me exact steps. >>> >>> The CSR process is documented at >>> https://wiki.openjdk.java.net/display/csr/Main. It should be fairly >>> self-explanatory but let me know if you have questions. >>> >>> For the release note, we can tackle that later once the CSR is >>> approved now I have tagged the issue with the "release-note=yes" >>> label so we don't forget it. >>> >>>> This patch was developed to address compatibility issue with new >>>> LDAP authentication over SSL/TLS announced by Microsoft [1]. It is >>>> not related to RFC 5801. In my opinion >>>> ?com.sun.jndi.ldap.tls.cbtype? name looks more suitable for this >>>> property and should allow backport it to early JDK versions. >>> >>> Good point about backporting. >>> >>> What RFC or specification defines the format you are using for the >>> channel binding in TlsChannelBinding.java, specifically where the >>> type prefix is encoded as "tls-server-end-point:" followed by the >>> binding data? I have looked through various RFCs but I can't find >>> exactly where this format is defined, so I am wondering if this is a >>> standard encoding or not. >>> >>> Thanks, >>> Sean >>> >>>> [1] - >>>> https://support.microsoft.com/en-au/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry >>>> >>>> Regards >>>> Alexey >>>>> On 8 Jun 2020, at 22:03, Sean Mullan wrote: >>>>> >>>>> (resending to all lists on the review) >>>>> >>>>> I'm just catching up a bit on this review. >>>>> >>>>> Sorry if this has mentioned before, but are you planning to write a >>>>> CSR and release note? I think this is needed for the >>>>> com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this >>>>> property should be documented in the javadocs, and why it is not a >>>>> standard property (i.e. "java.naming.ldap.tls.cbtype"). >>>>> >>>>> I was also wondering what relation this has to the "G2" standard >>>>> SASL mechanisms defined in RFC 5801 [1], and whether that is >>>>> something we should be using to negotiate this channel binding, and >>>>> if not, why not. Or if this is something that is >>>>> implementation-specific and will only work with Microsoft LDAP >>>>> technology, in which case, we might want to make that more >>>>> explicit, perhaps by including "microsoft" or something like that >>>>> in the property name. >>>>> >>>>> Thanks, >>>>> Sean >>>>> >>>>> [1] https://tools.ietf.org/html/rfc5801 >>>>> >>>>> On 6/8/20 9:07 AM, Aleks Efimov wrote: >>>>>> Hi Alexey, >>>>>> I've looked through LdapCtx/LdapClient/SaslBind changes: >>>>>> Do we need to check if CHANNEL_BINDING is set explicitly for all >>>>>> connection types? Maybe we can move the check inside 'if >>>>>> (conn.sock instanceof SSLSocket) {' block. >>>>>> Also, instead of setting CHANNEL_BINDING in context environment >>>>>> and then removing it in finally block, it would be better to clone >>>>>> the environment, put calculated CHANNEL_BINDING into it, and pass >>>>>> the cloned one to Sasl.createSaslClient. >>>>>> Another suggestion about the code that verifies if both properties >>>>>> are set before connection is started: >>>>>> As you've already mentioned the new code in LdapCtx is only needed >>>>>> for checking if timeout is set. Could we try to remove >>>>>> LdapCtx::cbType field and all related methods from LdapCtx (this >>>>>> class is already over-complicated and hard to read) and replace it >>>>>> with some static method in LdapSasl? It will help to localize all >>>>>> changes to LdapSasl except for one line in LdapCtx. >>>>>> I mean something like this: >>>>>> Replace >>>>>> + >>>>>> +??????????? // verify LDAP channel binding property >>>>>> +??????????? if (cbType != null && connectTimeout == -1) >>>>>> +??????????????????? throw new >>>>>> NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>>>>> +??????????????????????????? " property requires " + >>>>>> +??????????????????????????? CONNECT_TIMEOUT + >>>>>> +??????????????????????????? " property is set."); >>>>>> With >>>>>> + >>>>>> LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), >>>>>> connectTimeout); >>>>>> And add something like that to LdapSasl (or maybe pass the full >>>>>> env here): >>>>>> + public static void checkCbParameters(String cbTypePropertyValue, >>>>>> int connectTimeout) throws NamingException { >>>>>> +???? TlsChannelBindingType cbType = >>>>>> TlsChannelBinding.parseType(cbTypePropertyValue); >>>>>> +???? // verify LDAP channel binding property >>>>>> +???? if (cbType != null && connectTimeout == -1) { >>>>>> +???????? throw new >>>>>> NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>>>>> +???????????????? " property requires >>>>>> com.sun.jndi.ldap.connect.timeout" + >>>>>> +???????????????? " property is set."); >>>>>> +???? } >>>>>> + } >>>>>> Other LdapCtx/LdapClient/SaslBind? changes look fine to me. >>>>>> With Kind Regards, >>>>>> Aleksei >>>>>> On 06/06/2020 20:45, Alexey Bakhtin wrote: >>>>>>> Hello Max, Daniel, >>>>>>> >>>>>>> Thank you for review. >>>>>>> >>>>>>> Please review new version of the patch : >>>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >>>>>>> >>>>>>> In this version: >>>>>>> - TlsChannelBinding class is moved into the >>>>>>> com.sun.jndi.ldap.sasl package >>>>>>> - SSL Ceritificate related code is moved from LdapClient? into >>>>>>> the LdapSasl.saslBind method >>>>>>> - verification and removal of internal property is also moved to >>>>>>> LdapSasl.saslBind method >>>>>>> - verification of connectTimeout property is moved to >>>>>>> LdapCtx.connect. I?ve found that connectionTimeout could be >>>>>>> assigned later then cbType >>>>>>> >>>>>>> The test for this issue is not ready yet. I did not find any >>>>>>> suitable test case that can be reused. >>>>>>> >>>>>>> Thank you >>>>>>> Alexey >>>>>>> >>>>>>>> On 6 Jun 2020, at 09:44, Weijun Wang >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello Max, >>>>>>>>>> >>>>>>>>>> Thank you a lot for review. >>>>>>>>>> >>>>>>>>>> Could you check the new version of the patch : >>>>>>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>>>>>>> >>>>>>>>>> I?ve made the following changes: >>>>>>>>>> - TlsChannelBinding class is moved to java.naming module. >>>>>>>>>> java.security.sasl module is not affected any more >>>>>>>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you >>>>>>>>>> suggested >>>>>>>>>> - I?ve made some guards to prevent application from using >>>>>>>>>> "com.sun.security.sasl.tlschannelbinding? property directly: >>>>>>>>>> ???? - LdapClient verifies if internal property is not set >>>>>>>>> 245???????????????????? // Prepare TLS Channel Binding data >>>>>>>>> 246???????????????????? if (conn.sock instanceof SSLSocket) { >>>>>>>>> 247???????????????????????? // Internal property cannot be set >>>>>>>>> explicitly >>>>>>>>> 248???????????????????????? if >>>>>>>>> (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>>>>>>> 249???????????????????????????? throw new >>>>>>>>> NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>>>>>>> 250???????????????????????????????????? " property cannot be >>>>>>>>> set explicitly"); >>>>>>>>> 251???????????????????????? } >>>>>>>>> >>>>>>>>> If not TLS, this property value be kept there and visible >>>>>>>>> inside the SASL mech. >>>>>>>>> >>>>>>>>>> ???? - GssKrb5Client uses props.remove() to read and remove >>>>>>>>>> internal property >>>>>>>> Maybe you can remove the value in LdapClient.java, in case the >>>>>>>> mech used is not GSSAPI. You can remove it in a finally block >>>>>>>> after line 303. >>>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>>> Traditionally, we use "com.sun..." name which is a JDK >>>>>>>>> supported name (although not at Java SE level), you might want >>>>>>>>> to use a name which is even more internal. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if >>>>>>>>> I can improve the NTLM SASL mech to support it. >> From valerie.peng at oracle.com Tue Jun 9 16:52:27 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 9 Jun 2020 09:52:27 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <8BAA3715-11BC-4A39-8C96-FD04CFE1BC84@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> <386f23a8-023d-200a-04ee-545677f95614@oracle.com> <8BAA3715-11BC-4A39-8C96-FD04CFE1BC84@oracle.com> Message-ID: <2552dfed-922d-5db1-6266-d82abb11a9f9@oracle.com> Thanks for review~ As for the isProviderInfo() name, since I reverted the code for its impl to pre-7092821, I changed it back to the old name as you noticed. Sean mentioned that he also wants to take a look at this updated webrev, so I will wait for him to do that... Valerie On 6/8/2020 6:11 PM, Weijun Wang wrote: > Code change looks fine to me. > > I re-look at every place where legacyStrings and prngAlgorithms are used and they are all synchronized. Last time I thought some were not. Sorry. > > Only one comment: I like the isProviderInfo() name better, but I notice it was the old name pre-7092821. > > Thanks, > Max > > >> On Jun 9, 2020, at 6:31 AM, Valerie Peng wrote: >> >> Webrev updated: http://cr.openjdk.java.net/~valeriep/8246613/webrev.02/ >> >> Besides addressing Max's comments, I also made updateSecureRandomEntries(...) method private and removed the synchronized keyword as all of its accesses are synchronized. >> >> Thanks, >> Valerie >> On 6/8/2020 2:33 PM, Valerie Peng wrote: >>> Hi Max, >>> >>> Please find comments in line. >>> >>> On 6/8/2020 2:34 AM, Weijun Wang wrote: >>>> Looks like this should work, but still find it complicated. >>>> >>>> 1. Do we need to care about thread safety when managing legacyStrings? >>> Right, it's more complicated than I like as well. >>> >>> As for thread safety, the legacy relevant data are all synchronized under the current provider object, i.e. this. Is there a particular call path not doing this? This is the same as the pre-7092821 code. >>> >>>> 2. Does implReplaceAll() need to set legacyChanged = true? >>> Correct, the removal is by accident. Thanks for catching this. >>>> 3. How about using prngAlgorithms.iterator().next() below? >>>> >>>> 1416 return prngAlgorithms.toArray(new String[0])[0]; >>> Sure, changed. >>> >>> Valerie >>> >>>> --Max >>>> >>>> >>>>> On Jun 6, 2020, at 11:54 AM, Valerie Peng wrote: >>>>> >>>>> Thanks for reviewing and sharing the feedbacks on webrev.00. >>>>> >>>>> In order to support all existing calls for legacy registration for default secure random, I have to revert some of the JDK-7092821 changes and re-introduce the 'legacyStrings' LinkedHashMap. Updated the regression test with removal test for provider using legacy registrations as well. Although removal is supported, this is still not bullet proof as things may not work as expected if a provider registered their impl in both ways, i.e. legacy String pair and Service, and then remove/replace some entries later. Please comment if you really need this scenario to be supported. Although not explicitly documented, I think the intention is to use one or the other, never both. >>>>> >>>>> Webrev update: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>> >>>>> Thanks, >>>>> Valerie >>>>> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>>>>> Right, I try to keep the impl simple as I am not aware of any property removal usage. >>>>>> >>>>>> Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added. >>>>>> >>>>>> Valerie >>>>>> >>>>>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>>>>> I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". >>>>>>> >>>>>>> And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. >>>>>>> >>>>>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Looks good to me, one question >>>>>>>> >>>>>>>> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Prasad.K >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Valerie Peng >>>>>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>>>>> To: security-dev at openjdk.java.net >>>>>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >>>>>>>>> based on registration ordering >>>>>>>>> >>>>>>>>> Hi, Sean, >>>>>>>>> >>>>>>>>> Thanks for the review and feedback. Webrev updated: >>>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>>> >>>>>>>>> getTypeAndAlgorithm(...) was not static due to an instance variable used by >>>>>>>>> debugging output. I have removed it and made both method static. >>>>>>>>> >>>>>>>>> I will wait for others' review comments also. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Could someone help reviewing this fix? This change keep tracks of the >>>>>>>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>>>>>>> request of SecureRandom class. >>>>>>>>>> This looks good to me. I would recommend that Max or someone else >>>>>>>>>> review it as well. >>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>>>>> >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>>>>> >>>>>>>>>> * SecureRandom.java >>>>>>>>>> >>>>>>>>>> 879 // For SUN provider, we use >>>>>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>>>>> >>>>>>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>>>>>> >>>>>>>>>> * Provider.java >>>>>>>>>> >>>>>>>>>> 1156 private String parseSecureRandomPut(String name, String >>>>>>>>>> value) { >>>>>>>>>> >>>>>>>>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>>>>>>>> >>>>>>>>>> --Sean From sean.mullan at oracle.com Tue Jun 9 19:21:21 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 9 Jun 2020 15:21:21 -0400 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <2552dfed-922d-5db1-6266-d82abb11a9f9@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> <386f23a8-023d-200a-04ee-545677f95614@oracle.com> <8BAA3715-11BC-4A39-8C96-FD04CFE1BC84@oracle.com> <2552dfed-922d-5db1-6266-d82abb11a9f9@oracle.com> Message-ID: Looks good, just a couple of minor comments on the test: * test/jdk/java/security/SecureRandom/DefaultAlgo.java 75 Objects.requireNonNull(p); Not sure why you need this line, since the test never passes null. 90 validate(new SecureRandom(), pName, algos[0]); Is there a reason why you don't call removeService for each algorithm when testing the non-legacy provider? --Sean On 6/9/20 12:52 PM, Valerie Peng wrote: > Thanks for review~ > > As for the isProviderInfo() name, since I reverted the code for its impl > to pre-7092821, I changed it back to the old name as you noticed. Sean > mentioned that he also wants to take a look at this updated webrev, so I > will wait for him to do that... > > Valerie > > On 6/8/2020 6:11 PM, Weijun Wang wrote: >> Code change looks fine to me. >> >> I re-look at every place where legacyStrings and prngAlgorithms are >> used and they are all synchronized. Last time I thought some were not. >> Sorry. >> >> Only one comment: I like the isProviderInfo() name better, but I >> notice it was the old name pre-7092821. >> >> Thanks, >> Max >> >> >>> On Jun 9, 2020, at 6:31 AM, Valerie Peng >>> wrote: >>> >>> Webrev updated: http://cr.openjdk.java.net/~valeriep/8246613/webrev.02/ >>> >>> Besides addressing Max's comments, I also made >>> updateSecureRandomEntries(...) method private and removed the >>> synchronized keyword as all of its accesses are synchronized. >>> >>> Thanks, >>> Valerie >>> On 6/8/2020 2:33 PM, Valerie Peng wrote: >>>> Hi Max, >>>> >>>> Please find comments in line. >>>> >>>> On 6/8/2020 2:34 AM, Weijun Wang wrote: >>>>> Looks like this should work, but still find it complicated. >>>>> >>>>> 1. Do we need to care about thread safety when managing legacyStrings? >>>> Right, it's more complicated than I like as well. >>>> >>>> As for thread safety, the legacy relevant data are all synchronized >>>> under the current provider object, i.e. this. Is there a particular >>>> call path not doing this? This is the same as the pre-7092821 code. >>>> >>>>> 2. Does implReplaceAll() need to set legacyChanged = true? >>>> Correct, the removal is by accident. Thanks for catching this. >>>>> 3. How about using prngAlgorithms.iterator().next() below? >>>>> >>>>> ??? 1416???? return prngAlgorithms.toArray(new String[0])[0]; >>>> Sure, changed. >>>> >>>> Valerie >>>> >>>>> --Max >>>>> >>>>> >>>>>> On Jun 6, 2020, at 11:54 AM, Valerie Peng >>>>>> wrote: >>>>>> >>>>>> Thanks for reviewing and sharing the feedbacks on webrev.00. >>>>>> >>>>>> In order to support all existing calls for legacy registration for >>>>>> default secure random, I have to revert some of the JDK-7092821 >>>>>> changes and re-introduce the 'legacyStrings' LinkedHashMap. >>>>>> Updated the regression test with removal test for provider using >>>>>> legacy registrations as well. Although removal is supported, this >>>>>> is still not bullet proof as things may not work as expected if a >>>>>> provider registered their impl in both ways, i.e. legacy String >>>>>> pair and Service, and then remove/replace some entries later. >>>>>> Please comment if you really need this scenario to be supported. >>>>>> Although not explicitly documented, I think the intention is to >>>>>> use one or the other, never both. >>>>>> >>>>>> Webrev update: >>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>>>>>> Right, I try to keep the impl simple as I am not aware of any >>>>>>> property removal usage. >>>>>>> >>>>>>> Oh-well, if we have to cater to the removal scenario, then we'd >>>>>>> have to add a List and keep track of ALL secure random algos >>>>>>> instead of only the FIRST one. Alright, I guess it costs for >>>>>>> covering all aspect. But one extra benefit of this is that it >>>>>>> should be easy to handle the future JDK property such as >>>>>>> "jdk.securerandom.disabledAlgorithms" if it were to be added. >>>>>>> >>>>>>> Valerie >>>>>>> >>>>>>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>>>>>> I don't know who in this world would want to do that, but >>>>>>>> Prasad's concern is technically possible. I tried >>>>>>>> 'p.remove("SecureRandom.a")' in the new test, and new >>>>>>>> SecureRandom() fails with >>>>>>>> "java.security.NoSuchAlgorithmException: a SecureRandom not >>>>>>>> available". >>>>>>>> >>>>>>>> And people can also remove one entry and add it back in order to >>>>>>>> move it to the end. One can even add new implementations this way. >>>>>>>> >>>>>>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Looks good to me, one question >>>>>>>>> >>>>>>>>> If first registered SecureRandom algo gets removed, >>>>>>>>> getDefaultSecureRandomAlgorithm return stale data, a refresh >>>>>>>>> required in remove? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Prasad.K >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Valerie Peng >>>>>>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>>>>>> To: security-dev at openjdk.java.net >>>>>>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default >>>>>>>>>> SecureRandom algo >>>>>>>>>> based on registration ordering >>>>>>>>>> >>>>>>>>>> Hi, Sean, >>>>>>>>>> >>>>>>>>>> Thanks for the review and feedback. Webrev updated: >>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>>>> >>>>>>>>>> getTypeAndAlgorithm(...) was not static due to an instance >>>>>>>>>> variable used by >>>>>>>>>> debugging output. I have removed it and made both method static. >>>>>>>>>> >>>>>>>>>> I will wait for others' review comments also. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Could someone help reviewing this fix? This change keep >>>>>>>>>>>> tracks of the >>>>>>>>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>>>>>>>> request of SecureRandom class. >>>>>>>>>>> This looks good to me. I would recommend that Max or someone >>>>>>>>>>> else >>>>>>>>>>> review it as well. >>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>>>>>> >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>>>>>> >>>>>>>>>>> * SecureRandom.java >>>>>>>>>>> >>>>>>>>>>> 879???????????? // For SUN provider, we use >>>>>>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>>>>>> >>>>>>>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>>>>>>> >>>>>>>>>>> * Provider.java >>>>>>>>>>> >>>>>>>>>>> 1156???? private String parseSecureRandomPut(String name, String >>>>>>>>>>> value) { >>>>>>>>>>> >>>>>>>>>>> Could be static if you also make getTypeAndAlgorithm static, >>>>>>>>>>> I think. >>>>>>>>>>> >>>>>>>>>>> --Sean From alexey at azul.com Tue Jun 9 21:03:02 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 9 Jun 2020 21:03:02 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> Message-ID: <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> Hello Aleks, Thank you very much for review. I?ve fixed missed spaces and removed casting from LdapSasl.java Failure of the SaslMutual test was caused by prop.remove() in the GssKrb5Client This operation is not required any more. GssKrb5Client receives temporary copy of the properties. Fixed Also, I?ve added references to RFC-5929 and RFC-5056 into the TlsChannelBinding class Updated patch is located at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v7/ Regards Alexey > On 9 Jun 2020, at 15:59, Aleks Efimov wrote: > > Hi Alexey, > > Thank you for incorporating LdapCtx and LdapSasl changes. I've reviewed both classes and they look good to me, with few minor comments in LdapSasl.java: > missing spaces in the following lines: 78, 152 > With your last changes we can remove explicit cast of 'envProps' on line 176 > > I've also run your changes through our CI and one test is failing due to the changes in GssKrb5Client: > The failed test name: sun/security/krb5/auto/SaslMutual.java > > The observed failure: > java.lang.UnsupportedOperationException > at java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:127) > at java.base/java.util.ImmutableCollections$AbstractImmutableMap.remove(ImmutableCollections.java:910) > at jdk.security.jgss/com.sun.security.sasl.gsskerb.GssKrb5Client.(GssKrb5Client.java:156) > at jdk.security.jgss/com.sun.security.sasl.gsskerb.FactoryImpl.createSaslClient(FactoryImpl.java:63) > at java.security.sasl/javax.security.sasl.Sasl.createSaslClient(Sasl.java:433) > at SaslMutual.main(SaslMutual.java:50) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:832) > > > For information about CSR process you can start from this wiki page: https://wiki.openjdk.java.net/display/csr > > Best Regards, > Aleksei > > On 08/06/2020 22:33, Alexey Bakhtin wrote: >> Hello Sean, >> >> Yes, I think we'll need CSR and release notes as soon as this patch adds new property. >> I do not know exact process for it, so I will be grateful if you could explain me exact steps. >> >> This patch was developed to address compatibility issue with new LDAP authentication over SSL/TLS announced by Microsoft [1]. It is not related to RFC 5801. In my opinion ?com.sun.jndi.ldap.tls.cbtype? name looks more suitable for this property and should allow backport it to early JDK versions. >> >> [1] - >> https://support.microsoft.com/en-au/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry >> >> Regards >> Alexey >> >> >>> On 8 Jun 2020, at 22:03, Sean Mullan >>> wrote: >>> >>> (resending to all lists on the review) >>> >>> I'm just catching up a bit on this review. >>> >>> Sorry if this has mentioned before, but are you planning to write a CSR and release note? I think this is needed for the com.sun.jndi.ldap.tls.cbtype property. I'm also wondering if this property should be documented in the javadocs, and why it is not a standard property (i.e. "java.naming.ldap.tls.cbtype"). >>> >>> I was also wondering what relation this has to the "G2" standard SASL mechanisms defined in RFC 5801 [1], and whether that is something we should be using to negotiate this channel binding, and if not, why not. Or if this is something that is implementation-specific and will only work with Microsoft LDAP technology, in which case, we might want to make that more explicit, perhaps by including "microsoft" or something like that in the property name. >>> >>> Thanks, >>> Sean >>> >>> [1] >>> https://tools.ietf.org/html/rfc5801 >>> >>> >>> On 6/8/20 9:07 AM, Aleks Efimov wrote: >>> >>>> Hi Alexey, >>>> I've looked through LdapCtx/LdapClient/SaslBind changes: >>>> Do we need to check if CHANNEL_BINDING is set explicitly for all connection types? Maybe we can move the check inside 'if (conn.sock instanceof SSLSocket) {' block. >>>> Also, instead of setting CHANNEL_BINDING in context environment and then removing it in finally block, it would be better to clone the environment, put calculated CHANNEL_BINDING into it, and pass the cloned one to Sasl.createSaslClient. >>>> Another suggestion about the code that verifies if both properties are set before connection is started: >>>> As you've already mentioned the new code in LdapCtx is only needed for checking if timeout is set. Could we try to remove LdapCtx::cbType field and all related methods from LdapCtx (this class is already over-complicated and hard to read) and replace it with some static method in LdapSasl? It will help to localize all changes to LdapSasl except for one line in LdapCtx. >>>> I mean something like this: >>>> Replace >>>> + >>>> + // verify LDAP channel binding property >>>> + if (cbType != null && connectTimeout == -1) >>>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>>> + " property requires " + >>>> + CONNECT_TIMEOUT + >>>> + " property is set."); >>>> With >>>> + LdapSasl.checkCbParameters((String)envprops.get(TlsChannelBinding.CHANNEL_BINDING_TYPE), connectTimeout); >>>> And add something like that to LdapSasl (or maybe pass the full env here): >>>> + public static void checkCbParameters(String cbTypePropertyValue, int connectTimeout) throws NamingException { >>>> + TlsChannelBindingType cbType = TlsChannelBinding.parseType(cbTypePropertyValue); >>>> + // verify LDAP channel binding property >>>> + if (cbType != null && connectTimeout == -1) { >>>> + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + >>>> + " property requires com.sun.jndi.ldap.connect.timeout" + >>>> + " property is set."); >>>> + } >>>> + } >>>> Other LdapCtx/LdapClient/SaslBind changes look fine to me. >>>> With Kind Regards, >>>> Aleksei >>>> On 06/06/2020 20:45, Alexey Bakhtin wrote: >>>> >>>>> Hello Max, Daniel, >>>>> >>>>> Thank you for review. >>>>> >>>>> Please review new version of the patch : >>>>> >>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v5/ >>>>> >>>>> >>>>> In this version: >>>>> - TlsChannelBinding class is moved into the com.sun.jndi.ldap.sasl package >>>>> - SSL Ceritificate related code is moved from LdapClient into the LdapSasl.saslBind method >>>>> - verification and removal of internal property is also moved to LdapSasl.saslBind method >>>>> - verification of connectTimeout property is moved to LdapCtx.connect. I?ve found that connectionTimeout could be assigned later then cbType >>>>> >>>>> The test for this issue is not ready yet. I did not find any suitable test case that can be reused. >>>>> >>>>> Thank you >>>>> Alexey >>>>> >>>>> >>>>>> On 6 Jun 2020, at 09:44, Weijun Wang >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 6, 2020, at 2:41 PM, Weijun Wang >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 5, 2020, at 11:03 PM, Alexey Bakhtin >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello Max, >>>>>>>> >>>>>>>> Thank you a lot for review. >>>>>>>> >>>>>>>> Could you check the new version of the patch : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v4/ >>>>>>>> >>>>>>>> >>>>>>>> I?ve made the following changes: >>>>>>>> - TlsChannelBinding class is moved to java.naming module. >>>>>>>> java.security.sasl module is not affected any more >>>>>>>> - I pass tlsCB.getData() directly to the SASL mechanism as you suggested >>>>>>>> - I?ve made some guards to prevent application from using "com.sun.security.sasl.tlschannelbinding? property directly: >>>>>>>> - LdapClient verifies if internal property is not set >>>>>>>> >>>>>>> 245 // Prepare TLS Channel Binding data >>>>>>> 246 if (conn.sock instanceof SSLSocket) { >>>>>>> 247 // Internal property cannot be set explicitly >>>>>>> 248 if (env.get(TlsChannelBinding.CHANNEL_BINDING) != null) { >>>>>>> 249 throw new NamingException(TlsChannelBinding.CHANNEL_BINDING + >>>>>>> 250 " property cannot be set explicitly"); >>>>>>> 251 } >>>>>>> >>>>>>> If not TLS, this property value be kept there and visible inside the SASL mech. >>>>>>> >>>>>>> >>>>>>>> - GssKrb5Client uses props.remove() to read and remove internal property >>>>>>>> >>>>>> Maybe you can remove the value in LdapClient.java, in case the mech used is not GSSAPI. You can remove it in a finally block after line 303. >>>>>> >>>>>> --Max >>>>>> >>>>>> >>>>>>> Traditionally, we use "com.sun..." name which is a JDK supported name (although not at Java SE level), you might want to use a name which is even more internal. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> p.s. I see that NTLM also supports ChannelBinding. I'll see if I can improve the NTLM SASL mech to support it. >>>>>>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From tigran.mkrtchyan at desy.de Tue Jun 9 21:15:19 2020 From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran) Date: Tue, 9 Jun 2020 23:15:19 +0200 (CEST) Subject: Thread leak by LdapLoginModule Message-ID: <889628466.1257399.1591737319316.JavaMail.zimbra@desy.de> Hi all, with Java-11 we have notice a thread leak with ldap module. We use LDAP to authenticate users with username+pasword by directly calling LdapLoginModule. This was ok with java 7 and java 8. With java 11 we see threads getting accumulated. here is a test case that demonstrates it: ``` private static final String USERNAME_KEY = "javax.security.auth.login.name"; private static final String PASSWORD_KEY = "javax.security.auth.login.password"; String ldapUrl = "ldap://...."; String peopleOU = "ou= ... o= ... c=..."); String user = ...; String pass = ...; @Test public void threadLeakTest() throws AuthenticationException, NoSuchPrincipalException, LoginException { Map threadsBefore = Thread.getAllStackTraces(); Map globalLoginOptions = Map.of( "userProvider", ldapUrl + "/" + peopleOU, "useSSL", "false", "userFilter", "(uid={USERNAME})", "useFirstPass", "true" ); for (int i = 0; i < 10; i++) { Map loginOptions = Map.of( USERNAME_KEY, user, PASSWORD_KEY, pass.toCharArray()); Subject subject = new Subject(); LdapLoginModule loginModule = new LdapLoginModule(); loginModule.initialize(subject, null, loginOptions, globalLoginOptions); loginModule.login(); loginModule.commit(); loginModule.logout(); } Map threadsAfter = Thread.getAllStackTraces(); assertEquals("Thread leak detected", threadsBefore.size() + 1, threadsAfter.size()); } ``` The thread count difference is always equals to the number of iterations in the loop, e.g. on each call a thread is created and stays around. Eventually our server crashes with: [19497.011s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007fcc4c65c000-0x00007fcc4c660000). OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007fcc4c55b000, 16384, 0) failed; error='Not enough space' (errno=12) The issue is not observed with java-14, thus I assume that the fix is related to commit http://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 As java-11 is LTS, what is the procedure to get it fix back-ported? Regards, Tigran. From anthony.scarpino at oracle.com Tue Jun 9 22:12:27 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 9 Jun 2020 15:12:27 -0700 Subject: 8245686: Ed25519 and Ed448 present in handshake messages Message-ID: <69f9a4bb-d3b1-83c4-73b2-19d4cb5916b9@oracle.com> Hi, I need a code review of this very simple change for a situation that I'm not sure is a problem in the real world. The original TLS 1.3 putback added EdDSA to the TLS signature extensions enumeration before there was an EdDSA JCE implementation or JSSE support. Without an implementation, a signature checks would not include EdDSA for TLS extensions, signature_algorithms and signature_algorithm_cert. Now with JCE EdDSA support, the signature check adds EdDSA to the extension, despite JSSE not having support yet (JDK-8166596). This causes a signature scheme authentication failure, and JSSE moves onto the next certificate provided. The only time this is a problem is if EdDSA is the only cert provided. I'm not sure how realistic it is for one certificate to be provided. If someone knows multiple certificates are always available, I'm happy to not make this change. The fix is a simple check in the constructor to set the curves unavailable after the signature check. This code can be deleted when JDK-8166596 is fixed in jdk16. I had thought about commenting out the enums, but then the logging code would not know what the id's were when other clients and servers passed them to JSSE. https://cr.openjdk.java.net/~ascarpino/8245686/webrev/ Tony From sean.mullan at oracle.com Tue Jun 9 22:21:50 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 9 Jun 2020 18:21:50 -0400 Subject: Thread leak by LdapLoginModule In-Reply-To: <889628466.1257399.1591737319316.JavaMail.zimbra@desy.de> References: <889628466.1257399.1591737319316.JavaMail.zimbra@desy.de> Message-ID: <5e5f3f91-bdc2-7af2-7b41-894484de7f61@oracle.com> Adding core-libs-dev ... --Sean On 6/9/20 5:15 PM, Mkrtchyan, Tigran wrote: > > Hi all, > > with Java-11 we have notice a thread leak with ldap module. > We use LDAP to authenticate users with username+pasword by > directly calling LdapLoginModule. This was ok with java 7 and > java 8. With java 11 we see threads getting accumulated. here is a > test case that demonstrates it: > > ``` > > private static final String USERNAME_KEY = "javax.security.auth.login.name"; > private static final String PASSWORD_KEY = "javax.security.auth.login.password"; > > String ldapUrl = "ldap://...."; > String peopleOU = "ou= ... o= ... c=..."); > > String user = ...; > String pass = ...; > > > @Test > public void threadLeakTest() throws AuthenticationException, NoSuchPrincipalException, LoginException { > > Map threadsBefore = Thread.getAllStackTraces(); > > Map globalLoginOptions = Map.of( > "userProvider", ldapUrl + "/" + peopleOU, > "useSSL", "false", > "userFilter", "(uid={USERNAME})", > "useFirstPass", "true" > ); > > for (int i = 0; i < 10; i++) { > > Map loginOptions = Map.of( > USERNAME_KEY, user, > PASSWORD_KEY, pass.toCharArray()); > > Subject subject = new Subject(); > > LdapLoginModule loginModule = new LdapLoginModule(); > loginModule.initialize(subject, null, loginOptions, globalLoginOptions); > loginModule.login(); > loginModule.commit(); > loginModule.logout(); > } > > Map threadsAfter = Thread.getAllStackTraces(); > > assertEquals("Thread leak detected", threadsBefore.size() + 1, threadsAfter.size()); > } > > ``` > > The thread count difference is always equals to the number of iterations in the loop, e.g. on each call a > thread is created and stays around. Eventually our server crashes with: > > [19497.011s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007fcc4c65c000-0x00007fcc4c660000). > OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007fcc4c55b000, 16384, 0) failed; error='Not enough space' (errno=12) > > The issue is not observed with java-14, thus I assume that the fix is related to commit > > http://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 > > As java-11 is LTS, what is the procedure to get it fix back-ported? > > Regards, > Tigran. > From jamil.j.nimeh at oracle.com Tue Jun 9 22:23:02 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 9 Jun 2020 15:23:02 -0700 Subject: 8245686: Ed25519 and Ed448 present in handshake messages In-Reply-To: <69f9a4bb-d3b1-83c4-73b2-19d4cb5916b9@oracle.com> References: <69f9a4bb-d3b1-83c4-73b2-19d4cb5916b9@oracle.com> Message-ID: <1a392efe-c1ca-436e-75f7-fdc90ff5e334@oracle.com> Looks fine to me. --Jamil On 6/9/2020 3:12 PM, Anthony Scarpino wrote: > Hi, > > I need a code review of this very simple change for a situation that > I'm not sure is a problem in the real world. > > The original TLS 1.3 putback added EdDSA to the TLS signature > extensions enumeration before there was an EdDSA JCE implementation or > JSSE support.? Without an implementation, a signature checks would not > include EdDSA for TLS extensions, signature_algorithms and > signature_algorithm_cert.? Now with JCE EdDSA support, the signature > check adds EdDSA to the extension, despite JSSE not having support yet > (JDK-8166596).? This causes a signature scheme authentication failure, > and JSSE moves onto the next certificate provided. > > The only time this is a problem is if EdDSA is the only cert provided. > I'm not sure how realistic it is for one certificate to be provided.? > If someone knows multiple certificates are always available, I'm happy > to not make this change. > > The fix is a simple check in the constructor to set the curves > unavailable after the signature check.? This code can be deleted when > JDK-8166596 is fixed in jdk16.? I had thought about commenting out the > enums, but then the logging code would not know what the id's were > when other clients and servers passed them to JSSE. > > https://cr.openjdk.java.net/~ascarpino/8245686/webrev/ > > Tony From jamil.j.nimeh at oracle.com Tue Jun 9 22:58:07 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 9 Jun 2020 15:58:07 -0700 Subject: [RFR] 8241680: KeyPairGen & Signature microbenchmarks need updating for disabled EC curves In-Reply-To: References: Message-ID: <60439b6b-ef65-e1f9-a565-0c12cb5336f4@oracle.com> +1 --Jamil On 6/8/2020 12:22 PM, Sergey Kuksenko wrote: > Looks fine to me. > > On 6/8/20 11:15 AM, Anthony Scarpino wrote: >> Hi, >> >> I need a quick code review of updates to the microbenchmarks tests >> for EC.? These tests used curves that are now disabled by default in 15. >> >> https://cr.openjdk.java.net/~ascarpino/8241680/webrev/ >> >> thanks >> >> Tony From xuelei.fan at oracle.com Tue Jun 9 23:04:53 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 9 Jun 2020 16:04:53 -0700 Subject: 8245686: Ed25519 and Ed448 present in handshake messages In-Reply-To: <69f9a4bb-d3b1-83c4-73b2-19d4cb5916b9@oracle.com> References: <69f9a4bb-d3b1-83c4-73b2-19d4cb5916b9@oracle.com> Message-ID: A simple fix like this looks good to me. I may check this first, before the EC available and signature checking. Xuelei On 6/9/2020 3:12 PM, Anthony Scarpino wrote: > Hi, > > I need a code review of this very simple change for a situation that I'm > not sure is a problem in the real world. > > The original TLS 1.3 putback added EdDSA to the TLS signature extensions > enumeration before there was an EdDSA JCE implementation or JSSE > support.? Without an implementation, a signature checks would not > include EdDSA for TLS extensions, signature_algorithms and > signature_algorithm_cert.? Now with JCE EdDSA support, the signature > check adds EdDSA to the extension, despite JSSE not having support yet > (JDK-8166596).? This causes a signature scheme authentication failure, > and JSSE moves onto the next certificate provided. > > The only time this is a problem is if EdDSA is the only cert provided. > I'm not sure how realistic it is for one certificate to be provided.? If > someone knows multiple certificates are always available, I'm happy to > not make this change. > > The fix is a simple check in the constructor to set the curves > unavailable after the signature check.? This code can be deleted when > JDK-8166596 is fixed in jdk16.? I had thought about commenting out the > enums, but then the logging code would not know what the id's were when > other clients and servers passed them to JSSE. > > https://cr.openjdk.java.net/~ascarpino/8245686/webrev/ > > Tony From valerie.peng at oracle.com Tue Jun 9 23:53:00 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 9 Jun 2020 16:53:00 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> <386f23a8-023d-200a-04ee-545677f95614@oracle.com> <8BAA3715-11BC-4A39-8C96-FD04CFE1BC84@oracle.com> <2552dfed-922d-5db1-6266-d82abb11a9f9@oracle.com> Message-ID: <0f0fecf1-a995-4e7c-a68f-841c70d01638@oracle.com> Hi, Sean, On 6/9/2020 12:21 PM, Sean Mullan wrote: > Looks good, just a couple of minor comments on the test: > > * test/jdk/java/security/SecureRandom/DefaultAlgo.java > > 75???????? Objects.requireNonNull(p); > > Not sure why you need this line, since the test never passes null. True, the test never passes null, this line is just to make it clear that the provider argument should not be null as the test is not prepared to handle null provider. It's not essential, so I removed it per your comment. > > 90???????????????? validate(new SecureRandom(), pName, algos[0]); > > Is there a reason why you don't call removeService for each algorithm > when testing the non-legacy provider? The Provider.removeService(...) call is protected. So, it's not a public API for users of Provider objects. Thanks, Valerie > > --Sean > > On 6/9/20 12:52 PM, Valerie Peng wrote: >> Thanks for review~ >> >> As for the isProviderInfo() name, since I reverted the code for its >> impl to pre-7092821, I changed it back to the old name as you >> noticed. Sean mentioned that he also wants to take a look at this >> updated webrev, so I will wait for him to do that... >> >> Valerie >> >> On 6/8/2020 6:11 PM, Weijun Wang wrote: >>> Code change looks fine to me. >>> >>> I re-look at every place where legacyStrings and prngAlgorithms are >>> used and they are all synchronized. Last time I thought some were >>> not. Sorry. >>> >>> Only one comment: I like the isProviderInfo() name better, but I >>> notice it was the old name pre-7092821. >>> >>> Thanks, >>> Max >>> >>> >>>> On Jun 9, 2020, at 6:31 AM, Valerie Peng >>>> wrote: >>>> >>>> Webrev updated: >>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.02/ >>>> >>>> Besides addressing Max's comments, I also made >>>> updateSecureRandomEntries(...) method private and removed the >>>> synchronized keyword as all of its accesses are synchronized. >>>> >>>> Thanks, >>>> Valerie >>>> On 6/8/2020 2:33 PM, Valerie Peng wrote: >>>>> Hi Max, >>>>> >>>>> Please find comments in line. >>>>> >>>>> On 6/8/2020 2:34 AM, Weijun Wang wrote: >>>>>> Looks like this should work, but still find it complicated. >>>>>> >>>>>> 1. Do we need to care about thread safety when managing >>>>>> legacyStrings? >>>>> Right, it's more complicated than I like as well. >>>>> >>>>> As for thread safety, the legacy relevant data are all >>>>> synchronized under the current provider object, i.e. this. Is >>>>> there a particular call path not doing this? This is the same as >>>>> the pre-7092821 code. >>>>> >>>>>> 2. Does implReplaceAll() need to set legacyChanged = true? >>>>> Correct, the removal is by accident. Thanks for catching this. >>>>>> 3. How about using prngAlgorithms.iterator().next() below? >>>>>> >>>>>> ??? 1416???? return prngAlgorithms.toArray(new String[0])[0]; >>>>> Sure, changed. >>>>> >>>>> Valerie >>>>> >>>>>> --Max >>>>>> >>>>>> >>>>>>> On Jun 6, 2020, at 11:54 AM, Valerie Peng >>>>>>> wrote: >>>>>>> >>>>>>> Thanks for reviewing and sharing the feedbacks on webrev.00. >>>>>>> >>>>>>> In order to support all existing calls for legacy registration >>>>>>> for default secure random, I have to revert some of the >>>>>>> JDK-7092821 changes and re-introduce the 'legacyStrings' >>>>>>> LinkedHashMap. Updated the regression test with removal test for >>>>>>> provider using legacy registrations as well. Although removal is >>>>>>> supported, this is still not bullet proof as things may not work >>>>>>> as expected if a provider registered their impl in both ways, >>>>>>> i.e. legacy String pair and Service, and then remove/replace >>>>>>> some entries later. Please comment if you really need this >>>>>>> scenario to be supported. Although not explicitly documented, I >>>>>>> think the intention is to use one or the other, never both. >>>>>>> >>>>>>> Webrev update: >>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>>>>>>> Right, I try to keep the impl simple as I am not aware of any >>>>>>>> property removal usage. >>>>>>>> >>>>>>>> Oh-well, if we have to cater to the removal scenario, then we'd >>>>>>>> have to add a List and keep track of ALL secure random algos >>>>>>>> instead of only the FIRST one. Alright, I guess it costs for >>>>>>>> covering all aspect. But one extra benefit of this is that it >>>>>>>> should be easy to handle the future JDK property such as >>>>>>>> "jdk.securerandom.disabledAlgorithms" if it were to be added. >>>>>>>> >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>>>>>>> I don't know who in this world would want to do that, but >>>>>>>>> Prasad's concern is technically possible. I tried >>>>>>>>> 'p.remove("SecureRandom.a")' in the new test, and new >>>>>>>>> SecureRandom() fails with >>>>>>>>> "java.security.NoSuchAlgorithmException: a SecureRandom not >>>>>>>>> available". >>>>>>>>> >>>>>>>>> And people can also remove one entry and add it back in order >>>>>>>>> to move it to the end. One can even add new implementations >>>>>>>>> this way. >>>>>>>>> >>>>>>>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>>>>>>> >>>>>>>>> --Max >>>>>>>>> >>>>>>>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Looks good to me, one question >>>>>>>>>> >>>>>>>>>> If first registered SecureRandom algo gets removed, >>>>>>>>>> getDefaultSecureRandomAlgorithm return stale data, a refresh >>>>>>>>>> required in remove? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Prasad.K >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Valerie Peng >>>>>>>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>>>>>>> To: security-dev at openjdk.java.net >>>>>>>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default >>>>>>>>>>> SecureRandom algo >>>>>>>>>>> based on registration ordering >>>>>>>>>>> >>>>>>>>>>> Hi, Sean, >>>>>>>>>>> >>>>>>>>>>> Thanks for the review and feedback. Webrev updated: >>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> getTypeAndAlgorithm(...) was not static due to an instance >>>>>>>>>>> variable used by >>>>>>>>>>> debugging output. I have removed it and made both method >>>>>>>>>>> static. >>>>>>>>>>> >>>>>>>>>>> I will wait for others' review comments also. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Could someone help reviewing this fix? This change keep >>>>>>>>>>>>> tracks of the >>>>>>>>>>>>> first registered SecureRandom algorithm and returns it >>>>>>>>>>>>> upon the >>>>>>>>>>>>> request of SecureRandom class. >>>>>>>>>>>> This looks good to me. I would recommend that Max or >>>>>>>>>>>> someone else >>>>>>>>>>>> review it as well. >>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>>>>>>> >>>>>>>>>>>> * SecureRandom.java >>>>>>>>>>>> >>>>>>>>>>>> 879???????????? // For SUN provider, we use >>>>>>>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>>>>>>> >>>>>>>>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>>>>>>>> >>>>>>>>>>>> * Provider.java >>>>>>>>>>>> >>>>>>>>>>>> 1156???? private String parseSecureRandomPut(String name, >>>>>>>>>>>> String >>>>>>>>>>>> value) { >>>>>>>>>>>> >>>>>>>>>>>> Could be static if you also make getTypeAndAlgorithm >>>>>>>>>>>> static, I think. >>>>>>>>>>>> >>>>>>>>>>>> --Sean From bradford.wetmore at oracle.com Wed Jun 10 00:23:19 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 9 Jun 2020 17:23:19 -0700 Subject: 8245686: Ed25519 and Ed448 present in handshake messages In-Reply-To: References: <69f9a4bb-d3b1-83c4-73b2-19d4cb5916b9@oracle.com> Message-ID: <70a3843d-5f62-31d2-a543-dde351e358bc@oracle.com> Update the year, but otherwise looks good. Brad On 6/9/2020 4:04 PM, Xuelei Fan wrote: > A simple fix like this looks good to me.? I may check this first, before > the EC available and signature checking. > > Xuelei > > On 6/9/2020 3:12 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this very simple change for a situation that >> I'm not sure is a problem in the real world. >> >> The original TLS 1.3 putback added EdDSA to the TLS signature >> extensions enumeration before there was an EdDSA JCE implementation or >> JSSE support.? Without an implementation, a signature checks would not >> include EdDSA for TLS extensions, signature_algorithms and >> signature_algorithm_cert.? Now with JCE EdDSA support, the signature >> check adds EdDSA to the extension, despite JSSE not having support yet >> (JDK-8166596).? This causes a signature scheme authentication failure, >> and JSSE moves onto the next certificate provided. >> >> The only time this is a problem is if EdDSA is the only cert provided. >> I'm not sure how realistic it is for one certificate to be provided. >> If someone knows multiple certificates are always available, I'm happy >> to not make this change. >> >> The fix is a simple check in the constructor to set the curves >> unavailable after the signature check.? This code can be deleted when >> JDK-8166596 is fixed in jdk16.? I had thought about commenting out the >> enums, but then the logging code would not know what the id's were >> when other clients and servers passed them to JSSE. >> >> https://cr.openjdk.java.net/~ascarpino/8245686/webrev/ >> >> Tony From weijun.wang at oracle.com Wed Jun 10 00:58:46 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 10 Jun 2020 08:58:46 +0800 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> <77CE09E4-0A4F-41D1-A950-9CAF71F2317B@oracle.com> Message-ID: <8C294257-35F0-420A-BC93-A75C017A5C6B@oracle.com> Good to see both -keystore and -trustcacerts mentioned. Some comments: 1. I think there is no need to say "from -file cert_file". Or, do you mean the new function does not apply to those from -sslserver and -jarfile? If so, that might be a problem. 2. While you said "attempts to construct a chain of trust", do you also want to describe what happens if it succeeds or fails? 3. It will be nice if you can include the exact diff of the man page files either inside the CSR itself or as a comment. Thanks, Max > On Jun 9, 2020, at 10:51 PM, Hai-May Chao wrote: > > > >> On Jun 7, 2020, at 6:08 PM, Weijun Wang wrote: >> >> Looks fine to me. >> >> For CSR, since there is already a "Note" there for these 2 options, you can add a few words about what -keystore and -trustcacerts can do. > > Updated CSR as suggested. > > Thanks, > Hai-May > > >> >> Thanks, >> Max >> >>> On Jun 8, 2020, at 4:01 AM, Hai-May Chao wrote: >>> >>> Updated webrev - >>> >>> https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ >>> >>> Thanks, >>> Hai-May >>> >>> >>>> On Jun 5, 2020, at 11:04 PM, Weijun Wang wrote: >>>> >>>> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. >>>> >>>> Same for line 80 and line 96 of TrustedCRL.java. >>>> >>>> Everything else is fine. >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: >>>>> >>>>> Updated webrev - >>>>> >>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>>>> >>>>> Added one command line -importcert in TrustCert.java. >>>>> Added createCacerts() in test/lib SecurityTools.java. >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>> >>>>> >>>>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>>>>> >>>>>>>> The source change looks fine to me. >>>>>>>> >>>>>>>> In TrustedCert.java: >>>>>>>> >>>>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>>>>> >>>>>>> This cat() is taken from WealAlg.java. >>>>>>> >>>>>>>> >>>>>>>> - There is no need to recreate root.jks and root.pem. >>>>>>> >>>>>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>>>>> >>>>>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>>>>> >>>>>>> >>>>>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>>>>> >>>>>>>> >>>>>>>> - Why not use -trustcacerts below? >>>>>>>> >>>>>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>>>>> >>>>>>> >>>>>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>>>>> >>>>>> OK. >>>>>> >>>>>> Then how about we add a new command before line 155? >>>>>> >>>>>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>>>> >>>>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>>>>> >>>>>>> Ok, will change it. >>>>>>> >>>>>>>> >>>>>>>> In TrustedCRL.java: >>>>>>>> >>>>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>>>>> >>>>>>> Same reply as above. >>>>>> >>>>>> Same question as above. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>>>>> >>>>>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>>>>> >>>>>>>> >>>>>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>>>>> >>>>>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>>>>> >>>>>> I meant creating the cacerts in one method, something like >>>>>> >>>>>> void createCacerts(String ks, String... crt); >>>>>> >>>>>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>>>>> >>>>>> BTW, what does caks.size() == 0 matter here? >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Hai-May >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I?d like to request a review for: >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>>>> >>>>>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Hai-May >>>>> >>>> >>> >> > From anthony.scarpino at oracle.com Wed Jun 10 04:09:08 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 9 Jun 2020 21:09:08 -0700 Subject: 8245686: Ed25519 and Ed448 present in handshake messages In-Reply-To: References: <69f9a4bb-d3b1-83c4-73b2-19d4cb5916b9@oracle.com> Message-ID: <0084833f-6d34-c1ef-f8a6-cddb4e8e0831@oracle.com> Thanks for the comment.. I moved the code up toward the top. Tony On 6/9/20 4:04 PM, Xuelei Fan wrote: > A simple fix like this looks good to me.? I may check this first, before > the EC available and signature checking. > > Xuelei > > On 6/9/2020 3:12 PM, Anthony Scarpino wrote: >> Hi, >> >> I need a code review of this very simple change for a situation that >> I'm not sure is a problem in the real world. >> >> The original TLS 1.3 putback added EdDSA to the TLS signature >> extensions enumeration before there was an EdDSA JCE implementation or >> JSSE support.? Without an implementation, a signature checks would not >> include EdDSA for TLS extensions, signature_algorithms and >> signature_algorithm_cert.? Now with JCE EdDSA support, the signature >> check adds EdDSA to the extension, despite JSSE not having support yet >> (JDK-8166596).? This causes a signature scheme authentication failure, >> and JSSE moves onto the next certificate provided. >> >> The only time this is a problem is if EdDSA is the only cert provided. >> I'm not sure how realistic it is for one certificate to be provided. >> If someone knows multiple certificates are always available, I'm happy >> to not make this change. >> >> The fix is a simple check in the constructor to set the curves >> unavailable after the signature check.? This code can be deleted when >> JDK-8166596 is fixed in jdk16.? I had thought about commenting out the >> enums, but then the logging code would not know what the id's were >> when other clients and servers passed them to JSSE. >> >> https://cr.openjdk.java.net/~ascarpino/8245686/webrev/ >> >> Tony From anthony.scarpino at oracle.com Wed Jun 10 04:09:25 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 9 Jun 2020 21:09:25 -0700 Subject: 8245686: Ed25519 and Ed448 present in handshake messages In-Reply-To: <70a3843d-5f62-31d2-a543-dde351e358bc@oracle.com> References: <69f9a4bb-d3b1-83c4-73b2-19d4cb5916b9@oracle.com> <70a3843d-5f62-31d2-a543-dde351e358bc@oracle.com> Message-ID: Thanks for catching that. Tony On 6/9/20 5:23 PM, Bradford Wetmore wrote: > Update the year, but otherwise looks good. > > Brad > > > On 6/9/2020 4:04 PM, Xuelei Fan wrote: >> A simple fix like this looks good to me.? I may check this first, >> before the EC available and signature checking. >> >> Xuelei >> >> On 6/9/2020 3:12 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I need a code review of this very simple change for a situation that >>> I'm not sure is a problem in the real world. >>> >>> The original TLS 1.3 putback added EdDSA to the TLS signature >>> extensions enumeration before there was an EdDSA JCE implementation >>> or JSSE support.? Without an implementation, a signature checks would >>> not include EdDSA for TLS extensions, signature_algorithms and >>> signature_algorithm_cert.? Now with JCE EdDSA support, the signature >>> check adds EdDSA to the extension, despite JSSE not having support >>> yet (JDK-8166596).? This causes a signature scheme authentication >>> failure, and JSSE moves onto the next certificate provided. >>> >>> The only time this is a problem is if EdDSA is the only cert >>> provided. I'm not sure how realistic it is for one certificate to be >>> provided. If someone knows multiple certificates are always >>> available, I'm happy to not make this change. >>> >>> The fix is a simple check in the constructor to set the curves >>> unavailable after the signature check.? This code can be deleted when >>> JDK-8166596 is fixed in jdk16.? I had thought about commenting out >>> the enums, but then the logging code would not know what the id's >>> were when other clients and servers passed them to JSSE. >>> >>> https://cr.openjdk.java.net/~ascarpino/8245686/webrev/ >>> >>> Tony From alexey at azul.com Wed Jun 10 09:03:53 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 10 Jun 2020 09:03:53 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <192f1214-fe26-32b5-0243-8d6b90803181@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <9dc3aa80-cce1-e1c2-d50b-d7cfe570c652@oracle.com> <9B6A7339-F729-41EB-8245-CB6EA03A8D31@azul.com> <21ab9cf7-2d48-f5de-3586-78b40c1d0c12@oracle.com> <192f1214-fe26-32b5-0243-8d6b90803181@oracle.com> Message-ID: Hello Sean, The link to CSR for this feature : https://bugs.openjdk.java.net/browse/JDK-8247311 Regards Alexey > On 9 Jun 2020, at 19:50, Sean Mullan wrote: > > On 6/9/20 12:40 PM, Xuelei Fan wrote: >> About the prefix, it may follow RFC 5056 (See page 7, section 2.1). >> o Specifications of channel bindings for any secure channels MUST >> provide for a single, canonical octet string encoding of the >> channel bindings. Under this framework, channel bindings MUST >> start with the channel binding unique prefix followed by a colon >> (ASCII 0x3A). > > Thanks! Easy to miss. > > I would recommend adding more comments in the code (ex, in TLSChannelBinding) pointing to that RFC section, and other RFCs such 5929 for the tls cbtypes. Also, this RFC (and other specifications such as RFC 5959) should be listed in the CSR so that we document precisely what encodings and types the JDK implementation supports and is using. > > --Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From hai-may.chao at oracle.com Wed Jun 10 09:31:53 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Wed, 10 Jun 2020 02:31:53 -0700 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <8C294257-35F0-420A-BC93-A75C017A5C6B@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> <77CE09E4-0A4F-41D1-A950-9CAF71F2317B@oracle.com> <8C294257-35F0-420A-BC93-A75C017A5C6B@oracle.com> Message-ID: > On Jun 9, 2020, at 5:58 PM, Weijun Wang wrote: > > Good to see both -keystore and -trustcacerts mentioned. Some comments: > > 1. I think there is no need to say "from -file cert_file". Or, do you mean the new function does not apply to those from -sslserver and -jarfile? If so, that might be a problem. You?re right. Removed it. > > 2. While you said "attempts to construct a chain of trust", do you also want to describe what happens if it succeeds or fails? Updated manpage. > > 3. It will be nice if you can include the exact diff of the man page files either inside the CSR itself or as a comment. > Included the diff of the manpage in the CSR. Thanks, Hai-May > Thanks, > Max > >> On Jun 9, 2020, at 10:51 PM, Hai-May Chao wrote: >> >> >> >>> On Jun 7, 2020, at 6:08 PM, Weijun Wang wrote: >>> >>> Looks fine to me. >>> >>> For CSR, since there is already a "Note" there for these 2 options, you can add a few words about what -keystore and -trustcacerts can do. >> >> Updated CSR as suggested. >> >> Thanks, >> Hai-May >> >> >>> >>> Thanks, >>> Max >>> >>>> On Jun 8, 2020, at 4:01 AM, Hai-May Chao wrote: >>>> >>>> Updated webrev - >>>> >>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ >>>> >>>> Thanks, >>>> Hai-May >>>> >>>> >>>>> On Jun 5, 2020, at 11:04 PM, Weijun Wang wrote: >>>>> >>>>> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. >>>>> >>>>> Same for line 80 and line 96 of TrustedCRL.java. >>>>> >>>>> Everything else is fine. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: >>>>>> >>>>>> Updated webrev - >>>>>> >>>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>>>>> >>>>>> Added one command line -importcert in TrustCert.java. >>>>>> Added createCacerts() in test/lib SecurityTools.java. >>>>>> >>>>>> Thanks, >>>>>> Hai-May >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>>>>>> >>>>>>>> Hi Max, >>>>>>>> >>>>>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> The source change looks fine to me. >>>>>>>>> >>>>>>>>> In TrustedCert.java: >>>>>>>>> >>>>>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>>>>>> >>>>>>>> This cat() is taken from WealAlg.java. >>>>>>>> >>>>>>>>> >>>>>>>>> - There is no need to recreate root.jks and root.pem. >>>>>>>> >>>>>>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>>>>>> >>>>>>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>>>>>> >>>>>>>> >>>>>>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>>>>>> >>>>>>>>> >>>>>>>>> - Why not use -trustcacerts below? >>>>>>>>> >>>>>>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>>>>>> >>>>>>>> >>>>>>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>>>>>> >>>>>>> OK. >>>>>>> >>>>>>> Then how about we add a new command before line 155? >>>>>>> >>>>>>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>>>>> >>>>>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>>>>>> >>>>>>>> Ok, will change it. >>>>>>>> >>>>>>>>> >>>>>>>>> In TrustedCRL.java: >>>>>>>>> >>>>>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>>>>>> >>>>>>>> Same reply as above. >>>>>>> >>>>>>> Same question as above. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>>>>>> >>>>>>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>>>>>> >>>>>>>>> >>>>>>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>>>>>> >>>>>>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>>>>>> >>>>>>> I meant creating the cacerts in one method, something like >>>>>>> >>>>>>> void createCacerts(String ks, String... crt); >>>>>>> >>>>>>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>>>>>> >>>>>>> BTW, what does caks.size() == 0 matter here? >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hai-May >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I?d like to request a review for: >>>>>>>>>> >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>>>>> >>>>>>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Hai-May >>>>>> >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Wed Jun 10 14:29:36 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 10 Jun 2020 15:29:36 +0100 Subject: Thread leak by LdapLoginModule In-Reply-To: <5e5f3f91-bdc2-7af2-7b41-894484de7f61@oracle.com> References: <889628466.1257399.1591737319316.JavaMail.zimbra@desy.de> <5e5f3f91-bdc2-7af2-7b41-894484de7f61@oracle.com> Message-ID: <3c1da905-0654-1932-0b49-d257bf661d82@oracle.com> On 09/06/2020 23:21, Sean Mullan wrote: >> The issue is not observed with java-14, thus I assume that the fix is >> related to commit >> >> http://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 >> >> As java-11 is LTS, what is the procedure to get it fix back-ported? Hi, AFAICS the fix has already been backported to JDK 11.0.8. best regards, -- daniel From tigran.mkrtchyan at desy.de Wed Jun 10 14:45:08 2020 From: tigran.mkrtchyan at desy.de (Mkrtchyan, Tigran) Date: Wed, 10 Jun 2020 16:45:08 +0200 (CEST) Subject: Thread leak by LdapLoginModule In-Reply-To: <3c1da905-0654-1932-0b49-d257bf661d82@oracle.com> References: <889628466.1257399.1591737319316.JavaMail.zimbra@desy.de> <5e5f3f91-bdc2-7af2-7b41-894484de7f61@oracle.com> <3c1da905-0654-1932-0b49-d257bf661d82@oracle.com> Message-ID: <717334161.1433632.1591800308211.JavaMail.zimbra@desy.de> Hi, found it: https://bugs.openjdk.java.net/browse/JDK-8237876 Thanks, Tigran. ----- Original Message ----- > From: "Daniel Fuchs" > To: "Sean Mullan" , "Tigran Mkrtchyan" , "security-dev" > > Cc: "core-libs-dev" > Sent: Wednesday, June 10, 2020 4:29:36 PM > Subject: Re: Thread leak by LdapLoginModule > On 09/06/2020 23:21, Sean Mullan wrote: >>> The issue is not observed with java-14, thus I assume that the fix is >>> related to commit >>> >>> http://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 >>> >>> As java-11 is LTS, what is the procedure to get it fix back-ported? > > Hi, > > AFAICS the fix has already been backported to JDK 11.0.8. > > best regards, > > -- daniel From xuelei.fan at oracle.com Wed Jun 10 16:43:20 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Jun 2020 09:43:20 -0700 Subject: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test In-Reply-To: <26ba099b-c324-4492-abfc-ad454041382a@default> References: <26ba099b-c324-4492-abfc-ad454041382a@default> Message-ID: <3d987471-bcf7-0062-a25f-465ca4953352@oracle.com> It may be not needed to update the handleException() method. - 440 handleException(iioe); + 440 if (resumable) { + throw iioe; + } else { + handleException(iioe); + } Otherwise, looks good to me. Xuelei On 6/4/2020 8:13 AM, Prasadrao Koppula wrote: > Hi, > > Could you please review this patch. For timeout/interrupts, JDK11u+ > releases, SSLSocket:getSession behavior is different, compare to JDK8u. > i.e, connection is in open state for timeout/interrupts exception. For > comparability reasons, this fix will close connection for getSession > timeout/ interrupts. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246031 > > Webrev: http://cr.openjdk.java.net/~pkoppula/8246031/webrev.00/ > > Thanks, > > Prasad.K > From valerie.peng at oracle.com Wed Jun 10 19:45:48 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 10 Jun 2020 12:45:48 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> Message-ID: <7a49f7de-5165-43c1-d62b-7f9389f8a9d9@oracle.com> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8246077/webrev.01/ Key changes in this revision are in the Delegate.of() method in java.security.MessageDigest class. Comments? Thanks, Valerie On 6/8/2020 1:42 PM, Valerie Peng wrote: > "md instanceof Cloneable && md is not from PKCS11" is not entirely > precise. What I mean is that for MessageDigestSpi impls from PKCS11 > provider, we will need to call the clone() to know for sure whether > cloning is supported. If we decide to employ these extra logic for > saving clone() call, it's better to do it inside the > MessageDigest.of(...) so the callers don't have to repeat the same > logic. Comments? > > Valerie > > On 6/8/2020 1:34 PM, Valerie Peng wrote: >> Hmm, I checked all MessageDigestSpi impls of JDK providers... The >> story is more complicated than we expect. >> >> For SUN provider which implement the digest spi, implementing >> Cloneable means it supports clone functionality. >> >> However, for SunPKCS11 provider which wraps native PKCS11 library, it >> always implements Cloneable interface, but when clone() is called, it >> will then perform the equivalent PKCS11 calls and throw CNSE if any >> PKCS11 error is observed. >> >> So, there is a possibility that the instanceof check and the clone() >> check leads to different result in this particular scenario. >> >> The chance of 3rd non-PKCS11 party provider whose >> MessageDigest/MessageDigestSpi impl implements Cloneable but throws >> CNSE when clone() is called should be very low? So, I think it should >> be sufficient to use "md instanceof Cloneable && md is not from PKCS11"? >> >> Valerie >> >> On 6/6/2020 9:10 AM, Xuelei Fan wrote: >>> As the the Delegate class takes care of the Cloneable SPI >>> implementation, it should be sufficient to use "md instanceof >>> Cloneable" only.? It is not a expected behavior that a provider >>> implements Cloneable but does not really support it. >>> >>> Xuelei >>> >>> On 6/5/2020 10:54 PM, Weijun Wang wrote: >>>> Is it possible to try "md instanceof Cloneable || md.clone() >>>> returns"? Hopefully this is fast enough in most cases and also has >>>> the chance to recognize more actually-cloneable ones. >>>> >>>> I'm also OK with simply using "md instanceof Cloneable". >>>> >>>> --Max >>>> >>>>> On Jun 6, 2020, at 12:02 PM, Valerie Peng >>>>> wrote: >>>>> >>>>> >>>>> I am merely following the spec's recommendation of trying the >>>>> clone() for cloneability check. >>>>> >>>>> If you both are ok with it and prefer the instanceof check, I can >>>>> sure reverting back the changes in HmacCore and HandshakeHash >>>>> classes. >>>>> >>>>> Valerie >>>>> >>>>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>>>> I share the same concern. clone() is a heavy weight operation in >>>>>> constructors that can be called alot during intensive crypto >>>>>> operations. >>>>>> >>>>>> Now that you've done work on Delegate class - why not also keep >>>>>> the (instanceof Cloneable) test ? That can serve as your fastpath >>>>>> for the default JDK configuration AFAIK. >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>>>> >>>>>>>> ? 2020?6?5??03:19?Valerie Peng >>>>>>>> ??? >>>>>>>> >>>>>>>>> Can you give an example when these 2 rules have different >>>>>>>>> results? Is this only true for those implementation that >>>>>>>>> directly subclass MessageDigest? >>>>>>>> Before this fix, even the Spi impl implements Cloneable the >>>>>>>> instanceof check will always fail because the wrapper class, >>>>>>>> i.e. MessageDigest.Delegate does not. However, if you call the >>>>>>>> clone() (made public by the MessageDigest class), it will >>>>>>>> succeed because Delegate.clone() checks to see if the spi >>>>>>>> object implements the Cloneable interface, if yes, it will >>>>>>>> proceed to call the spi clone(). So, for this scenario, the >>>>>>>> results are different, e.g. instanceof returns false, but >>>>>>>> clone() succeeds. This is just one example. Is this what you >>>>>>>> are asking? >>>>>>> No. >>>>>>> >>>>>>> I understand this case, but this has already been fixed. Is >>>>>>> there any other example? Or are you only follow the words in the >>>>>>> spec? i.e. try clone() to see if it?s cloneable. >>>>>>> >>>>>>> I am worried that try clone() is much heavier than just check >>>>>>> instanof Cloneable. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>> From valerie.peng at oracle.com Wed Jun 10 20:13:32 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 10 Jun 2020 13:13:32 -0700 Subject: NullPointer in JceSecurity.getVerificationResult - Affects JDK 11.07, and JDK 12 and later. In-Reply-To: <651b2416-4764-d460-e3f9-56ef073a5c35@oracle.com> References: <651b2416-4764-d460-e3f9-56ef073a5c35@oracle.com> Message-ID: <83d5548d-9760-4c7a-c9f6-89519849dd74@oracle.com> Hi John, As you may have noticed, we are progressing a fix for https://bugs.openjdk.java.net/browse/JDK-8246613 for returning the same default SecureRandom algo for 3rd party providers as in pre-JDK7092821 releases. Thus, the chance of observing JDK-8246613 should be lowered significantly. Given this, I plan to lower the priority of JDK-8246383 and it may not be fixed in JDK 15 as earlier communicated. If this will be an issue, please let me know. Thanks, Valerie On 6/2/2020 4:37 PM, Valerie Peng wrote: > > Thanks for reporting the bug and the detailed analysis. > > I have filed https://bugs.openjdk.java.net/browse/JDK-8246383 to keep > track of this. Will aim to fix this for 15 and have it backported > accordingly. > > Is it possible to get hold of an test provider to reproduce and > verifying the fix? > > Regards, > > Valerie > On 6/2/2020 1:18 PM, John Gray wrote: >> >> Hello, >> >> At Entrust Datacard, we produce a Java based toolkit that contains >> our own Security Provider. This toolkit and provider ?has been around >> for about 19 years. >> >> In JDK version 11.07 (and I also think Java 12 and beyond), our >> toolkit reports the following error: >> >> java.lang.RuntimeException: java.security.NoSuchAlgorithmException: >> Error constructing implementation (algorithm: X9_31usingAES256, >> provider: Entrust, class: >> com.entrust.toolkit.security.crypto.random.X9_31usingAES256) >> at >> java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:281) >> at java.base/java.security.SecureRandom.(SecureRandom.java:219) >> at java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) >> ... 41 more >> Caused by: java.security.NoSuchAlgorithmException: Error constructing >> implementation (algorithm: X9_31usingAES256, provider: Entrust, >> class: com.entrust.toolkit.security.crypto.random.X9_31usingAES256) >> at >> java.base/java.security.Provider$Service.newInstance(Provider.java:1825) >> at >> java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236) >> at >> java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164) >> at >> java.base/java.security.SecureRandom.getInstance(SecureRandom.java:365) >> at >> java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:273) >> ... 43 more >> Caused by: java.lang.NullPointerException >> at >> java.base/javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:203) >> at java.base/javax.crypto.Cipher.getInstance(Cipher.java:690) >> at java.base/javax.crypto.Cipher.getInstance(Cipher.java:625) >> at >> com.entrust.toolkit.security.crypto.random.X9_31usingAES256.initialize(X9_31usingAES256.java:524) >> at >> com.entrust.toolkit.security.crypto.random.X9_31usingAES256.(X9_31usingAES256.java:102) >> at >> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> at >> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) >> at java.base/java.security.Provider.newInstanceUtil(Provider.java:176) >> at >> java.base/java.security.Provider$Service.newInstance(Provider.java:1818) >> >> I investigated this error, and found it was made possible because of >> the following change in Java 11.07 which unmasked a bug in the JVM >> that has probably been around for years. >> >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8228613 >> >> It is a problem inside the JceSecurity class.? When the class is >> being loaded, the call to setup a default SecureRandom() instance is >> invoked.?? ?That seems to invoke the JVM to find the first available >> SecureRandom() instance.? ??This error happens when our Entrust >> provider is in first position.?? In previous versions of the JDK it >> honoured the order of algorithms specified in the providers.?? In our >> Entrust Security provider, we have a number of SecureRandom >> implementations.?? Now because of the above change, it picks a >> different SecureRandom instance (the X9_31usingAES256).?? That should >> be fine, however the problem is that the SecureRandom() setup calls >> Cipher.getInstance() and as you can see below, that calls >> JceSecurity.getVerificationResult() which is static, and uses the >> verificationResuts Map that has not yet been initialized (becasuse >> it?s declaration is after the SecureRandom setup).??? That is why >> there is a NullPointerException. >> >> *public**static**final*Cipher getInstance(String transformation, >> >> Provider provider) >> >> *throws*NoSuchAlgorithmException, NoSuchPaddingException >> >> ??? { >> >> *if*((transformation == *null*) || transformation.equals("")) { >> >> *throw**new*NoSuchAlgorithmException("Null or empty transformation"); >> >> ??????? } >> >> *if*(provider == *null*) { >> >> *throw**new*IllegalArgumentException("Missing provider"); >> >> ??????? } >> >> ??????? Exception failure = *null*; >> >> ??????? List transforms = getTransforms(transformation); >> >> *boolean*providerChecked = *false*; >> >> ??????? String paddingError = *null*; >> >> *for*(Transform tr : transforms) { >> >> ??????????? Service s = provider.getService("Cipher", tr.transform); >> >> *if*(s == *null*) { >> >> *continue*; >> >> ??????????? } >> >> *if*(providerChecked == *false*) { >> >> // for compatibility, first do the lookup and then verify >> >> // the provider. this makes the difference between a NSAE >> >> // and a SecurityException if the >> >> // provider does not support the algorithm. >> >> Exception ve = JceSecurity.getVerificationResult(provider); >> >> *if*(ve != *null*) { >> >> ??????????????????? String msg = "JCE cannot authenticate the provider " >> >> ??????????????????????? + provider.getName(); >> >> *throw**new*SecurityException(msg, ve); >> >> ??????????????? } >> >> ??????????????? providerChecked = *true*; >> >> ??????????? } >> >> The JceSecurity.getVerificationResult(provider) method is used when >> initializing the SecureRandom (first highlighted line below) when the >> classLoader is loading the JceSecurity class itself. >> >> From the JceSecurity class: >> >> *static**final*SecureRandom RANDOM = *new*SecureRandom(); >> >> // The defaultPolicy and exemptPolicy will be set up >> >> // in the static initializer. >> >> *private**static*CryptoPermissions defaultPolicy = *null*; >> >> *private**static*CryptoPermissions exemptPolicy = *null*; >> >> // Map of the providers we already have verified >> >> // value == PROVIDER_VERIFIED is successfully verified >> >> // value is failure cause Exception in error case >> >> *private**static**final*Map verificationResults = >> >> *new*IdentityHashMap<>(); >> >> It fails when it calls the following code in JceSecurity.java because >> the verificationResults Map has not been >> initialized because the SecureRandom() constructor ends up calling >> the JceSecurity.getVerificationResult() static method that makes use >> of the Map!? That explains the NullPointerException. >> >> The fix to the issue should be simple, just move the initialization >> of the verificationResults Map BEFORE the SecureRandom initialization >> in JceSecurity.java >> >> Because verificationResults is not initialized, the line highlighted >> below fails (Because the Map has not been initialized). >> >> /* >> >> ???? * Verify that the provider JAR files are signed properly, which >> >> ???? * means the signer's certificate can be traced back to a >> >> ???? * JCE trusted CA. >> >> ???? * Return null if ok, failure Exception if verification failed. >> >> ???? */ >> >> *static**synchronized*Exception getVerificationResult(Provider p) { >> >> Object o = verificationResults.get(p); >> >> *if*(o == PROVIDER_VERIFIED) { >> >> *return**null*; >> >> ??????? } *else**if*(o != *null*) { >> >> *return*(Exception)o; >> >> ??????? } >> >> *if*(verifyingProviders.get(p) != *null*) { >> >> // this method is static synchronized, must be recursion >> >> // return failure now but do not save the result >> >> *return**new*NoSuchProviderException("Recursion during verification"); >> >> ????? ??} >> >> *try*{ >> >> verifyingProviders.put(p, Boolean.FALSE); >> >> ??????????? URL providerURL = getCodeBase(p.getClass()); >> >> verifyProvider(providerURL, p); >> >> // Verified ok, cache result >> >> verificationResults.put(p, PROVIDER_VERIFIED); >> >> *return**null*; >> >> ??????? } *catch*(Exception e) { >> >> verificationResults.put(p, e); >> >> *return*e; >> >> ??????? } *finally*{ >> >> verifyingProviders.remove(p); >> >> ??????? } >> >> ??? } >> >> Cheers, >> >> John Gray >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Gray at entrustdatacard.com Wed Jun 10 20:31:27 2020 From: John.Gray at entrustdatacard.com (John Gray) Date: Wed, 10 Jun 2020 20:31:27 +0000 Subject: [EXTERNAL]Re: NullPointer in JceSecurity.getVerificationResult - Affects JDK 11.07, and JDK 12 and later. In-Reply-To: <83d5548d-9760-4c7a-c9f6-89519849dd74@oracle.com> References: <651b2416-4764-d460-e3f9-56ef073a5c35@oracle.com> <83d5548d-9760-4c7a-c9f6-89519849dd74@oracle.com> Message-ID: Thanks Valerie! If I understand you correctly, I think you are saying the fix for https://bugs.openjdk.java.net/browse/JDK-8246613 will mean the first SecureRandom in the provider will be used as the default (which will make it equivalent to JDK 11.06 and previous versions). If that is the case, I agree it should mitigate the issue and would be ok with lowering the priority of 8246383. Will this new fix be back-ported into 11 LTS versions as well? Thanks so much for your amazing fast response. I have been trying to set aside some time to put together a simple sample you can use to verify 8246383 (that doesn't require our full toolkit), but haven't been able to find the time to do that yet. Cheers, John Gray From: Valerie Peng [mailto:valerie.peng at oracle.com] Sent: Wednesday, June 10, 2020 4:14 PM To: John Gray ; security-dev at openjdk.java.net Cc: Muthu Kannappan ; Raj Arora Subject: [EXTERNAL]Re: NullPointer in JceSecurity.getVerificationResult - Affects JDK 11.07, and JDK 12 and later. WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ Hi John, As you may have noticed, we are progressing a fix for https://bugs.openjdk.java.net/browse/JDK-8246613 for returning the same default SecureRandom algo for 3rd party providers as in pre-JDK7092821 releases. Thus, the chance of observing JDK-8246613 should be lowered significantly. Given this, I plan to lower the priority of JDK-8246383 and it may not be fixed in JDK 15 as earlier communicated. If this will be an issue, please let me know. Thanks, Valerie On 6/2/2020 4:37 PM, Valerie Peng wrote: Thanks for reporting the bug and the detailed analysis. I have filed https://bugs.openjdk.java.net/browse/JDK-8246383 to keep track of this. Will aim to fix this for 15 and have it backported accordingly. Is it possible to get hold of an test provider to reproduce and verifying the fix? Regards, Valerie On 6/2/2020 1:18 PM, John Gray wrote: Hello, At Entrust Datacard, we produce a Java based toolkit that contains our own Security Provider. This toolkit and provider has been around for about 19 years. In JDK version 11.07 (and I also think Java 12 and beyond), our toolkit reports the following error: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: X9_31usingAES256, provider: Entrust, class: com.entrust.toolkit.security.crypto.random.X9_31usingAES256) at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:281) at java.base/java.security.SecureRandom.(SecureRandom.java:219) at java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) ... 41 more Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: X9_31usingAES256, provider: Entrust, class: com.entrust.toolkit.security.crypto.random.X9_31usingAES256) at java.base/java.security.Provider$Service.newInstance(Provider.java:1825) at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236) at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164) at java.base/java.security.SecureRandom.getInstance(SecureRandom.java:365) at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:273) ... 43 more Caused by: java.lang.NullPointerException at java.base/javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:203) at java.base/javax.crypto.Cipher.getInstance(Cipher.java:690) at java.base/javax.crypto.Cipher.getInstance(Cipher.java:625) at com.entrust.toolkit.security.crypto.random.X9_31usingAES256.initialize(X9_31usingAES256.java:524) at com.entrust.toolkit.security.crypto.random.X9_31usingAES256.(X9_31usingAES256.java:102) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.security.Provider.newInstanceUtil(Provider.java:176) at java.base/java.security.Provider$Service.newInstance(Provider.java:1818) I investigated this error, and found it was made possible because of the following change in Java 11.07 which unmasked a bug in the JVM that has probably been around for years. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8228613 It is a problem inside the JceSecurity class. When the class is being loaded, the call to setup a default SecureRandom() instance is invoked. That seems to invoke the JVM to find the first available SecureRandom() instance. This error happens when our Entrust provider is in first position. In previous versions of the JDK it honoured the order of algorithms specified in the providers. In our Entrust Security provider, we have a number of SecureRandom implementations. Now because of the above change, it picks a different SecureRandom instance (the X9_31usingAES256). That should be fine, however the problem is that the SecureRandom() setup calls Cipher.getInstance() and as you can see below, that calls JceSecurity.getVerificationResult() which is static, and uses the verificationResuts Map that has not yet been initialized (becasuse it's declaration is after the SecureRandom setup). That is why there is a NullPointerException. public static final Cipher getInstance(String transformation, Provider provider) throws NoSuchAlgorithmException, NoSuchPaddingException { if ((transformation == null) || transformation.equals("")) { throw new NoSuchAlgorithmException("Null or empty transformation"); } if (provider == null) { throw new IllegalArgumentException("Missing provider"); } Exception failure = null; List transforms = getTransforms(transformation); boolean providerChecked = false; String paddingError = null; for (Transform tr : transforms) { Service s = provider.getService("Cipher", tr.transform); if (s == null) { continue; } if (providerChecked == false) { // for compatibility, first do the lookup and then verify // the provider. this makes the difference between a NSAE // and a SecurityException if the // provider does not support the algorithm. Exception ve = JceSecurity.getVerificationResult(provider); if (ve != null) { String msg = "JCE cannot authenticate the provider " + provider.getName(); throw new SecurityException(msg, ve); } providerChecked = true; } The JceSecurity.getVerificationResult(provider) method is used when initializing the SecureRandom (first highlighted line below) when the classLoader is loading the JceSecurity class itself. >From the JceSecurity class: static final SecureRandom RANDOM = new SecureRandom(); // The defaultPolicy and exemptPolicy will be set up // in the static initializer. private static CryptoPermissions defaultPolicy = null; private static CryptoPermissions exemptPolicy = null; // Map of the providers we already have verified // value == PROVIDER_VERIFIED is successfully verified // value is failure cause Exception in error case private static final Map verificationResults = new IdentityHashMap<>(); It fails when it calls the following code in JceSecurity.java because the verificationResults Map has not been initialized because the SecureRandom() constructor ends up calling the JceSecurity.getVerificationResult() static method that makes use of the Map! That explains the NullPointerException. The fix to the issue should be simple, just move the initialization of the verificationResults Map BEFORE the SecureRandom initialization in JceSecurity.java Because verificationResults is not initialized, the line highlighted below fails (Because the Map has not been initialized). /* * Verify that the provider JAR files are signed properly, which * means the signer's certificate can be traced back to a * JCE trusted CA. * Return null if ok, failure Exception if verification failed. */ static synchronized Exception getVerificationResult(Provider p) { Object o = verificationResults.get(p); if (o == PROVIDER_VERIFIED) { return null; } else if (o != null) { return (Exception)o; } if (verifyingProviders.get(p) != null) { // this method is static synchronized, must be recursion // return failure now but do not save the result return new NoSuchProviderException("Recursion during verification"); } try { verifyingProviders.put(p, Boolean.FALSE); URL providerURL = getCodeBase(p.getClass()); verifyProvider(providerURL, p); // Verified ok, cache result verificationResults.put(p, PROVIDER_VERIFIED); return null; } catch (Exception e) { verificationResults.put(p, e); return e; } finally { verifyingProviders.remove(p); } } Cheers, John Gray -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Jun 10 23:12:16 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 10 Jun 2020 16:12:16 -0700 Subject: JDK 16 RFR of JDK-8247374: Remove default constructors from javax.net.ssl Message-ID: <4f21f199-6935-a794-e3af-498a00315baa@oracle.com> Hello, Please review the addition of several explicit constructors to abstract classes in javax.net.ssl to remove the use of implicit default constructors; CSR link and patch below: ??? JDK-8247374: Remove default constructors from javax.net.ssl ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8247375 ??? webrev: http://cr.openjdk.java.net/~darcy/8247374.0/ Thanks, -Joe diff -r d9daa4ce8017 src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java --- a/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java Wed Jun 10 13:29:44 2020 -0700 +++ b/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java Wed Jun 10 16:09:50 2020 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2010, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2010, 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 @@ -35,6 +35,11 @@ ? */ ?public abstract class ExtendedSSLSession implements SSLSession { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public ExtendedSSLSession() {} + +??? /** ????? * Obtains an array of supported signature algorithms that the local side ????? * is willing to use. ????? *

diff -r d9daa4ce8017 src/java.base/share/classes/javax/net/ssl/KeyManagerFactorySpi.java --- a/src/java.base/share/classes/javax/net/ssl/KeyManagerFactorySpi.java Wed Jun 10 13:29:44 2020 -0700 +++ b/src/java.base/share/classes/javax/net/ssl/KeyManagerFactorySpi.java Wed Jun 10 16:09:50 2020 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 1999, 2001, 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 @@ -41,6 +41,11 @@ ? */ ?public abstract class KeyManagerFactorySpi { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public KeyManagerFactorySpi() {} + +??? /** ????? * Initializes this factory with a source of key material. ????? * ????? * @param ks the key store or null diff -r d9daa4ce8017 src/java.base/share/classes/javax/net/ssl/SSLContextSpi.java --- a/src/java.base/share/classes/javax/net/ssl/SSLContextSpi.java Wed Jun 10 13:29:44 2020 -0700 +++ b/src/java.base/share/classes/javax/net/ssl/SSLContextSpi.java Wed Jun 10 16:09:50 2020 -0700 @@ -40,6 +40,11 @@ ? */ ?public abstract class SSLContextSpi { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public SSLContextSpi() {} + +??? /** ????? * Initializes this context. ????? * ????? * @param km the sources of authentication keys diff -r d9daa4ce8017 src/java.base/share/classes/javax/net/ssl/TrustManagerFactorySpi.java --- a/src/java.base/share/classes/javax/net/ssl/TrustManagerFactorySpi.java Wed Jun 10 13:29:44 2020 -0700 +++ b/src/java.base/share/classes/javax/net/ssl/TrustManagerFactorySpi.java Wed Jun 10 16:09:50 2020 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 1999, 2008, 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 @@ -41,6 +41,11 @@ ? */ ?public abstract class TrustManagerFactorySpi { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public TrustManagerFactorySpi() {} + +??? /** ????? * Initializes this factory with a source of certificate ????? * authorities and related trust material. ????? * diff -r d9daa4ce8017 src/java.base/share/classes/javax/net/ssl/X509ExtendedTrustManager.java --- a/src/java.base/share/classes/javax/net/ssl/X509ExtendedTrustManager.java Wed Jun 10 13:29:44 2020 -0700 +++ b/src/java.base/share/classes/javax/net/ssl/X509ExtendedTrustManager.java Wed Jun 10 16:09:50 2020 -0700 @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2010, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2010, 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 @@ -55,6 +55,11 @@ ? */ ?public abstract class X509ExtendedTrustManager implements X509TrustManager { ???? /** +???? * Constructor for subclasses to call. +???? */ +??? public X509ExtendedTrustManager() {} + +??? /** ????? * Given the partial or complete certificate chain provided by the ????? * peer, build and validate the certificate path based on the ????? * authentication type and ssl parameters. From xuelei.fan at oracle.com Thu Jun 11 00:09:56 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 10 Jun 2020 17:09:56 -0700 Subject: JDK 16 RFR of JDK-8247374: Remove default constructors from javax.net.ssl In-Reply-To: <4f21f199-6935-a794-e3af-498a00315baa@oracle.com> References: <4f21f199-6935-a794-e3af-498a00315baa@oracle.com> Message-ID: Thank you for taking care of the issue. The update looks good to me. I added myself as the reviewer in the CSR. Xuelei On 6/10/2020 4:12 PM, Joe Darcy wrote: > Hello, > > Please review the addition of several explicit constructors to abstract > classes in javax.net.ssl to remove the use of implicit default > constructors; CSR link and patch below: > > ??? JDK-8247374: Remove default constructors from javax.net.ssl > ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8247375 > ??? webrev: http://cr.openjdk.java.net/~darcy/8247374.0/ > > Thanks, > > -Joe > > diff -r d9daa4ce8017 > src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java > --- a/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java > Wed Jun 10 13:29:44 2020 -0700 > +++ b/src/java.base/share/classes/javax/net/ssl/ExtendedSSLSession.java > Wed Jun 10 16:09:50 2020 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2010, 2017, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2010, 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 > @@ -35,6 +35,11 @@ > ? */ > ?public abstract class ExtendedSSLSession implements SSLSession { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public ExtendedSSLSession() {} > + > +??? /** > ????? * Obtains an array of supported signature algorithms that the > local side > ????? * is willing to use. > ????? *

> diff -r d9daa4ce8017 > src/java.base/share/classes/javax/net/ssl/KeyManagerFactorySpi.java > --- > a/src/java.base/share/classes/javax/net/ssl/KeyManagerFactorySpi.java > Wed Jun 10 13:29:44 2020 -0700 > +++ > b/src/java.base/share/classes/javax/net/ssl/KeyManagerFactorySpi.java > Wed Jun 10 16:09:50 2020 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 1999, 2001, 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 > @@ -41,6 +41,11 @@ > ? */ > ?public abstract class KeyManagerFactorySpi { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public KeyManagerFactorySpi() {} > + > +??? /** > ????? * Initializes this factory with a source of key material. > ????? * > ????? * @param ks the key store or null > diff -r d9daa4ce8017 > src/java.base/share/classes/javax/net/ssl/SSLContextSpi.java > --- a/src/java.base/share/classes/javax/net/ssl/SSLContextSpi.java Wed > Jun 10 13:29:44 2020 -0700 > +++ b/src/java.base/share/classes/javax/net/ssl/SSLContextSpi.java Wed > Jun 10 16:09:50 2020 -0700 > @@ -40,6 +40,11 @@ > ? */ > ?public abstract class SSLContextSpi { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public SSLContextSpi() {} > + > +??? /** > ????? * Initializes this context. > ????? * > ????? * @param km the sources of authentication keys > diff -r d9daa4ce8017 > src/java.base/share/classes/javax/net/ssl/TrustManagerFactorySpi.java > --- > a/src/java.base/share/classes/javax/net/ssl/TrustManagerFactorySpi.java > Wed Jun 10 13:29:44 2020 -0700 > +++ > b/src/java.base/share/classes/javax/net/ssl/TrustManagerFactorySpi.java > Wed Jun 10 16:09:50 2020 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 1999, 2008, 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 > @@ -41,6 +41,11 @@ > ? */ > ?public abstract class TrustManagerFactorySpi { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public TrustManagerFactorySpi() {} > + > +??? /** > ????? * Initializes this factory with a source of certificate > ????? * authorities and related trust material. > ????? * > diff -r d9daa4ce8017 > src/java.base/share/classes/javax/net/ssl/X509ExtendedTrustManager.java > --- > a/src/java.base/share/classes/javax/net/ssl/X509ExtendedTrustManager.java Wed > Jun 10 13:29:44 2020 -0700 > +++ > b/src/java.base/share/classes/javax/net/ssl/X509ExtendedTrustManager.java Wed > Jun 10 16:09:50 2020 -0700 > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2010, 2015, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2010, 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 > @@ -55,6 +55,11 @@ > ? */ > ?public abstract class X509ExtendedTrustManager implements > X509TrustManager { > ???? /** > +???? * Constructor for subclasses to call. > +???? */ > +??? public X509ExtendedTrustManager() {} > + > +??? /** > ????? * Given the partial or complete certificate chain provided by the > ????? * peer, build and validate the certificate path based on the > ????? * authentication type and ssl parameters. > From valerie.peng at oracle.com Thu Jun 11 00:16:51 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 10 Jun 2020 17:16:51 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <0f0fecf1-a995-4e7c-a68f-841c70d01638@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> <386f23a8-023d-200a-04ee-545677f95614@oracle.com> <8BAA3715-11BC-4A39-8C96-FD04CFE1BC84@oracle.com> <2552dfed-922d-5db1-6266-d82abb11a9f9@oracle.com> <0f0fecf1-a995-4e7c-a68f-841c70d01638@oracle.com> Message-ID: <4f5595a1-8949-89b2-8cbf-dd5822ff29cc@oracle.com> Updated webrev after incorporating Sean's feedbacks: http://cr.openjdk.java.net/~valeriep/8246613/webrev.03/ Main changes are code refactoring in SecureRandom class and changed Provider class to store SecureRandom services in their order of registration instead of only the algorithm name. Thanks, Valerie On 6/9/2020 4:53 PM, Valerie Peng wrote: > Hi, Sean, > > On 6/9/2020 12:21 PM, Sean Mullan wrote: >> Looks good, just a couple of minor comments on the test: >> >> * test/jdk/java/security/SecureRandom/DefaultAlgo.java >> >> 75???????? Objects.requireNonNull(p); >> >> Not sure why you need this line, since the test never passes null. > > True, the test never passes null, this line is just to make it clear > that the provider argument should not be null as the test is not > prepared to handle null provider. It's not essential, so I removed it > per your comment. > >> >> 90???????????????? validate(new SecureRandom(), pName, algos[0]); >> >> Is there a reason why you don't call removeService for each algorithm >> when testing the non-legacy provider? > > The Provider.removeService(...) call is protected. So, it's not a > public API for users of Provider objects. > > Thanks, > Valerie >> >> --Sean >> >> On 6/9/20 12:52 PM, Valerie Peng wrote: >>> Thanks for review~ >>> >>> As for the isProviderInfo() name, since I reverted the code for its >>> impl to pre-7092821, I changed it back to the old name as you >>> noticed. Sean mentioned that he also wants to take a look at this >>> updated webrev, so I will wait for him to do that... >>> >>> Valerie >>> >>> On 6/8/2020 6:11 PM, Weijun Wang wrote: >>>> Code change looks fine to me. >>>> >>>> I re-look at every place where legacyStrings and prngAlgorithms are >>>> used and they are all synchronized. Last time I thought some were >>>> not. Sorry. >>>> >>>> Only one comment: I like the isProviderInfo() name better, but I >>>> notice it was the old name pre-7092821. >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> On Jun 9, 2020, at 6:31 AM, Valerie Peng >>>>> wrote: >>>>> >>>>> Webrev updated: >>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.02/ >>>>> >>>>> Besides addressing Max's comments, I also made >>>>> updateSecureRandomEntries(...) method private and removed the >>>>> synchronized keyword as all of its accesses are synchronized. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> On 6/8/2020 2:33 PM, Valerie Peng wrote: >>>>>> Hi Max, >>>>>> >>>>>> Please find comments in line. >>>>>> >>>>>> On 6/8/2020 2:34 AM, Weijun Wang wrote: >>>>>>> Looks like this should work, but still find it complicated. >>>>>>> >>>>>>> 1. Do we need to care about thread safety when managing >>>>>>> legacyStrings? >>>>>> Right, it's more complicated than I like as well. >>>>>> >>>>>> As for thread safety, the legacy relevant data are all >>>>>> synchronized under the current provider object, i.e. this. Is >>>>>> there a particular call path not doing this? This is the same as >>>>>> the pre-7092821 code. >>>>>> >>>>>>> 2. Does implReplaceAll() need to set legacyChanged = true? >>>>>> Correct, the removal is by accident. Thanks for catching this. >>>>>>> 3. How about using prngAlgorithms.iterator().next() below? >>>>>>> >>>>>>> ??? 1416???? return prngAlgorithms.toArray(new String[0])[0]; >>>>>> Sure, changed. >>>>>> >>>>>> Valerie >>>>>> >>>>>>> --Max >>>>>>> >>>>>>> >>>>>>>> On Jun 6, 2020, at 11:54 AM, Valerie Peng >>>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks for reviewing and sharing the feedbacks on webrev.00. >>>>>>>> >>>>>>>> In order to support all existing calls for legacy registration >>>>>>>> for default secure random, I have to revert some of the >>>>>>>> JDK-7092821 changes and re-introduce the 'legacyStrings' >>>>>>>> LinkedHashMap. Updated the regression test with removal test >>>>>>>> for provider using legacy registrations as well. Although >>>>>>>> removal is supported, this is still not bullet proof as things >>>>>>>> may not work as expected if a provider registered their impl in >>>>>>>> both ways, i.e. legacy String pair and Service, and then >>>>>>>> remove/replace some entries later. Please comment if you really >>>>>>>> need this scenario to be supported. Although not explicitly >>>>>>>> documented, I think the intention is to use one or the other, >>>>>>>> never both. >>>>>>>> >>>>>>>> Webrev update: >>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>>>>>>>> Right, I try to keep the impl simple as I am not aware of any >>>>>>>>> property removal usage. >>>>>>>>> >>>>>>>>> Oh-well, if we have to cater to the removal scenario, then >>>>>>>>> we'd have to add a List and keep track of ALL secure random >>>>>>>>> algos instead of only the FIRST one. Alright, I guess it costs >>>>>>>>> for covering all aspect. But one extra benefit of this is that >>>>>>>>> it should be easy to handle the future JDK property such as >>>>>>>>> "jdk.securerandom.disabledAlgorithms" if it were to be added. >>>>>>>>> >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>>>>>>>> I don't know who in this world would want to do that, but >>>>>>>>>> Prasad's concern is technically possible. I tried >>>>>>>>>> 'p.remove("SecureRandom.a")' in the new test, and new >>>>>>>>>> SecureRandom() fails with >>>>>>>>>> "java.security.NoSuchAlgorithmException: a SecureRandom not >>>>>>>>>> available". >>>>>>>>>> >>>>>>>>>> And people can also remove one entry and add it back in order >>>>>>>>>> to move it to the end. One can even add new implementations >>>>>>>>>> this way. >>>>>>>>>> >>>>>>>>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>>>>>>>> >>>>>>>>>> --Max >>>>>>>>>> >>>>>>>>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Looks good to me, one question >>>>>>>>>>> >>>>>>>>>>> If first registered SecureRandom algo gets removed, >>>>>>>>>>> getDefaultSecureRandomAlgorithm return stale data, a refresh >>>>>>>>>>> required in remove? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Prasad.K >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Valerie Peng >>>>>>>>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>>>>>>>> To: security-dev at openjdk.java.net >>>>>>>>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default >>>>>>>>>>>> SecureRandom algo >>>>>>>>>>>> based on registration ordering >>>>>>>>>>>> >>>>>>>>>>>> Hi, Sean, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for the review and feedback. Webrev updated: >>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> getTypeAndAlgorithm(...) was not static due to an instance >>>>>>>>>>>> variable used by >>>>>>>>>>>> debugging output. I have removed it and made both method >>>>>>>>>>>> static. >>>>>>>>>>>> >>>>>>>>>>>> I will wait for others' review comments also. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Valerie >>>>>>>>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>>>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could someone help reviewing this fix? This change keep >>>>>>>>>>>>>> tracks of the >>>>>>>>>>>>>> first registered SecureRandom algorithm and returns it >>>>>>>>>>>>>> upon the >>>>>>>>>>>>>> request of SecureRandom class. >>>>>>>>>>>>> This looks good to me. I would recommend that Max or >>>>>>>>>>>>> someone else >>>>>>>>>>>>> review it as well. >>>>>>>>>>>>> >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>>>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>>>>>>>> >>>>>>>>>>>>> * SecureRandom.java >>>>>>>>>>>>> >>>>>>>>>>>>> 879???????????? // For SUN provider, we use >>>>>>>>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>>>>>>>> >>>>>>>>>>>>> Might as well fix the typo while you are in there: >>>>>>>>>>>>> s/DEFF/DEF/ >>>>>>>>>>>>> >>>>>>>>>>>>> * Provider.java >>>>>>>>>>>>> >>>>>>>>>>>>> 1156???? private String parseSecureRandomPut(String name, >>>>>>>>>>>>> String >>>>>>>>>>>>> value) { >>>>>>>>>>>>> >>>>>>>>>>>>> Could be static if you also make getTypeAndAlgorithm >>>>>>>>>>>>> static, I think. >>>>>>>>>>>>> >>>>>>>>>>>>> --Sean From sha.jiang at oracle.com Thu Jun 11 01:39:46 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 11 Jun 2020 09:39:46 +0800 Subject: RFR 8245520: Provide a way to add CA certificate to cacerts during test run Message-ID: <124fa783-00d3-f140-07c6-40aac08c466d@oracle.com> Hi, This patch contains a patched version for class sun.security.util.AnchorCertificates. It allows to add CAs to cacerts at runtime for testing purpose. Webrev: http://cr.openjdk.java.net/~jjiang/8245520/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8245520 Best regards, John Jiang From weijun.wang at oracle.com Thu Jun 11 03:21:30 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Jun 2020 11:21:30 +0800 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> <77CE09E4-0A4F-41D1-A950-9CAF71F2317B@oracle.com> <8C294257-35F0-420A-BC93-A75C017A5C6B@oracle.com> Message-ID: <5E24D19E-8E5C-4343-AE89-C4D16A471CFA@oracle.com> "to a self-signed certificate in the keystore". This is not correct. What we look for is a TrustedCertificateEntry. "It emits warning when a certificate is not trusted and uses weak algorithms". Precisely, it's "uses a weak signature algorithm". --Max > On Jun 10, 2020, at 5:31 PM, Hai-May Chao wrote: > > > >> On Jun 9, 2020, at 5:58 PM, Weijun Wang wrote: >> >> Good to see both -keystore and -trustcacerts mentioned. Some comments: >> >> 1. I think there is no need to say "from -file cert_file". Or, do you mean the new function does not apply to those from -sslserver and -jarfile? If so, that might be a problem. > > You?re right. Removed it. > >> >> 2. While you said "attempts to construct a chain of trust", do you also want to describe what happens if it succeeds or fails? > > Updated manpage. > >> >> 3. It will be nice if you can include the exact diff of the man page files either inside the CSR itself or as a comment. >> > > Included the diff of the manpage in the CSR. > > Thanks, > Hai-May > > >> Thanks, >> Max >> >>> On Jun 9, 2020, at 10:51 PM, Hai-May Chao wrote: >>> >>> >>> >>>> On Jun 7, 2020, at 6:08 PM, Weijun Wang wrote: >>>> >>>> Looks fine to me. >>>> >>>> For CSR, since there is already a "Note" there for these 2 options, you can add a few words about what -keystore and -trustcacerts can do. >>> >>> Updated CSR as suggested. >>> >>> Thanks, >>> Hai-May >>> >>> >>>> >>>> Thanks, >>>> Max >>>> >>>>> On Jun 8, 2020, at 4:01 AM, Hai-May Chao wrote: >>>>> >>>>> Updated webrev - >>>>> >>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>> >>>>>> On Jun 5, 2020, at 11:04 PM, Weijun Wang wrote: >>>>>> >>>>>> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. >>>>>> >>>>>> Same for line 80 and line 96 of TrustedCRL.java. >>>>>> >>>>>> Everything else is fine. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: >>>>>>> >>>>>>> Updated webrev - >>>>>>> >>>>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>>>>>> >>>>>>> Added one command line -importcert in TrustCert.java. >>>>>>> Added createCacerts() in test/lib SecurityTools.java. >>>>>>> >>>>>>> Thanks, >>>>>>> Hai-May >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>>>>>>> >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> The source change looks fine to me. >>>>>>>>>> >>>>>>>>>> In TrustedCert.java: >>>>>>>>>> >>>>>>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>>>>>>> >>>>>>>>> This cat() is taken from WealAlg.java. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - There is no need to recreate root.jks and root.pem. >>>>>>>>> >>>>>>>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>>>>>>> >>>>>>>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>>>>>>> >>>>>>>>> >>>>>>>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Why not use -trustcacerts below? >>>>>>>>>> >>>>>>>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>>>>>>> >>>>>>>>> >>>>>>>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> Then how about we add a new command before line 155? >>>>>>>> >>>>>>>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>>>>>> >>>>>>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>>>>>>> >>>>>>>>> Ok, will change it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> In TrustedCRL.java: >>>>>>>>>> >>>>>>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>>>>>>> >>>>>>>>> Same reply as above. >>>>>>>> >>>>>>>> Same question as above. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>>>>>>> >>>>>>>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>>>>>>> >>>>>>>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>>>>>>> >>>>>>>> I meant creating the cacerts in one method, something like >>>>>>>> >>>>>>>> void createCacerts(String ks, String... crt); >>>>>>>> >>>>>>>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>>>>>>> >>>>>>>> BTW, what does caks.size() == 0 matter here? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Hai-May >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I?d like to request a review for: >>>>>>>>>>> >>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Hai-May >>>>>>> >>>>>> >>>>> >>>> >>> >> > From weijun.wang at oracle.com Thu Jun 11 03:25:00 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Jun 2020 11:25:00 +0800 Subject: RFR 8245520: Provide a way to add CA certificate to cacerts during test run In-Reply-To: <124fa783-00d3-f140-07c6-40aac08c466d@oracle.com> References: <124fa783-00d3-f140-07c6-40aac08c466d@oracle.com> Message-ID: <90ABC528-D206-4BCF-A500-35C41E0F9D52@oracle.com> Hai-May has a similar function as a by-product in https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ See FilePaths.java and MyOwnCacerts.java for the detail. Her code change is in code review now. Please coordinate with her on how to get this done nicely. Thanks, Max > On Jun 11, 2020, at 9:39 AM, sha.jiang at oracle.com wrote: > > Hi, > This patch contains a patched version for class sun.security.util.AnchorCertificates. > It allows to add CAs to cacerts at runtime for testing purpose. > > Webrev: http://cr.openjdk.java.net/~jjiang/8245520/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8245520 > > Best regards, > John Jiang > From weijun.wang at oracle.com Thu Jun 11 06:15:24 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Jun 2020 14:15:24 +0800 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <4f5595a1-8949-89b2-8cbf-dd5822ff29cc@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> <386f23a8-023d-200a-04ee-545677f95614@oracle.com> <8BAA3715-11BC-4A39-8C96-FD04CFE1BC84@oracle.com> <2552dfed-922d-5db1-6266-d82abb11a9f9@oracle.com> <0f0fecf1-a995-4e7c-a68f-841c70d01638@oracle.com> <4f5595a1-8949-89b2-8cbf-dd5822ff29cc@oracle.com> Message-ID: <4593D6B9-EF9A-456D-9439-4FB120087ED9@oracle.com> The old code 265 prng = "SHA1PRNG"; 266 this.secureRandomSpi = new sun.security.provider.SecureRandom(); 267 this.provider = Providers.getSunProvider(); always works since that class is always there. Now, it's 282 prngService = Providers.getSunProvider().getService("SecureRandom", 283 "SHA1PRNG"); If someone remove that service the above would return null. Can we simply reuse the old lines? Everything else looks fine. Thanks, Max > On Jun 11, 2020, at 8:16 AM, Valerie Peng wrote: > > Updated webrev after incorporating Sean's feedbacks: > > http://cr.openjdk.java.net/~valeriep/8246613/webrev.03/ > > Main changes are code refactoring in SecureRandom class and changed Provider class to store SecureRandom services in their order of registration instead of only the algorithm name. > > Thanks, > Valerie > On 6/9/2020 4:53 PM, Valerie Peng wrote: >> Hi, Sean, >> >> On 6/9/2020 12:21 PM, Sean Mullan wrote: >>> Looks good, just a couple of minor comments on the test: >>> >>> * test/jdk/java/security/SecureRandom/DefaultAlgo.java >>> >>> 75 Objects.requireNonNull(p); >>> >>> Not sure why you need this line, since the test never passes null. >> >> True, the test never passes null, this line is just to make it clear that the provider argument should not be null as the test is not prepared to handle null provider. It's not essential, so I removed it per your comment. >> >>> >>> 90 validate(new SecureRandom(), pName, algos[0]); >>> >>> Is there a reason why you don't call removeService for each algorithm when testing the non-legacy provider? >> >> The Provider.removeService(...) call is protected. So, it's not a public API for users of Provider objects. >> >> Thanks, >> Valerie >>> >>> --Sean >>> >>> On 6/9/20 12:52 PM, Valerie Peng wrote: >>>> Thanks for review~ >>>> >>>> As for the isProviderInfo() name, since I reverted the code for its impl to pre-7092821, I changed it back to the old name as you noticed. Sean mentioned that he also wants to take a look at this updated webrev, so I will wait for him to do that... >>>> >>>> Valerie >>>> >>>> On 6/8/2020 6:11 PM, Weijun Wang wrote: >>>>> Code change looks fine to me. >>>>> >>>>> I re-look at every place where legacyStrings and prngAlgorithms are used and they are all synchronized. Last time I thought some were not. Sorry. >>>>> >>>>> Only one comment: I like the isProviderInfo() name better, but I notice it was the old name pre-7092821. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> On Jun 9, 2020, at 6:31 AM, Valerie Peng wrote: >>>>>> >>>>>> Webrev updated: http://cr.openjdk.java.net/~valeriep/8246613/webrev.02/ >>>>>> >>>>>> Besides addressing Max's comments, I also made updateSecureRandomEntries(...) method private and removed the synchronized keyword as all of its accesses are synchronized. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> On 6/8/2020 2:33 PM, Valerie Peng wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> Please find comments in line. >>>>>>> >>>>>>> On 6/8/2020 2:34 AM, Weijun Wang wrote: >>>>>>>> Looks like this should work, but still find it complicated. >>>>>>>> >>>>>>>> 1. Do we need to care about thread safety when managing legacyStrings? >>>>>>> Right, it's more complicated than I like as well. >>>>>>> >>>>>>> As for thread safety, the legacy relevant data are all synchronized under the current provider object, i.e. this. Is there a particular call path not doing this? This is the same as the pre-7092821 code. >>>>>>> >>>>>>>> 2. Does implReplaceAll() need to set legacyChanged = true? >>>>>>> Correct, the removal is by accident. Thanks for catching this. >>>>>>>> 3. How about using prngAlgorithms.iterator().next() below? >>>>>>>> >>>>>>>> 1416 return prngAlgorithms.toArray(new String[0])[0]; >>>>>>> Sure, changed. >>>>>>> >>>>>>> Valerie >>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 6, 2020, at 11:54 AM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> Thanks for reviewing and sharing the feedbacks on webrev.00. >>>>>>>>> >>>>>>>>> In order to support all existing calls for legacy registration for default secure random, I have to revert some of the JDK-7092821 changes and re-introduce the 'legacyStrings' LinkedHashMap. Updated the regression test with removal test for provider using legacy registrations as well. Although removal is supported, this is still not bullet proof as things may not work as expected if a provider registered their impl in both ways, i.e. legacy String pair and Service, and then remove/replace some entries later. Please comment if you really need this scenario to be supported. Although not explicitly documented, I think the intention is to use one or the other, never both. >>>>>>>>> >>>>>>>>> Webrev update: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>>>>>>>>> Right, I try to keep the impl simple as I am not aware of any property removal usage. >>>>>>>>>> >>>>>>>>>> Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added. >>>>>>>>>> >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>>>>>>>>> I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". >>>>>>>>>>> >>>>>>>>>>> And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. >>>>>>>>>>> >>>>>>>>>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>>>>>>>>> >>>>>>>>>>> --Max >>>>>>>>>>> >>>>>>>>>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Looks good to me, one question >>>>>>>>>>>> >>>>>>>>>>>> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Prasad.K >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Valerie Peng >>>>>>>>>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>>>>>>>>> To: security-dev at openjdk.java.net >>>>>>>>>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >>>>>>>>>>>>> based on registration ordering >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, Sean, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for the review and feedback. Webrev updated: >>>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> getTypeAndAlgorithm(...) was not static due to an instance variable used by >>>>>>>>>>>>> debugging output. I have removed it and made both method static. >>>>>>>>>>>>> >>>>>>>>>>>>> I will wait for others' review comments also. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Valerie >>>>>>>>>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>>>>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could someone help reviewing this fix? This change keep tracks of the >>>>>>>>>>>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>>>>>>>>>>> request of SecureRandom class. >>>>>>>>>>>>>> This looks good to me. I would recommend that Max or someone else >>>>>>>>>>>>>> review it as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>>>>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>>>>>>>>> >>>>>>>>>>>>>> * SecureRandom.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> 879 // For SUN provider, we use >>>>>>>>>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>>>>>>>>> >>>>>>>>>>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Provider.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1156 private String parseSecureRandomPut(String name, String >>>>>>>>>>>>>> value) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>>>>>>>>>>>> >>>>>>>>>>>>>> --Sean From sha.jiang at oracle.com Thu Jun 11 07:55:12 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 11 Jun 2020 15:55:12 +0800 Subject: RFR 8245520: Provide a way to add CA certificate to cacerts during test run In-Reply-To: <90ABC528-D206-4BCF-A500-35C41E0F9D52@oracle.com> References: <124fa783-00d3-f140-07c6-40aac08c466d@oracle.com> <90ABC528-D206-4BCF-A500-35C41E0F9D52@oracle.com> Message-ID: Hi Max, Thanks for your info! It looks that patch for java.base:sun.security.util.FilePaths.java is used for specifying an alternative cacerts file. But my requirement is updating the existing cacerts with given CAs. Both of the functions are useful. I'll submit a new webrev after the fix for JDK-8244148 is pushed. I also have some comments about Hai-May's webrev. Best regards, John Jiang On 2020/6/11 11:25, Weijun Wang wrote: > Hai-May has a similar function as a by-product in > > https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ > > See FilePaths.java and MyOwnCacerts.java for the detail. Her code change is in code review now. > > Please coordinate with her on how to get this done nicely. > > Thanks, > Max > >> On Jun 11, 2020, at 9:39 AM, sha.jiang at oracle.com wrote: >> >> Hi, >> This patch contains a patched version for class sun.security.util.AnchorCertificates. >> It allows to add CAs to cacerts at runtime for testing purpose. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8245520/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8245520 >> >> Best regards, >> John Jiang >> From sha.jiang at oracle.com Thu Jun 11 08:45:28 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 11 Jun 2020 16:45:28 +0800 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> Message-ID: Hi Hai-May, On 2020/6/8 04:01, Hai-May Chao wrote: > Updated webrev - > > https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ -- src/java.base/share/classes/sun/security/util/FilePaths.java Would it be better to use String.join() or even java.nio.file.Path to build the file path? -- src/java.base/share/classes/sun/security/util/AnchorCertificates.java 55???????????????? File f = new File(FilePaths.cacerts()); ... 59???????????????????? try (FileInputStream fis = new FileInputStream(f)) { f is used only once, so it may be unnecessary. 56???????????????? KeyStore cacerts; Though it's not in your change, would you mind to declare this variable in the try block? I just want to narrow the variable scope. -- test/lib/jdk/test/lib/SecurityTools.java Could move method createCacerts() to test/lib/jdk/test/lib/security/KeyStoreUtils.java? This class contains a set of methods for creating trust/key stores. And getCertFromFile() in test/lib/jdk/test/lib/security/CertUtils.java can load certificate from a file. 289???????? int pos = 0; ... 294???????????? for (String crt : crts) { If not using for-each style, pos can be declared in the for statement. -- test/jdk/sun/security/tools/keytool/fakecacerts/java.base/sun/security/util/FilePaths.java This patch can be used by other tests, so could you please move it to a common path? Like test/jdk/sun/security/util/module_patch/java.base/sun/security/util/FilePaths.java 32???? public static String cacerts() { 33???????? return "mycacerts"; 34???? } Could it be flexible for returning an alternative path? For example, accept a system property, say test.cacerts, for specifying an alternative path. mycacerts is the default value of this property. Best regards, John Jiang > > Thanks, > Hai-May > > >> On Jun 5, 2020, at 11:04 PM, Weijun Wang > > wrote: >> >> I still think duplicated commands in TrustedCert.java are useless. >> Line 104 and line 133 are exactly the same, line 109 and line 138 are >> exactly the same, and you haven't made any change to these 2 files in >> between. >> >> Same for line 80 and line 96 of TrustedCRL.java. >> >> Everything else is fine. >> >> Thanks, >> Max >> >> >>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao >> > wrote: >>> >>> Updated webrev - >>> >>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>> >>> Added one command line -importcert in TrustCert.java. >>> Added createCacerts() in test/lib SecurityTools.java. >>> >>> Thanks, >>> Hai-May >>> >>> >>> >>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao >>>>> wrote: >>>>> >>>>> Hi Max, >>>>> >>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang >>>>>> wrote: >>>>>> >>>>>> The source change looks fine to me. >>>>>> >>>>>> In TrustedCert.java: >>>>>> >>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) >>>>>> in cat(). >>>>> >>>>> This cat() is taken from WealAlg.java. >>>>> >>>>>> >>>>>> - There is no need to recreate root.jks and root.pem. >>>>> >>>>> The sequences of the commands used in this test scenario allows me >>>>> to test -printcert for the -trustcacerts and -keytsore options. We >>>>> had discussion offline about it. The test uses trusted >>>>> certificates and checks no warnings on the weak algorithms to >>>>> address the requirement described in the bug. I believe it does >>>>> serve that purpose, and looks legitimate to me. There could be >>>>> different ways of testing a functionality, and please let me know >>>>> if there is a problem with the current approach. >>>> >>>> I just meant that the keytool commands generating root.jks and >>>> root.pem are exactly the same and there is no need to recreate it. >>>> >>>>> >>>>> Please also elaborate your comment about no need to recreate >>>>> root.jks and root.pem. >>>>> >>>>>> >>>>>> - Why not use -trustcacerts below? >>>>>> >>>>>> 160 ????????kt("-importcert -file server.pem -noprompt", >>>>>> "server.jks?); >>>>> >>>>> >>>>> Because here is to import the server (end-entity) cert, and it >>>>> will not make a difference for the test result whether to use the >>>>> -trustcacerts or not. It?s the ca (intermediate) cert needs to >>>>> have it in this test scenario. I intended to leave it out in #160 >>>>> to distinguish between server and ca certs. >>>> >>>> OK. >>>> >>>> Then how about we add a new command before line 155? >>>> >>>> ??kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>> >>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>> >>>>> >>>>>> >>>>>> - It's probably better to add a " " between cmd and options in >>>>>> patchcmd(). Same in TrustedCRL.java. >>>>> >>>>> Ok, will change it. >>>>> >>>>>> >>>>>> In TrustedCRL.java: >>>>>> >>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with >>>>>> different options. >>>>> >>>>> Same reply as above. >>>> >>>> Same question as above. >>>> >>>>> >>>>>> >>>>>> - Why create using MD5withRSA? Do you meant to warn about the >>>>>> weak algorithm? >>>>> >>>>> Yes, exactly, and it differentiates from the weak algorithm >>>>> SHA1withRSA used in root CA where no warning will be emitted. >>>>> There is another -gencrl in #119 without using MD5withRSA so I?d >>>>> have two test cases. >>>>> >>>>>> >>>>>> Also I would suggest you create a dedicate method (maybe in >>>>>> SecurityTools.java) to create your own cacerts. There is no need >>>>>> to copy over the system cacerts, just make sure the file is >>>>>> created with the JKS storetype. We are thinking of upgrading the >>>>>> storetype of cacerts and it's nice to do this at a single place >>>>>> so we can modify it easily later. >>>>> >>>>> I created a method in SecurityTools.java to create the own >>>>> cacerts. With this keystore, the subsequent importing a >>>>> certificate reply would not work. It turns out that its >>>>> caks.size() is zero detected at establishCertChain() in >>>>> keytool/Main.java after root cert has been imported to that >>>>> cacerts. At this point I?d like to suggest a separate bug be filed >>>>> to cover the cacerts enhancement that you suggested. >>>> >>>> I meant creating the cacerts in one method, something like >>>> >>>> ?void createCacerts(String ks, String... crt); >>>> >>>> and you can call createCacerts("mycacerts", "root.crt") to create >>>> it. The method can call KeyStore APIs and not keytool commands. >>>> >>>> BTW, what does caks.size() == 0 matter here? >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I?d like to request a review for: >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>> >>>>>>> The change is to add the support of -trustcacerts and -keystore >>>>>>> options to -printcert and -princrl command for keytool. This >>>>>>> enables keytool to use the trusted certificates when verifying >>>>>>> untrusted artifacts that are signed by CAs. It also incorporates >>>>>>> Max?s change that consolidates the code to get the default >>>>>>> location of cacerts keystore. >>>>>>> >>>>>>> Thanks, >>>>>>> Hai-May >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasadarao.koppula at oracle.com Thu Jun 11 08:50:48 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Thu, 11 Jun 2020 01:50:48 -0700 (PDT) Subject: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test In-Reply-To: <3d987471-bcf7-0062-a25f-465ca4953352@oracle.com> References: <26ba099b-c324-4492-abfc-ad454041382a@default> <3d987471-bcf7-0062-a25f-465ca4953352@oracle.com> Message-ID: <02c7da1a-4e5b-4d8e-8a00-bac800147415@default> Thanks for review Xuelei, Removed handleException changes. Please review the change from latest webrev[1] >+ } else { >+ handleException(iioe); handleException throws exception for InterruptedIOException without closing the connection. A direct conContext.fatal call helps to close the connection. Updated the code accordingly. >+ } Thanks, Prasad.K [1] http://cr.openjdk.java.net/~pkoppula/8246031/webrev.01/ >-----Original Message----- >From: Xuelei Fan >Sent: Wednesday, June 10, 2020 10:13 PM >To: security-dev at openjdk.java.net >Subject: Re: [15] RFR JDK-8246031: Hang observed with coherence >SSLNIOServer test > >It may be not needed to update the handleException() method. > >- 440 handleException(iioe); >+ 440 if (resumable) { >+ throw iioe; >+ } else { >+ handleException(iioe); handleException throws exception for InterruptedIOException without closing the connection. A direct conContext.fatal call helps to close the connection. Update the code accordingly. >+ } > >Otherwise, looks good to me. > >Xuelei > >On 6/4/2020 8:13 AM, Prasadrao Koppula wrote: >> Hi, >> >> Could you please review this patch. For timeout/interrupts, JDK11u+ >> releases, SSLSocket:getSession behavior is different, compare to JDK8u. >> i.e, connection is in open state for timeout/interrupts exception. For >> comparability reasons, this fix will close connection for getSession >> timeout/ interrupts. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8246031 >> >> Webrev: http://cr.openjdk.java.net/~pkoppula/8246031/webrev.00/ >> >> Thanks, >> >> Prasad.K >> From sean.coffey at oracle.com Thu Jun 11 14:47:13 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 11 Jun 2020 15:47:13 +0100 Subject: Thread leak by LdapLoginModule In-Reply-To: <889628466.1257399.1591737319316.JavaMail.zimbra@desy.de> References: <889628466.1257399.1591737319316.JavaMail.zimbra@desy.de> Message-ID: If 8217606 is your issue, then it's fixed in JDK 11.0.8 which is due for release in mid July. regards, Sean. On 09/06/2020 22:15, Mkrtchyan, Tigran wrote: > Hi all, > > with Java-11 we have notice a thread leak with ldap module. > We use LDAP to authenticate users with username+pasword by > directly calling LdapLoginModule. This was ok with java 7 and > java 8. With java 11 we see threads getting accumulated. here is a > test case that demonstrates it: > > ``` > > private static final String USERNAME_KEY = "javax.security.auth.login.name"; > private static final String PASSWORD_KEY = "javax.security.auth.login.password"; > > String ldapUrl = "ldap://...."; > String peopleOU = "ou= ... o= ... c=..."); > > String user = ...; > String pass = ...; > > > @Test > public void threadLeakTest() throws AuthenticationException, NoSuchPrincipalException, LoginException { > > Map threadsBefore = Thread.getAllStackTraces(); > > Map globalLoginOptions = Map.of( > "userProvider", ldapUrl + "/" + peopleOU, > "useSSL", "false", > "userFilter", "(uid={USERNAME})", > "useFirstPass", "true" > ); > > for (int i = 0; i < 10; i++) { > > Map loginOptions = Map.of( > USERNAME_KEY, user, > PASSWORD_KEY, pass.toCharArray()); > > Subject subject = new Subject(); > > LdapLoginModule loginModule = new LdapLoginModule(); > loginModule.initialize(subject, null, loginOptions, globalLoginOptions); > loginModule.login(); > loginModule.commit(); > loginModule.logout(); > } > > Map threadsAfter = Thread.getAllStackTraces(); > > assertEquals("Thread leak detected", threadsBefore.size() + 1, threadsAfter.size()); > } > > ``` > > The thread count difference is always equals to the number of iterations in the loop, e.g. on each call a > thread is created and stays around. Eventually our server crashes with: > > [19497.011s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007fcc4c65c000-0x00007fcc4c660000). > OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007fcc4c55b000, 16384, 0) failed; error='Not enough space' (errno=12) > > The issue is not observed with java-14, thus I assume that the fix is related to commit > > http://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 > > As java-11 is LTS, what is the procedure to get it fix back-ported? > > Regards, > Tigran. From xuelei.fan at oracle.com Thu Jun 11 15:32:46 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 11 Jun 2020 08:32:46 -0700 Subject: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test In-Reply-To: <02c7da1a-4e5b-4d8e-8a00-bac800147415@default> References: <26ba099b-c324-4492-abfc-ad454041382a@default> <3d987471-bcf7-0062-a25f-465ca4953352@oracle.com> <02c7da1a-4e5b-4d8e-8a00-bac800147415@default> Message-ID: On 6/11/2020 1:50 AM, Prasadrao Koppula wrote: > http://cr.openjdk.java.net/~pkoppula/8246031/webrev.01/ I may have 8 more white spaces indent at line 449, and have 446 and 447 in one line. Otherwise, looks good to me. Need no more review from me. Thanks, Xuelei From prasadarao.koppula at oracle.com Thu Jun 11 16:12:42 2020 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Thu, 11 Jun 2020 09:12:42 -0700 (PDT) Subject: [15] RFR JDK-8246031: Hang observed with coherence SSLNIOServer test In-Reply-To: References: <26ba099b-c324-4492-abfc-ad454041382a@default> <3d987471-bcf7-0062-a25f-465ca4953352@oracle.com> <02c7da1a-4e5b-4d8e-8a00-bac800147415@default> Message-ID: <12c3c900-8796-4fb4-b616-934de3d2c52e@default> Thanks Xuelei, updated the code accordingly. Thanks, Prasad.K >-----Original Message----- >From: Xuelei Fan >Sent: Thursday, June 11, 2020 9:03 PM >To: Prasadrao Koppula ; security- >dev at openjdk.java.net >Subject: Re: [15] RFR JDK-8246031: Hang observed with coherence >SSLNIOServer test > >On 6/11/2020 1:50 AM, Prasadrao Koppula wrote: >> http://cr.openjdk.java.net/~pkoppula/8246031/webrev.01/ >I may have 8 more white spaces indent at line 449, and have 446 and 447 in >one line. > >Otherwise, looks good to me. Need no more review from me. > >Thanks, >Xuelei From valerie.peng at oracle.com Thu Jun 11 18:28:45 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 11 Jun 2020 11:28:45 -0700 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: <4593D6B9-EF9A-456D-9439-4FB120087ED9@oracle.com> References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> <3d5f62f0-a125-f9b8-74b7-5d838fe77278@oracle.com> <8b3a106b-b018-41c1-5a49-14cadd5bbae7@oracle.com> <386f23a8-023d-200a-04ee-545677f95614@oracle.com> <8BAA3715-11BC-4A39-8C96-FD04CFE1BC84@oracle.com> <2552dfed-922d-5db1-6266-d82abb11a9f9@oracle.com> <0f0fecf1-a995-4e7c-a68f-841c70d01638@oracle.com> <4f5595a1-8949-89b2-8cbf-dd5822ff29cc@oracle.com> <4593D6B9-EF9A-456D-9439-4FB120087ED9@oracle.com> Message-ID: Hi, Max, Sure, I've reverted to that old code so it should be bullet proof now. Webrev updated: http://cr.openjdk.java.net/~valeriep/8246613/webrev.04/ Will proceed with integration once pre-integration Mach5 tests finishes. Thanks for reviewing~ Valerie On 6/10/2020 11:15 PM, Weijun Wang wrote: > The old code > > 265 prng = "SHA1PRNG"; > 266 this.secureRandomSpi = new sun.security.provider.SecureRandom(); > 267 this.provider = Providers.getSunProvider(); > > always works since that class is always there. > > Now, it's > > 282 prngService = Providers.getSunProvider().getService("SecureRandom", > 283 "SHA1PRNG"); > > If someone remove that service the above would return null. Can we simply reuse the old lines? > > Everything else looks fine. > > Thanks, > Max > > >> On Jun 11, 2020, at 8:16 AM, Valerie Peng wrote: >> >> Updated webrev after incorporating Sean's feedbacks: >> >> http://cr.openjdk.java.net/~valeriep/8246613/webrev.03/ >> >> Main changes are code refactoring in SecureRandom class and changed Provider class to store SecureRandom services in their order of registration instead of only the algorithm name. >> >> Thanks, >> Valerie >> On 6/9/2020 4:53 PM, Valerie Peng wrote: >>> Hi, Sean, >>> >>> On 6/9/2020 12:21 PM, Sean Mullan wrote: >>>> Looks good, just a couple of minor comments on the test: >>>> >>>> * test/jdk/java/security/SecureRandom/DefaultAlgo.java >>>> >>>> 75 Objects.requireNonNull(p); >>>> >>>> Not sure why you need this line, since the test never passes null. >>> True, the test never passes null, this line is just to make it clear that the provider argument should not be null as the test is not prepared to handle null provider. It's not essential, so I removed it per your comment. >>> >>>> 90 validate(new SecureRandom(), pName, algos[0]); >>>> >>>> Is there a reason why you don't call removeService for each algorithm when testing the non-legacy provider? >>> The Provider.removeService(...) call is protected. So, it's not a public API for users of Provider objects. >>> >>> Thanks, >>> Valerie >>>> --Sean >>>> >>>> On 6/9/20 12:52 PM, Valerie Peng wrote: >>>>> Thanks for review~ >>>>> >>>>> As for the isProviderInfo() name, since I reverted the code for its impl to pre-7092821, I changed it back to the old name as you noticed. Sean mentioned that he also wants to take a look at this updated webrev, so I will wait for him to do that... >>>>> >>>>> Valerie >>>>> >>>>> On 6/8/2020 6:11 PM, Weijun Wang wrote: >>>>>> Code change looks fine to me. >>>>>> >>>>>> I re-look at every place where legacyStrings and prngAlgorithms are used and they are all synchronized. Last time I thought some were not. Sorry. >>>>>> >>>>>> Only one comment: I like the isProviderInfo() name better, but I notice it was the old name pre-7092821. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> On Jun 9, 2020, at 6:31 AM, Valerie Peng wrote: >>>>>>> >>>>>>> Webrev updated: http://cr.openjdk.java.net/~valeriep/8246613/webrev.02/ >>>>>>> >>>>>>> Besides addressing Max's comments, I also made updateSecureRandomEntries(...) method private and removed the synchronized keyword as all of its accesses are synchronized. >>>>>>> >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> On 6/8/2020 2:33 PM, Valerie Peng wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> Please find comments in line. >>>>>>>> >>>>>>>> On 6/8/2020 2:34 AM, Weijun Wang wrote: >>>>>>>>> Looks like this should work, but still find it complicated. >>>>>>>>> >>>>>>>>> 1. Do we need to care about thread safety when managing legacyStrings? >>>>>>>> Right, it's more complicated than I like as well. >>>>>>>> >>>>>>>> As for thread safety, the legacy relevant data are all synchronized under the current provider object, i.e. this. Is there a particular call path not doing this? This is the same as the pre-7092821 code. >>>>>>>> >>>>>>>>> 2. Does implReplaceAll() need to set legacyChanged = true? >>>>>>>> Correct, the removal is by accident. Thanks for catching this. >>>>>>>>> 3. How about using prngAlgorithms.iterator().next() below? >>>>>>>>> >>>>>>>>> 1416 return prngAlgorithms.toArray(new String[0])[0]; >>>>>>>> Sure, changed. >>>>>>>> >>>>>>>> Valerie >>>>>>>> >>>>>>>>> --Max >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jun 6, 2020, at 11:54 AM, Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> Thanks for reviewing and sharing the feedbacks on webrev.00. >>>>>>>>>> >>>>>>>>>> In order to support all existing calls for legacy registration for default secure random, I have to revert some of the JDK-7092821 changes and re-introduce the 'legacyStrings' LinkedHashMap. Updated the regression test with removal test for provider using legacy registrations as well. Although removal is supported, this is still not bullet proof as things may not work as expected if a provider registered their impl in both ways, i.e. legacy String pair and Service, and then remove/replace some entries later. Please comment if you really need this scenario to be supported. Although not explicitly documented, I think the intention is to use one or the other, never both. >>>>>>>>>> >>>>>>>>>> Webrev update: http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> On 6/5/2020 11:00 AM, Valerie Peng wrote: >>>>>>>>>>> Right, I try to keep the impl simple as I am not aware of any property removal usage. >>>>>>>>>>> >>>>>>>>>>> Oh-well, if we have to cater to the removal scenario, then we'd have to add a List and keep track of ALL secure random algos instead of only the FIRST one. Alright, I guess it costs for covering all aspect. But one extra benefit of this is that it should be easy to handle the future JDK property such as "jdk.securerandom.disabledAlgorithms" if it were to be added. >>>>>>>>>>> >>>>>>>>>>> Valerie >>>>>>>>>>> >>>>>>>>>>> On 6/5/2020 7:54 AM, Weijun Wang wrote: >>>>>>>>>>>> I don't know who in this world would want to do that, but Prasad's concern is technically possible. I tried 'p.remove("SecureRandom.a")' in the new test, and new SecureRandom() fails with "java.security.NoSuchAlgorithmException: a SecureRandom not available". >>>>>>>>>>>> >>>>>>>>>>>> And people can also remove one entry and add it back in order to move it to the end. One can even add new implementations this way. >>>>>>>>>>>> >>>>>>>>>>>> Unfortunately there is no ConcurrentLinkedHashMap. >>>>>>>>>>>> >>>>>>>>>>>> --Max >>>>>>>>>>>> >>>>>>>>>>>>> On Jun 5, 2020, at 1:44 PM, Prasadrao Koppula wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Looks good to me, one question >>>>>>>>>>>>> >>>>>>>>>>>>> If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Prasad.K >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Valerie Peng >>>>>>>>>>>>>> Sent: Friday, June 5, 2020 2:52 AM >>>>>>>>>>>>>> To: security-dev at openjdk.java.net >>>>>>>>>>>>>> Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >>>>>>>>>>>>>> based on registration ordering >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, Sean, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for the review and feedback. Webrev updated: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> getTypeAndAlgorithm(...) was not static due to an instance variable used by >>>>>>>>>>>>>> debugging output. I have removed it and made both method static. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will wait for others' review comments also. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Valerie >>>>>>>>>>>>>> On 6/4/2020 2:01 PM, Sean Mullan wrote: >>>>>>>>>>>>>>> On 6/4/20 3:34 PM, Valerie Peng wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could someone help reviewing this fix? This change keep tracks of the >>>>>>>>>>>>>>>> first registered SecureRandom algorithm and returns it upon the >>>>>>>>>>>>>>>> request of SecureRandom class. >>>>>>>>>>>>>>> This looks good to me. I would recommend that Max or someone else >>>>>>>>>>>>>>> review it as well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >>>>>>>>>>>>>>> A couple of minor comments, feel free to fix or ignore. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * SecureRandom.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 879 // For SUN provider, we use >>>>>>>>>>>>>>> SunEntries.DEFF_SECURE_RANDOM_ALGO >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Might as well fix the typo while you are in there: s/DEFF/DEF/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * Provider.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1156 private String parseSecureRandomPut(String name, String >>>>>>>>>>>>>>> value) { >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could be static if you also make getTypeAndAlgorithm static, I think. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --Sean From valerie.peng at oracle.com Fri Jun 12 00:07:47 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 11 Jun 2020 17:07:47 -0700 Subject: [EXTERNAL]Re: NullPointer in JceSecurity.getVerificationResult - Affects JDK 11.07, and JDK 12 and later. In-Reply-To: References: <651b2416-4764-d460-e3f9-56ef073a5c35@oracle.com> <83d5548d-9760-4c7a-c9f6-89519849dd74@oracle.com> Message-ID: <8d9878f9-f382-3664-d9c6-7be11662ac2e@oracle.com> Hi, John, Thanks for the reply. Yes, your understanding is correct. I expect the fix for JDK-8246613 will be backported into other releases. BTW, if you have spare time for the test provider, it'd help speeding up the fix for JDK-8246383. If not, it's ok as well. Just may take longer to get to it. Regards, Valerie On 6/10/2020 1:31 PM, John Gray wrote: > > Thanks Valerie! > > If I understand you correctly, I think you are saying the fix for > https://bugs.openjdk.java.net/browse/JDK-8246613 ?will mean the first > SecureRandom in the provider will be used as the default (which will > make it equivalent to JDK 11.06 and previous versions).??? If that is > the case, I agree it should mitigate the issue and would be ok with > lowering the priority of 8246383. > > Will this new fix be back-ported into 11 LTS versions as well? > > Thanks so much for your amazing fast response.?? I have been trying to > set aside some time to put together a simple sample you can use to > verify 8246383 (that doesn?t require our full toolkit), but haven?t > been able to find the time to do that yet. > > Cheers, > > John Gray > > *From:*Valerie Peng [mailto:valerie.peng at oracle.com] > *Sent:* Wednesday, June 10, 2020 4:14 PM > *To:* John Gray ; > security-dev at openjdk.java.net > *Cc:* Muthu Kannappan ; Raj Arora > > *Subject:* [EXTERNAL]Re: NullPointer in > JceSecurity.getVerificationResult - Affects JDK 11.07, and JDK 12 and > later. > > *WARNING:* This email originated outside of Entrust Datacard. > *DO NOT CLICK* links or attachments unless you trust the sender and > know the content is safe. > > ------------------------------------------------------------------------ > > Hi John, > > As you may have noticed, we are progressing a fix for > https://bugs.openjdk.java.net/browse/JDK-8246613 > for returning the > same default SecureRandom algo for 3rd party providers as in > pre-JDK7092821 releases. Thus, the chance of observing JDK-8246613 > should be lowered significantly. Given this, I plan to lower the > priority of JDK-8246383 and it may not be fixed in JDK 15 as earlier > communicated. > > If this will be an issue, please let me know. > > Thanks, > Valerie > > On 6/2/2020 4:37 PM, Valerie Peng wrote: > > Thanks for reporting the bug and the detailed analysis. > > I have filed https://bugs.openjdk.java.net/browse/JDK-8246383 to > keep track of this. Will aim to fix this for 15 and have it > backported accordingly. > > Is it possible to get hold of an test provider to reproduce and > verifying the fix? > > Regards, > > Valerie > > On 6/2/2020 1:18 PM, John Gray wrote: > > Hello, > > At Entrust Datacard, we produce a Java based toolkit that > contains our own Security Provider.?? This toolkit and > provider ?has been around for about 19 years. > > In JDK version 11.07 (and I also think Java 12 and beyond), > our toolkit reports the following error: > > java.lang.RuntimeException: > java.security.NoSuchAlgorithmException: Error constructing > implementation (algorithm: X9_31usingAES256, provider: > Entrust, class: > com.entrust.toolkit.security.crypto.random.X9_31usingAES256) > at > java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:281) > at > java.base/java.security.SecureRandom.(SecureRandom.java:219) > at > java.base/javax.crypto.JceSecurity.(JceSecurity.java:80) > ... 41 more > Caused by: java.security.NoSuchAlgorithmException: Error > constructing implementation (algorithm: X9_31usingAES256, > provider: Entrust, class: > com.entrust.toolkit.security.crypto.random.X9_31usingAES256) > at > java.base/java.security.Provider$Service.newInstance(Provider.java:1825) > at > java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236) > at > java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164) > at > java.base/java.security.SecureRandom.getInstance(SecureRandom.java:365) > at > java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:273) > ... 43 more > Caused by: java.lang.NullPointerException > at > java.base/javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:203) > at java.base/javax.crypto.Cipher.getInstance(Cipher.java:690) > at java.base/javax.crypto.Cipher.getInstance(Cipher.java:625) > at > com.entrust.toolkit.security.crypto.random.X9_31usingAES256.initialize(X9_31usingAES256.java:524) > at > com.entrust.toolkit.security.crypto.random.X9_31usingAES256.(X9_31usingAES256.java:102) > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at > java.base/java.security.Provider.newInstanceUtil(Provider.java:176) > at > java.base/java.security.Provider$Service.newInstance(Provider.java:1818) > > I investigated this error, and found it was made possible > because of the following change in Java 11.07 which unmasked a > bug in the JVM that has probably been around for years. > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8228613 > > It is a problem inside the JceSecurity class.? When the class > is being loaded, the call to setup a default SecureRandom() > instance is invoked.?? ?That seems to invoke the JVM to find > the first available SecureRandom() instance.? ??This error > happens when our Entrust provider is in first position.?? In > previous versions of the JDK it honoured the order of > algorithms specified in the providers.?? In our Entrust > Security provider, we have a number of SecureRandom > implementations.?? Now because of the above change, it picks a > different SecureRandom instance (the X9_31usingAES256).?? That > should be fine, however the problem is that the SecureRandom() > setup calls Cipher.getInstance() and as you can see below, > that calls JceSecurity.getVerificationResult() which is > static, and uses the verificationResuts Map that has not yet > been initialized (becasuse it?s declaration is after the > SecureRandom setup).??? That is why there is a > NullPointerException. > > *public* *static* *final* Cipher getInstance(String > transformation, > > Provider provider) > > *throws* NoSuchAlgorithmException, NoSuchPaddingException > > ??? { > > *if* ((transformation == *null*) || transformation.equals("")) { > > *throw* *new* NoSuchAlgorithmException("Null or empty > transformation"); > > ??????? } > > *if* (provider == *null*) { > > *throw* *new* IllegalArgumentException("Missing provider"); > > ??????? } > > ??????? Exception failure = *null*; > > ??????? List transforms = > getTransforms(transformation); > > *boolean* providerChecked = *false*; > > ??????? String paddingError = *null*; > > *for* (Transform tr : transforms) { > > ??????????? Service s = provider.getService("Cipher", > tr.transform); > > *if* (s == *null*) { > > *continue*; > > ??????????? } > > *if* (providerChecked == *false*) { > > ??????????????? // for compatibility, first do the lookup and > then verify > > ??????????????? // the provider. this makes the difference > between a NSAE > > ??????????????? // and a SecurityException if the > > ??????????????? // provider does not support the algorithm. > > ??????????????? Exception ve = > JceSecurity.getVerificationResult(provider); > > *if* (ve != *null*) { > > ??????????????????? String msg = "JCE cannot authenticate the > provider " > > ??????????????????????? + provider.getName(); > > *throw* *new* SecurityException(msg, ve); > > ??????????????? } > > ??????????????? providerChecked = *true*; > > ??????????? } > > The JceSecurity.getVerificationResult(provider) method is used > when initializing the SecureRandom (first highlighted line > below) when the classLoader is loading the JceSecurity class > itself. > > From the JceSecurity class: > > *static* *final* SecureRandom RANDOM = *new* SecureRandom(); > > ??? // The defaultPolicy and exemptPolicy will be set up > > ??? // in the static initializer. > > *private* *static* CryptoPermissions defaultPolicy = *null*; > > *private* *static* CryptoPermissions exemptPolicy = *null*; > > ?? ?// Map of the providers we already have verified > > ??? // value == PROVIDER_VERIFIED is successfully verified > > ??? // value is failure cause Exception in error case > > *private* *static* *final* Map > verificationResults = > > *new* IdentityHashMap<>(); > > It fails when it calls the following code in JceSecurity.java > because the verificationResults Map has not > been initialized because the SecureRandom() constructor ends > up calling the JceSecurity.getVerificationResult() static > method that makes use of the Map!? That explains the > NullPointerException. > > The fix to the issue should be simple, just move the > initialization of the verificationResults Map BEFORE the > SecureRandom initialization in JceSecurity.java > > Because verificationResults is not initialized, the line > highlighted below fails (Because the Map has not been > initialized). > > /* > > ???? * Verify that the provider JAR files are signed properly, > which > > ???? * means the signer's certificate can be traced back to a > > ???? * JCE trusted CA. > > ???? * Return null if ok, failure Exception if verification > failed. > > ???? */ > > *static* *synchronized* Exception > getVerificationResult(Provider p) { > > ??????? Object o = verificationResults.get(p); > > *if* (o == PROVIDER_VERIFIED) { > > *return* *null*; > > ??????? } *else* *if* (o != *null*) { > > *return* (Exception)o; > > ??????? } > > *if* (verifyingProviders.get(p) != *null*) { > > ??????????? // this method is static synchronized, must be > recursion > > ??????????? // return failure now but do not save the result > > *return* *new* NoSuchProviderException("Recursion during > verification"); > > ????? ??} > > *try* { > > ??????????? verifyingProviders.put(p, Boolean.FALSE); > > ??????????? URL providerURL = getCodeBase(p.getClass()); > > verifyProvider(providerURL, p); > > ??????????? // Verified ok, cache result > > verificationResults.put(p, PROVIDER_VERIFIED); > > *return* *null*; > > ??????? } *catch* (Exception e) { > > verificationResults.put(p, e); > > *return* e; > > ??????? } *finally* { > > verifyingProviders.remove(p); > > ??????? } > > ??? } > > Cheers, > > John Gray > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Jun 12 09:20:32 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 12 Jun 2020 10:20:32 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> Message-ID: <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> Hi Alexey, This is starting to look good. Thank you for persisting! I have a couple of comments - on the LDAP/JNDI side. There are several places where your new code is supposed to trigger the throwing of a NamingException: LdapSasl.java: lines 76, 85, 140, 168 Please write a test to verify that it does so. Since the exceptions are all supposed to be thrown before the actual binding happens, there's no need to have an actual LDAP server that supports any kind of authentication to test that. The simple dummy servers that we have in the test base should be enough to write such a test. In addition, there are a couple of places where stray exceptions could theoretically be thrown, and where they should be wrapped in NamingException (but are not). Maybe it's OK, because this has been checked before - but it would be better if we had a test that proves that it is so: For instance: LdapSasl.java 82 connectTimeout = Integer.parseInt((String)propVal); What if the value of the propVal is "Foo" - or not a String? What unexpected exception might be relayed to the calling code? Still in that same file: 84 if (connectTimeout == -1) should probably be if (connectTimeout <= 0) since Connection.java checks for connectTimeout > 0 to determine whether to start the initial handshake. Which makes me wonder if we should find a better way to instruct Connection to start the initial handshake... TlsChannelBinding.java: It would be much better if static factories methods were used instead of public constructors. That would allow you to check all arguments before actually constructing your object: public static TlsChannelBinding create((byte[] finishedMessage) throws SaslException { throw new UnsupportedOperationException("tls-unique channel binding is not supported"); } public statuic TlsChannelBinding create(X509Certificate serverCertificate) throws SaslException { var cbType = TlsChannelBindingType.TLS_SERVER_END_POINT; byte[] cbData; try { // compute cbdata ... return new TlsChannelBinding(cbType, cbData); } private TlsChannelBinding(TlsChannelBindingType cbType, byte[] cbData) { this.cbType = cbType; this.cbData = cbData; } That's all I have for now. best regards, -- daniel On 09/06/2020 22:03, Alexey Bakhtin wrote: > Hello Aleks, > > Thank you very much for review. > > I?ve fixed missed spaces and removed casting from LdapSasl.java > Failure of the SaslMutual test was caused by prop.remove() in the GssKrb5Client > This operation is not required any more. GssKrb5Client receives temporary copy of the properties. Fixed > > Also, I?ve added references to RFC-5929 and RFC-5056 into the TlsChannelBinding class > > Updated patch is located at: > http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v7/ > > Regards > Alexey From sean.coffey at oracle.com Fri Jun 12 10:21:18 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 12 Jun 2020 11:21:18 +0100 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file Message-ID: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> Hi, I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms https://bugs.openjdk.java.net/browse/JDK-8218021 https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/ regards, Sean. [1] http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html From weijun.wang at oracle.com Fri Jun 12 12:37:22 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 12 Jun 2020 20:37:22 +0800 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <5E24D19E-8E5C-4343-AE89-C4D16A471CFA@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> <77CE09E4-0A4F-41D1-A950-9CAF71F2317B@oracle.com> <8C294257-35F0-420A-BC93-A75C017A5C6B@oracle.com> <5E24D19E-8E5C-4343-AE89-C4D16A471CFA@oracle.com> Message-ID: <463191C9-DB2A-4F29-9B49-F2E1A2C88C0E@oracle.com> I re-read the CSR. The precise meaning of the 2 options for -printcert is: "If the cert is a trusted certificate in either keystore or cacerts, we will not warn if it uses a weak signature algorithm". This is so subtle and I wonder it's worth describing it. Or we just say "This command does not check for the weakness of a certificate's signature algorithm if it's a trusted certificate in the user keystore (specified by -keystore) or the `cacerts` keystore (if -trustcacerts is specified)". For -printcrl, the "issuer CA" is a little confusing. I would say "This commands attempts to verify the CRL using a certificate from the user keystore (specified by -keystore) or the `cacerts` keystore (if -trustcacerts is specified), and print out a warning if it cannot be verified". Thanks, Max p.s. A new kind of check comes to my mind. Suppose you are printing a certificate whose own key is 2048-bit RSA, signature is using SHA256withRSA, but the signer key is only 512 bits (we can notice this from the size of the signature). Shall we print out a warning? > On Jun 11, 2020, at 11:21 AM, Weijun Wang wrote: > > "to a self-signed certificate in the keystore". This is not correct. What we look for is a TrustedCertificateEntry. > > "It emits warning when a certificate is not trusted and uses weak algorithms". Precisely, it's "uses a weak signature algorithm". > > --Max > > >> On Jun 10, 2020, at 5:31 PM, Hai-May Chao wrote: >> >> >> >>> On Jun 9, 2020, at 5:58 PM, Weijun Wang wrote: >>> >>> Good to see both -keystore and -trustcacerts mentioned. Some comments: >>> >>> 1. I think there is no need to say "from -file cert_file". Or, do you mean the new function does not apply to those from -sslserver and -jarfile? If so, that might be a problem. >> >> You?re right. Removed it. >> >>> >>> 2. While you said "attempts to construct a chain of trust", do you also want to describe what happens if it succeeds or fails? >> >> Updated manpage. >> >>> >>> 3. It will be nice if you can include the exact diff of the man page files either inside the CSR itself or as a comment. >>> >> >> Included the diff of the manpage in the CSR. >> >> Thanks, >> Hai-May >> >> >>> Thanks, >>> Max >>> >>>> On Jun 9, 2020, at 10:51 PM, Hai-May Chao wrote: >>>> >>>> >>>> >>>>> On Jun 7, 2020, at 6:08 PM, Weijun Wang wrote: >>>>> >>>>> Looks fine to me. >>>>> >>>>> For CSR, since there is already a "Note" there for these 2 options, you can add a few words about what -keystore and -trustcacerts can do. >>>> >>>> Updated CSR as suggested. >>>> >>>> Thanks, >>>> Hai-May >>>> >>>> >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On Jun 8, 2020, at 4:01 AM, Hai-May Chao wrote: >>>>>> >>>>>> Updated webrev - >>>>>> >>>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Hai-May >>>>>> >>>>>> >>>>>>> On Jun 5, 2020, at 11:04 PM, Weijun Wang wrote: >>>>>>> >>>>>>> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. >>>>>>> >>>>>>> Same for line 80 and line 96 of TrustedCRL.java. >>>>>>> >>>>>>> Everything else is fine. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: >>>>>>>> >>>>>>>> Updated webrev - >>>>>>>> >>>>>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>>>>>>> >>>>>>>> Added one command line -importcert in TrustCert.java. >>>>>>>> Added createCacerts() in test/lib SecurityTools.java. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hai-May >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>>>>>>>> >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>>>>>>>> >>>>>>>>>>> The source change looks fine to me. >>>>>>>>>>> >>>>>>>>>>> In TrustedCert.java: >>>>>>>>>>> >>>>>>>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>>>>>>>> >>>>>>>>>> This cat() is taken from WealAlg.java. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - There is no need to recreate root.jks and root.pem. >>>>>>>>>> >>>>>>>>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>>>>>>>> >>>>>>>>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Why not use -trustcacerts below? >>>>>>>>>>> >>>>>>>>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>>>>>>>> >>>>>>>>> OK. >>>>>>>>> >>>>>>>>> Then how about we add a new command before line 155? >>>>>>>>> >>>>>>>>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>>>>>>> >>>>>>>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>>>>>>>> >>>>>>>>>> Ok, will change it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In TrustedCRL.java: >>>>>>>>>>> >>>>>>>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>>>>>>>> >>>>>>>>>> Same reply as above. >>>>>>>>> >>>>>>>>> Same question as above. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>>>>>>>> >>>>>>>>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>>>>>>>> >>>>>>>>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>>>>>>>> >>>>>>>>> I meant creating the cacerts in one method, something like >>>>>>>>> >>>>>>>>> void createCacerts(String ks, String... crt); >>>>>>>>> >>>>>>>>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>>>>>>>> >>>>>>>>> BTW, what does caks.size() == 0 matter here? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Hai-May >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I?d like to request a review for: >>>>>>>>>>>> >>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Hai-May >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sean.mullan at oracle.com Fri Jun 12 16:00:05 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 Jun 2020 12:00:05 -0400 Subject: RFR 8245679: KeyStore cannot probe PKCS12 keystore if BouncyCastle is the top security provider In-Reply-To: References: Message-ID: <080bfd36-e8d5-738b-3bb5-28a889cd18b7@oracle.com> Looks good to me. --Sean On 6/8/20 8:25 AM, Weijun Wang wrote: > Please take a look at > > https://cr.openjdk.java.net/~weijun/8245679/webrev.00/ > > If two providers support the same keystore type, we only try engineProbe() on the 1st one, and fail if it hasn't implemented it. The correct way is to try KeyStoreSpi from all providers. > > I also fixed an error that engineProbe() of both JKS and CaseExactJKS would return true on a JKS keystore, since the method is implemented in their common base class. This means there's a chance that a JKS keystore would be recognized as a CaseExactJKS keystore. This is seen after my code change in KeyStore. > > Thanks, > Max > From lance.andersen at oracle.com Fri Jun 12 16:05:07 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 12 Jun 2020 12:05:07 -0400 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> Message-ID: <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> Hi Sean, I think your changes look fine so all good FMPOV. Best Lance > On Jun 12, 2020, at 6:21 AM, Se?n Coffey wrote: > > Hi, > > I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms > > https://bugs.openjdk.java.net/browse/JDK-8218021 > https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/ > > regards, > Sean. > > [1] http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From xuelei.fan at oracle.com Fri Jun 12 21:43:14 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 12 Jun 2020 14:43:14 -0700 Subject: Request for review, typo in exception message Message-ID: Hi, May I have the following typo correction reviewed in test file? $ hg diff test/jdk/javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java @@ -70,7 +70,7 @@ cliToSrv.put(7, (byte)0x80); // use illegal message length } else { // unlikely - throw new Exception("No handshage message generated."); + throw new Exception("No handshake message generated."); } Thanks, Xuelei From bradford.wetmore at oracle.com Fri Jun 12 22:11:07 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 12 Jun 2020 15:11:07 -0700 Subject: Request for review, typo in exception message In-Reply-To: References: Message-ID: <5a466697-82bc-a238-4de0-7bf34af2d2b5@oracle.com> Approved. :) Or if you want, I could review this much more carefully... Brad On 6/12/2020 2:43 PM, Xuelei Fan wrote: > Hi, > > May I have the following typo correction reviewed in test file? > > $ hg diff test/jdk/javax/net/ssl/SSLEngine/IllegalHandshakeMessage.java > @@ -70,7 +70,7 @@ > ???????????? cliToSrv.put(7, (byte)0x80);??? // use illegal message length > ???????? } else { > ???????????? // unlikely > -??????????? throw new Exception("No handshage message generated."); > +??????????? throw new Exception("No handshake message generated."); > ???????? } > > > Thanks, > Xuelei From hai-may.chao at oracle.com Fri Jun 12 22:34:10 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 12 Jun 2020 15:34:10 -0700 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> Message-ID: <80FFB20F-6714-484D-9C3B-E046CCF3AD09@oracle.com> Hi John, Updated Webrev - https://cr.openjdk.java.net/~hchao/8244148/webrev.03/ > On Jun 11, 2020, at 1:45 AM, sha.jiang at oracle.com wrote: > > Hi Hai-May, > > On 2020/6/8 04:01, Hai-May Chao wrote: >> Updated webrev - >> >> https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ -- src/java.base/share/classes/sun/security/util/FilePaths.java > Would it be better to use String.join() or even java.nio.file.Path to > build the file path? > The current code is based on the original code such as in KeyStoreUtil.java and is consistent with others. > -- src/java.base/share/classes/sun/security/util/AnchorCertificates.java > 55 File f = new File(FilePaths.cacerts()); > ... > 59 try (FileInputStream fis = new FileInputStream(f)) { > f is used only once, so it may be unnecessary. This is the existing code struct which is working fine. > > 56 KeyStore cacerts; > Though it's not in your change, would you mind to declare this variable > in the try block? I just want to narrow the variable scope. Done. > > -- test/lib/jdk/test/lib/SecurityTools.java > Could move method createCacerts() to test/lib/jdk/test/lib/security/KeyStoreUtils.java? > This class contains a set of methods for creating trust/key stores. > And getCertFromFile() in test/lib/jdk/test/lib/security/CertUtils.java > can load certificate from a file. Moved the method createCacerts() to the suggested location under test/. Tried to use getCertFromFile() and it did not work as it read from test.src. So we need to read the cert directly. > > 289 int pos = 0; > ... > 294 for (String crt : crts) { > If not using for-each style, pos can be declared in the for statement. Ok, changed to not using for-each style. > > -- test/jdk/sun/security/tools/keytool/fakecacerts/java.base/sun/security/util/FilePaths.java > This patch can be used by other tests, so could you please move it to a > common path? Like test/jdk/sun/security/util/module_patch/java.base/sun/security/util/FilePaths.java Moved the patch to the suggested location under test/. > > 32 public static String cacerts() { > 33 return "mycacerts"; > 34 } > Could it be flexible for returning an alternative path? > For example, accept a system property, say test.cacerts, for specifying > an alternative path. mycacerts is the default value of this property. Done. Thanks, Hai-May > > Best regards, > John Jiang > >> >> Thanks, >> Hai-May >> >> >>> On Jun 5, 2020, at 11:04 PM, Weijun Wang > wrote: >>> >>> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. >>> >>> Same for line 80 and line 96 of TrustedCRL.java. >>> >>> Everything else is fine. >>> >>> Thanks, >>> Max >>> >>> >>>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao > wrote: >>>> >>>> Updated webrev - >>>> >>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>>> >>>> Added one command line -importcert in TrustCert.java. >>>> Added createCacerts() in test/lib SecurityTools.java. >>>> >>>> Thanks, >>>> Hai-May >>>> >>>> >>>> >>>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>>> >>>>> >>>>> >>>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>>>> >>>>>>> The source change looks fine to me. >>>>>>> >>>>>>> In TrustedCert.java: >>>>>>> >>>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>>>> >>>>>> This cat() is taken from WealAlg.java. >>>>>> >>>>>>> >>>>>>> - There is no need to recreate root.jks and root.pem. >>>>>> >>>>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>>>> >>>>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>>>> >>>>>> >>>>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>>>> >>>>>>> >>>>>>> - Why not use -trustcacerts below? >>>>>>> >>>>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>>>> >>>>>> >>>>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>>>> >>>>> OK. >>>>> >>>>> Then how about we add a new command before line 155? >>>>> >>>>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>>> >>>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>>> >>>>>> >>>>>>> >>>>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>>>> >>>>>> Ok, will change it. >>>>>> >>>>>>> >>>>>>> In TrustedCRL.java: >>>>>>> >>>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>>>> >>>>>> Same reply as above. >>>>> >>>>> Same question as above. >>>>> >>>>>> >>>>>>> >>>>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>>>> >>>>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>>>> >>>>>>> >>>>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>>>> >>>>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>>>> >>>>> I meant creating the cacerts in one method, something like >>>>> >>>>> void createCacerts(String ks, String... crt); >>>>> >>>>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>>>> >>>>> BTW, what does caks.size() == 0 matter here? >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Hai-May >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> >>>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I?d like to request a review for: >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>>> >>>>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hai-May >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hai-may.chao at oracle.com Fri Jun 12 23:09:51 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 12 Jun 2020 16:09:51 -0700 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <463191C9-DB2A-4F29-9B49-F2E1A2C88C0E@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> <77CE09E4-0A4F-41D1-A950-9CAF71F2317B@oracle.com> <8C294257-35F0-420A-BC93-A75C017A5C6B@oracle.com> <5E24D19E-8E5C-4343-AE89-C4D16A471CFA@oracle.com> <463191C9-DB2A-4F29-9B49-F2E1A2C88C0E@oracle.com> Message-ID: <4E7CECEE-7C1A-4D95-A13D-C9CD6C5749B9@oracle.com> > On Jun 12, 2020, at 5:37 AM, Weijun Wang wrote: > > I re-read the CSR. > > The precise meaning of the 2 options for -printcert is: "If the cert is a trusted certificate in either keystore or cacerts, we will not warn if it uses a weak signature algorithm". This is so subtle and I wonder it's worth describing it. Or we just say "This command does not check for the weakness of a certificate's signature algorithm if it's a trusted certificate in the user keystore (specified by -keystore) or the `cacerts` keystore (if -trustcacerts is specified)?. Updated CSR with the second mentioned. > > For -printcrl, the "issuer CA" is a little confusing. I would say "This commands attempts to verify the CRL using a certificate from the user keystore (specified by -keystore) or the `cacerts` keystore (if -trustcacerts is specified), and print out a warning if it cannot be verified?. CRL issuer is usually the CA, and the implementation of -printcrl tries to get its issuer from the user or cacerts keystore. Updated CSR as suggested as if there may be confusing. Thanks, Hai-May > > Thanks, > Max > > p.s. A new kind of check comes to my mind. Suppose you are printing a certificate whose own key is 2048-bit RSA, signature is using SHA256withRSA, but the signer key is only 512 bits (we can notice this from the size of the signature). Shall we print out a warning? Your thought? > >> On Jun 11, 2020, at 11:21 AM, Weijun Wang wrote: >> >> "to a self-signed certificate in the keystore". This is not correct. What we look for is a TrustedCertificateEntry. >> >> "It emits warning when a certificate is not trusted and uses weak algorithms". Precisely, it's "uses a weak signature algorithm". >> >> --Max >> >> >>> On Jun 10, 2020, at 5:31 PM, Hai-May Chao wrote: >>> >>> >>> >>>> On Jun 9, 2020, at 5:58 PM, Weijun Wang wrote: >>>> >>>> Good to see both -keystore and -trustcacerts mentioned. Some comments: >>>> >>>> 1. I think there is no need to say "from -file cert_file". Or, do you mean the new function does not apply to those from -sslserver and -jarfile? If so, that might be a problem. >>> >>> You?re right. Removed it. >>> >>>> >>>> 2. While you said "attempts to construct a chain of trust", do you also want to describe what happens if it succeeds or fails? >>> >>> Updated manpage. >>> >>>> >>>> 3. It will be nice if you can include the exact diff of the man page files either inside the CSR itself or as a comment. >>>> >>> >>> Included the diff of the manpage in the CSR. >>> >>> Thanks, >>> Hai-May >>> >>> >>>> Thanks, >>>> Max >>>> >>>>> On Jun 9, 2020, at 10:51 PM, Hai-May Chao wrote: >>>>> >>>>> >>>>> >>>>>> On Jun 7, 2020, at 6:08 PM, Weijun Wang wrote: >>>>>> >>>>>> Looks fine to me. >>>>>> >>>>>> For CSR, since there is already a "Note" there for these 2 options, you can add a few words about what -keystore and -trustcacerts can do. >>>>> >>>>> Updated CSR as suggested. >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>>> On Jun 8, 2020, at 4:01 AM, Hai-May Chao wrote: >>>>>>> >>>>>>> Updated webrev - >>>>>>> >>>>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ >>>>>>> >>>>>>> Thanks, >>>>>>> Hai-May >>>>>>> >>>>>>> >>>>>>>> On Jun 5, 2020, at 11:04 PM, Weijun Wang wrote: >>>>>>>> >>>>>>>> I still think duplicated commands in TrustedCert.java are useless. Line 104 and line 133 are exactly the same, line 109 and line 138 are exactly the same, and you haven't made any change to these 2 files in between. >>>>>>>> >>>>>>>> Same for line 80 and line 96 of TrustedCRL.java. >>>>>>>> >>>>>>>> Everything else is fine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao wrote: >>>>>>>>> >>>>>>>>> Updated webrev - >>>>>>>>> >>>>>>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>>>>>>>> >>>>>>>>> Added one command line -importcert in TrustCert.java. >>>>>>>>> Added createCacerts() in test/lib SecurityTools.java. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Hai-May >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang wrote: >>>>>>>>>>>> >>>>>>>>>>>> The source change looks fine to me. >>>>>>>>>>>> >>>>>>>>>>>> In TrustedCert.java: >>>>>>>>>>>> >>>>>>>>>>>> - You can use FileOutputStream and Files.copy(Path,OutputStream) in cat(). >>>>>>>>>>> >>>>>>>>>>> This cat() is taken from WealAlg.java. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - There is no need to recreate root.jks and root.pem. >>>>>>>>>>> >>>>>>>>>>> The sequences of the commands used in this test scenario allows me to test -printcert for the -trustcacerts and -keytsore options. We had discussion offline about it. The test uses trusted certificates and checks no warnings on the weak algorithms to address the requirement described in the bug. I believe it does serve that purpose, and looks legitimate to me. There could be different ways of testing a functionality, and please let me know if there is a problem with the current approach. >>>>>>>>>> >>>>>>>>>> I just meant that the keytool commands generating root.jks and root.pem are exactly the same and there is no need to recreate it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please also elaborate your comment about no need to recreate root.jks and root.pem. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - Why not use -trustcacerts below? >>>>>>>>>>>> >>>>>>>>>>>> 160 kt("-importcert -file server.pem -noprompt", "server.jks?); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Because here is to import the server (end-entity) cert, and it will not make a difference for the test result whether to use the -trustcacerts or not. It?s the ca (intermediate) cert needs to have it in this test scenario. I intended to leave it out in #160 to distinguish between server and ca certs. >>>>>>>>>> >>>>>>>>>> OK. >>>>>>>>>> >>>>>>>>>> Then how about we add a new command before line 155? >>>>>>>>>> >>>>>>>>>> kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>>>>>>>> >>>>>>>>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - It's probably better to add a " " between cmd and options in patchcmd(). Same in TrustedCRL.java. >>>>>>>>>>> >>>>>>>>>>> Ok, will change it. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> In TrustedCRL.java: >>>>>>>>>>>> >>>>>>>>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with different options. >>>>>>>>>>> >>>>>>>>>>> Same reply as above. >>>>>>>>>> >>>>>>>>>> Same question as above. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - Why create using MD5withRSA? Do you meant to warn about the weak algorithm? >>>>>>>>>>> >>>>>>>>>>> Yes, exactly, and it differentiates from the weak algorithm SHA1withRSA used in root CA where no warning will be emitted. There is another -gencrl in #119 without using MD5withRSA so I?d have two test cases. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Also I would suggest you create a dedicate method (maybe in SecurityTools.java) to create your own cacerts. There is no need to copy over the system cacerts, just make sure the file is created with the JKS storetype. We are thinking of upgrading the storetype of cacerts and it's nice to do this at a single place so we can modify it easily later. >>>>>>>>>>> >>>>>>>>>>> I created a method in SecurityTools.java to create the own cacerts. With this keystore, the subsequent importing a certificate reply would not work. It turns out that its caks.size() is zero detected at establishCertChain() in keytool/Main.java after root cert has been imported to that cacerts. At this point I?d like to suggest a separate bug be filed to cover the cacerts enhancement that you suggested. >>>>>>>>>> >>>>>>>>>> I meant creating the cacerts in one method, something like >>>>>>>>>> >>>>>>>>>> void createCacerts(String ks, String... crt); >>>>>>>>>> >>>>>>>>>> and you can call createCacerts("mycacerts", "root.crt") to create it. The method can call KeyStore APIs and not keytool commands. >>>>>>>>>> >>>>>>>>>> BTW, what does caks.size() == 0 matter here? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Hai-May >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I?d like to request a review for: >>>>>>>>>>>>> >>>>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> The change is to add the support of -trustcacerts and -keystore options to -printcert and -princrl command for keytool. This enables keytool to use the trusted certificates when verifying untrusted artifacts that are signed by CAs. It also incorporates Max?s change that consolidates the code to get the default location of cacerts keystore. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Hai-May >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sha.jiang at oracle.com Sat Jun 13 01:22:01 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Sat, 13 Jun 2020 09:22:01 +0800 Subject: RFR 8244148: keytool -printcert and -printcrl should support the -trustcacerts and -keystore options In-Reply-To: <80FFB20F-6714-484D-9C3B-E046CCF3AD09@oracle.com> References: <426A5985-90C9-48D4-A1FD-0A23A60CC618@oracle.com> <6FB9D0B7-BB1D-4424-AB7A-32EB2B836731@oracle.com> <9CC203F4-6939-401D-B681-C51AB32ABF73@oracle.com> <24EF91BD-6D35-4CEB-AFE8-FF56E1A9D76B@oracle.com> <8786A3F4-A140-4FCC-A6AB-6EAB5788859D@oracle.com> <80FFB20F-6714-484D-9C3B-E046CCF3AD09@oracle.com> Message-ID: Hi Hai-May, On 2020/6/13 06:34, Hai-May Chao wrote: > Hi John, > > Updated Webrev - > https://cr.openjdk.java.net/~hchao/8244148/webrev.03/ Thanks for this updated webrev! I have no more comment. Best regards, John Jiang > >> On Jun 11, 2020, at 1:45 AM, sha.jiang at oracle.com >> wrote: >> >> Hi Hai-May, >> >> On 2020/6/8 04:01, Hai-May Chao wrote: >>> Updated webrev - >>> >>> https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ >> -- src/java.base/share/classes/sun/security/util/FilePaths.java >> Would it be better to use String.join() or even java.nio.file.Path to >> build the file path? >> > > The current code is based on the original code such as in > KeyStoreUtil.java and is consistent with others. > >> -- src/java.base/share/classes/sun/security/util/AnchorCertificates.java >> 55???????????????? File f = new File(FilePaths.cacerts()); >> ... >> 59???????????????????? try (FileInputStream fis = new >> FileInputStream(f)) { >> f is used only once, so it may be unnecessary. > > This is the existing code struct which is working fine. > >> >> 56???????????????? KeyStore cacerts; >> Though it's not in your change, would you mind to declare this variable >> in the try block? I just want to narrow the variable scope. > > Done. > >> >> -- test/lib/jdk/test/lib/SecurityTools.java >> Could move method createCacerts() to >> test/lib/jdk/test/lib/security/KeyStoreUtils.java? >> This class contains a set of methods for creating trust/key stores. >> And getCertFromFile() in test/lib/jdk/test/lib/security/CertUtils.java >> can load certificate from a file. > > Moved the method createCacerts() to the suggested location under test/. > Tried to use getCertFromFile() and it did not work as it read from > test.src. So we need to read the cert directly. > >> >> 289???????? int pos = 0; >> ... >> 294???????????? for (String crt : crts) { >> If not using for-each style, pos can be declared in the for statement. > > Ok, changed to not using for-each style. > >> >> -- >> test/jdk/sun/security/tools/keytool/fakecacerts/java.base/sun/security/util/FilePaths.java >> This patch can be used by other tests, so could you please move it to a >> common path? Like >> test/jdk/sun/security/util/module_patch/java.base/sun/security/util/FilePaths.java > > Moved the patch to the suggested location under test/. > >> >> 32???? public static String cacerts() { >> 33???????? return "mycacerts"; >> 34???? } >> Could it be flexible for returning an alternative path? >> For example, accept a system property, say test.cacerts, for specifying >> an alternative path. mycacerts is the default value of this property. > > Done. > > Thanks, > Hai-May > > >> >> Best regards, >> John Jiang >> >>> >>> Thanks, >>> Hai-May >>> >>> >>>> On Jun 5, 2020, at 11:04 PM, Weijun Wang >>> > wrote: >>>> >>>> I still think duplicated commands in TrustedCert.java are useless. >>>> Line 104 and line 133 are exactly the same, line 109 and line 138 >>>> are exactly the same, and you haven't made any change to these 2 >>>> files in between. >>>> >>>> Same for line 80 and line 96 of TrustedCRL.java. >>>> >>>> Everything else is fine. >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> On Jun 6, 2020, at 2:25 AM, Hai-May Chao >>>> > wrote: >>>>> >>>>> Updated webrev - >>>>> >>>>> https://cr.openjdk.java.net/~hchao/8244148/webrev.01/ >>>>> >>>>> Added one command line -importcert in TrustCert.java. >>>>> Added createCacerts() in test/lib SecurityTools.java. >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>> >>>>> >>>>>> On Jun 4, 2020, at 5:57 AM, Weijun Wang >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 4, 2020, at 7:29 PM, Hai-May Chao >>>>>>> wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>>> On Jun 3, 2020, at 12:59 AM, Weijun Wang >>>>>>>> wrote: >>>>>>>> >>>>>>>> The source change looks fine to me. >>>>>>>> >>>>>>>> In TrustedCert.java: >>>>>>>> >>>>>>>> - You can use FileOutputStream and >>>>>>>> Files.copy(Path,OutputStream) in cat(). >>>>>>> >>>>>>> This cat() is taken from WealAlg.java. >>>>>>> >>>>>>>> >>>>>>>> - There is no need to recreate root.jks and root.pem. >>>>>>> >>>>>>> The sequences of the commands used in this test scenario allows >>>>>>> me to test -printcert for the -trustcacerts and -keytsore >>>>>>> options. We had discussion offline about it. The test uses >>>>>>> trusted certificates and checks no warnings on the weak >>>>>>> algorithms to address the requirement described in the bug. I >>>>>>> believe it does serve that purpose, and looks legitimate to me. >>>>>>> There could be different ways of testing a functionality, and >>>>>>> please let me know if there is a problem with the current approach. >>>>>> >>>>>> I just meant that the keytool commands generating root.jks and >>>>>> root.pem are exactly the same and there is no need to recreate it. >>>>>> >>>>>>> >>>>>>> Please also elaborate your comment about no need to recreate >>>>>>> root.jks and root.pem. >>>>>>> >>>>>>>> >>>>>>>> - Why not use -trustcacerts below? >>>>>>>> >>>>>>>> 160 ????????kt("-importcert -file server.pem -noprompt", >>>>>>>> "server.jks?); >>>>>>> >>>>>>> >>>>>>> Because here is to import the server (end-entity) cert, and it >>>>>>> will not make a difference for the test result whether to use >>>>>>> the -trustcacerts or not. It?s the ca (intermediate) cert needs >>>>>>> to have it in this test scenario. I intended to leave it out in >>>>>>> #160 to distinguish between server and ca certs. >>>>>> >>>>>> OK. >>>>>> >>>>>> Then how about we add a new command before line 155? >>>>>> >>>>>> ??kt("-importcert -file ca.pem", "ca.jks").shouldNotHaveExitValue(0); >>>>>> >>>>>> This would prove the "-trustcacerts" on line 155 is really useful. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> - It's probably better to add a " " between cmd and options in >>>>>>>> patchcmd(). Same in TrustedCRL.java. >>>>>>> >>>>>>> Ok, will change it. >>>>>>> >>>>>>>> >>>>>>>> In TrustedCRL.java: >>>>>>>> >>>>>>>> - No need to recreate ks and ca.crl. Just call "-printcrl" with >>>>>>>> different options. >>>>>>> >>>>>>> Same reply as above. >>>>>> >>>>>> Same question as above. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> - Why create using MD5withRSA? Do you meant to warn about the >>>>>>>> weak algorithm? >>>>>>> >>>>>>> Yes, exactly, and it differentiates from the weak algorithm >>>>>>> SHA1withRSA used in root CA where no warning will be emitted. >>>>>>> There is another -gencrl in #119 without using MD5withRSA so I?d >>>>>>> have two test cases. >>>>>>> >>>>>>>> >>>>>>>> Also I would suggest you create a dedicate method (maybe in >>>>>>>> SecurityTools.java) to create your own cacerts. There is no >>>>>>>> need to copy over the system cacerts, just make sure the file >>>>>>>> is created with the JKS storetype. We are thinking of upgrading >>>>>>>> the storetype of cacerts and it's nice to do this at a single >>>>>>>> place so we can modify it easily later. >>>>>>> >>>>>>> I created a method in SecurityTools.java to create the own >>>>>>> cacerts. With this keystore, the subsequent importing a >>>>>>> certificate reply would not work. It turns out that its >>>>>>> caks.size() is zero detected at establishCertChain() in >>>>>>> keytool/Main.java after root cert has been imported to that >>>>>>> cacerts. At this point I?d like to suggest a separate bug be >>>>>>> filed to cover the cacerts enhancement that you suggested. >>>>>> >>>>>> I meant creating the cacerts in one method, something like >>>>>> >>>>>> ?void createCacerts(String ks, String... crt); >>>>>> >>>>>> and you can call createCacerts("mycacerts", "root.crt") to create >>>>>> it. The method can call KeyStore APIs and not keytool commands. >>>>>> >>>>>> BTW, what does caks.size() == 0 matter here? >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Hai-May >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>>> On Jun 2, 2020, at 2:37 AM, Hai-May Chao >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I?d like to request a review for: >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244148 >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8246269 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~hchao/8244148/webrev.00/ >>>>>>>>> >>>>>>>>> The change is to add the support of -trustcacerts and >>>>>>>>> -keystore options to -printcert and -princrl command for >>>>>>>>> keytool. This enables keytool to use the trusted certificates >>>>>>>>> when verifying untrusted artifacts that are signed by CAs. It >>>>>>>>> also incorporates Max?s change that consolidates the code to >>>>>>>>> get the default location of cacerts keystore. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Hai-May >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sun Jun 14 09:21:38 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 14 Jun 2020 17:21:38 +0800 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <7a49f7de-5165-43c1-d62b-7f9389f8a9d9@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> <7a49f7de-5165-43c1-d62b-7f9389f8a9d9@oracle.com> Message-ID: Looks fine to me. Maybe you can also use "if (this instanceof Cloneable)" in Signature$Delegate::clone. Thanks, Max > On Jun 11, 2020, at 3:45 AM, Valerie Peng wrote: > > Webrev updated at: http://cr.openjdk.java.net/~valeriep/8246077/webrev.01/ > > Key changes in this revision are in the Delegate.of() method in java.security.MessageDigest class. > > Comments? > > Thanks, > Valerie > On 6/8/2020 1:42 PM, Valerie Peng wrote: >> "md instanceof Cloneable && md is not from PKCS11" is not entirely precise. What I mean is that for MessageDigestSpi impls from PKCS11 provider, we will need to call the clone() to know for sure whether cloning is supported. If we decide to employ these extra logic for saving clone() call, it's better to do it inside the MessageDigest.of(...) so the callers don't have to repeat the same logic. Comments? >> >> Valerie >> >> On 6/8/2020 1:34 PM, Valerie Peng wrote: >>> Hmm, I checked all MessageDigestSpi impls of JDK providers... The story is more complicated than we expect. >>> >>> For SUN provider which implement the digest spi, implementing Cloneable means it supports clone functionality. >>> >>> However, for SunPKCS11 provider which wraps native PKCS11 library, it always implements Cloneable interface, but when clone() is called, it will then perform the equivalent PKCS11 calls and throw CNSE if any PKCS11 error is observed. >>> >>> So, there is a possibility that the instanceof check and the clone() check leads to different result in this particular scenario. >>> >>> The chance of 3rd non-PKCS11 party provider whose MessageDigest/MessageDigestSpi impl implements Cloneable but throws CNSE when clone() is called should be very low? So, I think it should be sufficient to use "md instanceof Cloneable && md is not from PKCS11"? >>> >>> Valerie >>> >>> On 6/6/2020 9:10 AM, Xuelei Fan wrote: >>>> As the the Delegate class takes care of the Cloneable SPI implementation, it should be sufficient to use "md instanceof Cloneable" only. It is not a expected behavior that a provider implements Cloneable but does not really support it. >>>> >>>> Xuelei >>>> >>>> On 6/5/2020 10:54 PM, Weijun Wang wrote: >>>>> Is it possible to try "md instanceof Cloneable || md.clone() returns"? Hopefully this is fast enough in most cases and also has the chance to recognize more actually-cloneable ones. >>>>> >>>>> I'm also OK with simply using "md instanceof Cloneable". >>>>> >>>>> --Max >>>>> >>>>>> On Jun 6, 2020, at 12:02 PM, Valerie Peng wrote: >>>>>> >>>>>> >>>>>> I am merely following the spec's recommendation of trying the clone() for cloneability check. >>>>>> >>>>>> If you both are ok with it and prefer the instanceof check, I can sure reverting back the changes in HmacCore and HandshakeHash classes. >>>>>> >>>>>> Valerie >>>>>> >>>>>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>>>>> I share the same concern. clone() is a heavy weight operation in constructors that can be called alot during intensive crypto operations. >>>>>>> >>>>>>> Now that you've done work on Delegate class - why not also keep the (instanceof Cloneable) test ? That can serve as your fastpath for the default JDK configuration AFAIK. >>>>>>> >>>>>>> regards, >>>>>>> Sean. >>>>>>> >>>>>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>>>>> >>>>>>>>> ? 2020?6?5??03:19?Valerie Peng ??? >>>>>>>>> >>>>>>>>>> Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? >>>>>>>>> Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? >>>>>>>> No. >>>>>>>> >>>>>>>> I understand this case, but this has already been fixed. Is there any other example? Or are you only follow the words in the spec? i.e. try clone() to see if it?s cloneable. >>>>>>>> >>>>>>>> I am worried that try clone() is much heavier than just check instanof Cloneable. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>> From valerie.peng at oracle.com Mon Jun 15 19:59:04 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 15 Jun 2020 12:59:04 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> <7a49f7de-5165-43c1-d62b-7f9389f8a9d9@oracle.com> Message-ID: <0b6984b2-868f-0fa2-29ff-62d281e5f4d2@oracle.com> Sure, sounds good. Webrev is updated in place at webrev.01 since the change is just one-line. Will proceed with integration once the mach5 tests finish. Thanks! Valerie On 6/14/2020 2:21 AM, Weijun Wang wrote: > Looks fine to me. Maybe you can also use "if (this instanceof Cloneable)" in Signature$Delegate::clone. > > Thanks, > Max > >> On Jun 11, 2020, at 3:45 AM, Valerie Peng wrote: >> >> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8246077/webrev.01/ >> >> Key changes in this revision are in the Delegate.of() method in java.security.MessageDigest class. >> >> Comments? >> >> Thanks, >> Valerie >> On 6/8/2020 1:42 PM, Valerie Peng wrote: >>> "md instanceof Cloneable && md is not from PKCS11" is not entirely precise. What I mean is that for MessageDigestSpi impls from PKCS11 provider, we will need to call the clone() to know for sure whether cloning is supported. If we decide to employ these extra logic for saving clone() call, it's better to do it inside the MessageDigest.of(...) so the callers don't have to repeat the same logic. Comments? >>> >>> Valerie >>> >>> On 6/8/2020 1:34 PM, Valerie Peng wrote: >>>> Hmm, I checked all MessageDigestSpi impls of JDK providers... The story is more complicated than we expect. >>>> >>>> For SUN provider which implement the digest spi, implementing Cloneable means it supports clone functionality. >>>> >>>> However, for SunPKCS11 provider which wraps native PKCS11 library, it always implements Cloneable interface, but when clone() is called, it will then perform the equivalent PKCS11 calls and throw CNSE if any PKCS11 error is observed. >>>> >>>> So, there is a possibility that the instanceof check and the clone() check leads to different result in this particular scenario. >>>> >>>> The chance of 3rd non-PKCS11 party provider whose MessageDigest/MessageDigestSpi impl implements Cloneable but throws CNSE when clone() is called should be very low? So, I think it should be sufficient to use "md instanceof Cloneable && md is not from PKCS11"? >>>> >>>> Valerie >>>> >>>> On 6/6/2020 9:10 AM, Xuelei Fan wrote: >>>>> As the the Delegate class takes care of the Cloneable SPI implementation, it should be sufficient to use "md instanceof Cloneable" only. It is not a expected behavior that a provider implements Cloneable but does not really support it. >>>>> >>>>> Xuelei >>>>> >>>>> On 6/5/2020 10:54 PM, Weijun Wang wrote: >>>>>> Is it possible to try "md instanceof Cloneable || md.clone() returns"? Hopefully this is fast enough in most cases and also has the chance to recognize more actually-cloneable ones. >>>>>> >>>>>> I'm also OK with simply using "md instanceof Cloneable". >>>>>> >>>>>> --Max >>>>>> >>>>>>> On Jun 6, 2020, at 12:02 PM, Valerie Peng wrote: >>>>>>> >>>>>>> >>>>>>> I am merely following the spec's recommendation of trying the clone() for cloneability check. >>>>>>> >>>>>>> If you both are ok with it and prefer the instanceof check, I can sure reverting back the changes in HmacCore and HandshakeHash classes. >>>>>>> >>>>>>> Valerie >>>>>>> >>>>>>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>>>>>> I share the same concern. clone() is a heavy weight operation in constructors that can be called alot during intensive crypto operations. >>>>>>>> >>>>>>>> Now that you've done work on Delegate class - why not also keep the (instanceof Cloneable) test ? That can serve as your fastpath for the default JDK configuration AFAIK. >>>>>>>> >>>>>>>> regards, >>>>>>>> Sean. >>>>>>>> >>>>>>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>>>>>>> ? 2020?6?5??03:19?Valerie Peng ??? >>>>>>>>>> >>>>>>>>>>> Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? >>>>>>>>>> Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? >>>>>>>>> No. >>>>>>>>> >>>>>>>>> I understand this case, but this has already been fixed. Is there any other example? Or are you only follow the words in the spec? i.e. try clone() to see if it?s cloneable. >>>>>>>>> >>>>>>>>> I am worried that try clone() is much heavier than just check instanof Cloneable. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max From valerie.peng at oracle.com Mon Jun 15 23:29:02 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 15 Jun 2020 16:29:02 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <0b6984b2-868f-0fa2-29ff-62d281e5f4d2@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> <7a49f7de-5165-43c1-d62b-7f9389f8a9d9@oracle.com> <0b6984b2-868f-0fa2-29ff-62d281e5f4d2@oracle.com> Message-ID: <1c7380a9-af6a-23f6-5a2a-ab969ad62835@oracle.com> Hmm, on a second thought, I reverted back on this last suggestion. Signature class has this delayed provider selection mechanism, so the clone() method should always rely on the chosen signatureSpi obj. Thanks, Valerie On 6/15/2020 12:59 PM, Valerie Peng wrote: > Sure, sounds good. Webrev is updated in place at webrev.01 since the > change is just one-line. > > Will proceed with integration once the mach5 tests finish. > > Thanks! > Valerie > On 6/14/2020 2:21 AM, Weijun Wang wrote: >> Looks fine to me. Maybe you can also use "if (this instanceof >> Cloneable)" in Signature$Delegate::clone. >> >> Thanks, >> Max >> >>> On Jun 11, 2020, at 3:45 AM, Valerie Peng >>> wrote: >>> >>> Webrev updated at: >>> http://cr.openjdk.java.net/~valeriep/8246077/webrev.01/ >>> >>> Key changes in this revision are in the Delegate.of() method in >>> java.security.MessageDigest class. >>> >>> Comments? >>> >>> Thanks, >>> Valerie >>> On 6/8/2020 1:42 PM, Valerie Peng wrote: >>>> "md instanceof Cloneable && md is not from PKCS11" is not entirely >>>> precise. What I mean is that for MessageDigestSpi impls from PKCS11 >>>> provider, we will need to call the clone() to know for sure whether >>>> cloning is supported. If we decide to employ these extra logic for >>>> saving clone() call, it's better to do it inside the >>>> MessageDigest.of(...) so the callers don't have to repeat the same >>>> logic. Comments? >>>> >>>> Valerie >>>> >>>> On 6/8/2020 1:34 PM, Valerie Peng wrote: >>>>> Hmm, I checked all MessageDigestSpi impls of JDK providers... The >>>>> story is more complicated than we expect. >>>>> >>>>> For SUN provider which implement the digest spi, implementing >>>>> Cloneable means it supports clone functionality. >>>>> >>>>> However, for SunPKCS11 provider which wraps native PKCS11 library, >>>>> it always implements Cloneable interface, but when clone() is >>>>> called, it will then perform the equivalent PKCS11 calls and throw >>>>> CNSE if any PKCS11 error is observed. >>>>> >>>>> So, there is a possibility that the instanceof check and the >>>>> clone() check leads to different result in this particular scenario. >>>>> >>>>> The chance of 3rd non-PKCS11 party provider whose >>>>> MessageDigest/MessageDigestSpi impl implements Cloneable but >>>>> throws CNSE when clone() is called should be very low? So, I think >>>>> it should be sufficient to use "md instanceof Cloneable && md is >>>>> not from PKCS11"? >>>>> >>>>> Valerie >>>>> >>>>> On 6/6/2020 9:10 AM, Xuelei Fan wrote: >>>>>> As the the Delegate class takes care of the Cloneable SPI >>>>>> implementation, it should be sufficient to use "md instanceof >>>>>> Cloneable" only.? It is not a expected behavior that a provider >>>>>> implements Cloneable but does not really support it. >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 6/5/2020 10:54 PM, Weijun Wang wrote: >>>>>>> Is it possible to try "md instanceof Cloneable || md.clone() >>>>>>> returns"? Hopefully this is fast enough in most cases and also >>>>>>> has the chance to recognize more actually-cloneable ones. >>>>>>> >>>>>>> I'm also OK with simply using "md instanceof Cloneable". >>>>>>> >>>>>>> --Max >>>>>>> >>>>>>>> On Jun 6, 2020, at 12:02 PM, Valerie Peng >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> I am merely following the spec's recommendation of trying the >>>>>>>> clone() for cloneability check. >>>>>>>> >>>>>>>> If you both are ok with it and prefer the instanceof check, I >>>>>>>> can sure reverting back the changes in HmacCore and >>>>>>>> HandshakeHash classes. >>>>>>>> >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>>>>>>> I share the same concern. clone() is a heavy weight operation >>>>>>>>> in constructors that can be called alot during intensive >>>>>>>>> crypto operations. >>>>>>>>> >>>>>>>>> Now that you've done work on Delegate class - why not also >>>>>>>>> keep the (instanceof Cloneable) test ? That can serve as your >>>>>>>>> fastpath for the default JDK configuration AFAIK. >>>>>>>>> >>>>>>>>> regards, >>>>>>>>> Sean. >>>>>>>>> >>>>>>>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>>>>>>>> ? 2020?6?5??03:19?Valerie Peng >>>>>>>>>>> ??? >>>>>>>>>>> >>>>>>>>>>>> Can you give an example when these 2 rules have different >>>>>>>>>>>> results? Is this only true for those implementation that >>>>>>>>>>>> directly subclass MessageDigest? >>>>>>>>>>> Before this fix, even the Spi impl implements Cloneable the >>>>>>>>>>> instanceof check will always fail because the wrapper class, >>>>>>>>>>> i.e. MessageDigest.Delegate does not. However, if you call >>>>>>>>>>> the clone() (made public by the MessageDigest class), it >>>>>>>>>>> will succeed because Delegate.clone() checks to see if the >>>>>>>>>>> spi object implements the Cloneable interface, if yes, it >>>>>>>>>>> will proceed to call the spi clone(). So, for this scenario, >>>>>>>>>>> the results are different, e.g. instanceof returns false, >>>>>>>>>>> but clone() succeeds. This is just one example. Is this what >>>>>>>>>>> you are asking? >>>>>>>>>> No. >>>>>>>>>> >>>>>>>>>> I understand this case, but this has already been fixed. Is >>>>>>>>>> there any other example? Or are you only follow the words in >>>>>>>>>> the spec? i.e. try clone() to see if it?s cloneable. >>>>>>>>>> >>>>>>>>>> I am worried that try clone() is much heavier than just check >>>>>>>>>> instanof Cloneable. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max From anthony.scarpino at oracle.com Tue Jun 16 00:42:32 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jun 2020 17:42:32 -0700 Subject: [RFR] 8229148: SSLSession.invalidate() does not invalidate stateless tickets In-Reply-To: <4395fdcf-b7cf-9943-9896-feed43196b8a@oracle.com> References: <4395fdcf-b7cf-9943-9896-feed43196b8a@oracle.com> Message-ID: <46734043-e6aa-dcb7-a652-34ada619d4fb@oracle.com> The specifications for TLS 1.3 (RFC 8446) and Stateless Resumption for TLS 1.2 (RFC 5077) does not define session invalidation. Additionally, RFC 5077 provides research that it is unnecessary. This change is to clarify that session invalidation method in the Java API, in javax.net.ssl.SSLSession.invalidate(), may not be supported in some circumstances. The CSR is: https://bugs.openjdk.java.net/browse/JDK-8243678 The webrev is inline: src/java.base/share/classes/javax/net/ssl/SSLSession.java @@ -129,6 +129,12 @@ * using this session can continue to use the session until the * connection is closed. * + * @apiNote + * This operation is optional as the implementation may not support + * session invalidation. This could occur with implementations of + * Stateless Resumption (RFC 5077) and/or TLS 1.3 (RFC 8446) which + * do not specify session invalidation. + * * @see #isValid() */ public void invalidate(); From xuelei.fan at oracle.com Tue Jun 16 00:54:28 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 15 Jun 2020 17:54:28 -0700 Subject: [RFR] 8229148: SSLSession.invalidate() does not invalidate stateless tickets In-Reply-To: <46734043-e6aa-dcb7-a652-34ada619d4fb@oracle.com> References: <4395fdcf-b7cf-9943-9896-feed43196b8a@oracle.com> <46734043-e6aa-dcb7-a652-34ada619d4fb@oracle.com> Message-ID: I added myself as reviewer of the CSR. Xuelei On 6/15/2020 5:42 PM, Anthony Scarpino wrote: > The specifications for TLS 1.3 (RFC 8446) and Stateless Resumption for > TLS 1.2 (RFC 5077) does not define session invalidation. Additionally, > RFC 5077 provides research that it is unnecessary. This change is to > clarify that session invalidation method in the Java API, in > javax.net.ssl.SSLSession.invalidate(), may not be supported in some > circumstances. > > The CSR is: https://bugs.openjdk.java.net/browse/JDK-8243678 > The webrev is inline: > > src/java.base/share/classes/javax/net/ssl/SSLSession.java > @@ -129,6 +129,12 @@ > ????? * using this session can continue to use the session until the > ????? * connection is closed. > ????? * > +???? * @apiNote > +???? * This operation is optional as the implementation may not support > +???? * session invalidation.? This could occur with implementations of > +???? * Stateless Resumption (RFC 5077) and/or TLS 1.3 (RFC 8446) which > +???? * do not specify session invalidation. > +???? * > ????? * @see #isValid() > ????? */ > ???? public void invalidate(); From weijun.wang at oracle.com Tue Jun 16 01:18:01 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Jun 2020 09:18:01 +0800 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <1c7380a9-af6a-23f6-5a2a-ab969ad62835@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> <7a49f7de-5165-43c1-d62b-7f9389f8a9d9@oracle.com> <0b6984b2-868f-0fa2-29ff-62d281e5f4d2@oracle.com> <1c7380a9-af6a-23f6-5a2a-ab969ad62835@oracle.com> Message-ID: <04515356-4ED9-4BDE-9887-44CE501C784C@oracle.com> Ah yes, you're correct. But because of this delayed selection, the existence of CloneableDelegate is not that useful unless user has specified a provider at the beginning. At first every Signature is a Delegate and thus not a Cloneable, you would have to clone it to make it Cloneable. I noticed none of our impls are Cloneable (or did I miss one?). What is the motivation to update Signature in this code change? Thanks, Max > On Jun 16, 2020, at 7:29 AM, Valerie Peng wrote: > > Hmm, on a second thought, I reverted back on this last suggestion. Signature class has this delayed provider selection mechanism, so the clone() method should always rely on the chosen signatureSpi obj. > > Thanks, > Valerie > On 6/15/2020 12:59 PM, Valerie Peng wrote: >> Sure, sounds good. Webrev is updated in place at webrev.01 since the change is just one-line. >> >> Will proceed with integration once the mach5 tests finish. >> >> Thanks! >> Valerie >> On 6/14/2020 2:21 AM, Weijun Wang wrote: >>> Looks fine to me. Maybe you can also use "if (this instanceof Cloneable)" in Signature$Delegate::clone. >>> >>> Thanks, >>> Max >>> >>>> On Jun 11, 2020, at 3:45 AM, Valerie Peng wrote: >>>> >>>> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8246077/webrev.01/ >>>> >>>> Key changes in this revision are in the Delegate.of() method in java.security.MessageDigest class. >>>> >>>> Comments? >>>> >>>> Thanks, >>>> Valerie >>>> On 6/8/2020 1:42 PM, Valerie Peng wrote: >>>>> "md instanceof Cloneable && md is not from PKCS11" is not entirely precise. What I mean is that for MessageDigestSpi impls from PKCS11 provider, we will need to call the clone() to know for sure whether cloning is supported. If we decide to employ these extra logic for saving clone() call, it's better to do it inside the MessageDigest.of(...) so the callers don't have to repeat the same logic. Comments? >>>>> >>>>> Valerie >>>>> >>>>> On 6/8/2020 1:34 PM, Valerie Peng wrote: >>>>>> Hmm, I checked all MessageDigestSpi impls of JDK providers... The story is more complicated than we expect. >>>>>> >>>>>> For SUN provider which implement the digest spi, implementing Cloneable means it supports clone functionality. >>>>>> >>>>>> However, for SunPKCS11 provider which wraps native PKCS11 library, it always implements Cloneable interface, but when clone() is called, it will then perform the equivalent PKCS11 calls and throw CNSE if any PKCS11 error is observed. >>>>>> >>>>>> So, there is a possibility that the instanceof check and the clone() check leads to different result in this particular scenario. >>>>>> >>>>>> The chance of 3rd non-PKCS11 party provider whose MessageDigest/MessageDigestSpi impl implements Cloneable but throws CNSE when clone() is called should be very low? So, I think it should be sufficient to use "md instanceof Cloneable && md is not from PKCS11"? >>>>>> >>>>>> Valerie >>>>>> >>>>>> On 6/6/2020 9:10 AM, Xuelei Fan wrote: >>>>>>> As the the Delegate class takes care of the Cloneable SPI implementation, it should be sufficient to use "md instanceof Cloneable" only. It is not a expected behavior that a provider implements Cloneable but does not really support it. >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>> On 6/5/2020 10:54 PM, Weijun Wang wrote: >>>>>>>> Is it possible to try "md instanceof Cloneable || md.clone() returns"? Hopefully this is fast enough in most cases and also has the chance to recognize more actually-cloneable ones. >>>>>>>> >>>>>>>> I'm also OK with simply using "md instanceof Cloneable". >>>>>>>> >>>>>>>> --Max >>>>>>>> >>>>>>>>> On Jun 6, 2020, at 12:02 PM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I am merely following the spec's recommendation of trying the clone() for cloneability check. >>>>>>>>> >>>>>>>>> If you both are ok with it and prefer the instanceof check, I can sure reverting back the changes in HmacCore and HandshakeHash classes. >>>>>>>>> >>>>>>>>> Valerie >>>>>>>>> >>>>>>>>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>>>>>>>> I share the same concern. clone() is a heavy weight operation in constructors that can be called alot during intensive crypto operations. >>>>>>>>>> >>>>>>>>>> Now that you've done work on Delegate class - why not also keep the (instanceof Cloneable) test ? That can serve as your fastpath for the default JDK configuration AFAIK. >>>>>>>>>> >>>>>>>>>> regards, >>>>>>>>>> Sean. >>>>>>>>>> >>>>>>>>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>>>>>>>>> ? 2020?6?5??03:19?Valerie Peng ??? >>>>>>>>>>>> >>>>>>>>>>>>> Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? >>>>>>>>>>>> Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? >>>>>>>>>>> No. >>>>>>>>>>> >>>>>>>>>>> I understand this case, but this has already been fixed. Is there any other example? Or are you only follow the words in the spec? i.e. try clone() to see if it?s cloneable. >>>>>>>>>>> >>>>>>>>>>> I am worried that try clone() is much heavier than just check instanof Cloneable. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max From ecki at zusammenkunft.net Tue Jun 16 01:43:52 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 16 Jun 2020 01:43:52 +0000 Subject: [RFR] 8229148: SSLSession.invalidate() does not invalidate stateless tickets In-Reply-To: <46734043-e6aa-dcb7-a652-34ada619d4fb@oracle.com> References: <4395fdcf-b7cf-9943-9896-feed43196b8a@oracle.com>, <46734043-e6aa-dcb7-a652-34ada619d4fb@oracle.com> Message-ID: Hello, The change seems reasonable, but should there maybe a method to refresh temporary keys used for those session tokens - I.e. "invalidate all" and link to that so specific implementations are encourages to offer such an API. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Anthony Scarpino Gesendet: Tuesday, June 16, 2020 2:42:32 AM An: OpenJDK Security Betreff: Re: [RFR] 8229148: SSLSession.invalidate() does not invalidate stateless tickets The specifications for TLS 1.3 (RFC 8446) and Stateless Resumption for TLS 1.2 (RFC 5077) does not define session invalidation. Additionally, RFC 5077 provides research that it is unnecessary. This change is to clarify that session invalidation method in the Java API, in javax.net.ssl.SSLSession.invalidate(), may not be supported in some circumstances. The CSR is: https://bugs.openjdk.java.net/browse/JDK-8243678 The webrev is inline: src/java.base/share/classes/javax/net/ssl/SSLSession.java @@ -129,6 +129,12 @@ * using this session can continue to use the session until the * connection is closed. * + * @apiNote + * This operation is optional as the implementation may not support + * session invalidation. This could occur with implementations of + * Stateless Resumption (RFC 5077) and/or TLS 1.3 (RFC 8446) which + * do not specify session invalidation. + * * @see #isValid() */ public void invalidate(); -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue Jun 16 04:32:41 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 15 Jun 2020 21:32:41 -0700 Subject: [RFR] 8229148: SSLSession.invalidate() does not invalidate stateless tickets In-Reply-To: References: <4395fdcf-b7cf-9943-9896-feed43196b8a@oracle.com> <46734043-e6aa-dcb7-a652-34ada619d4fb@oracle.com> Message-ID: <549fbf8c-95ad-fd97-5ef0-b917cbd8f999@oracle.com> Hi, That's an interesting idea. I don't think a method in SSLSession would be the right place for such a method, maybe SSLContext given it's a server side operation affecting many sessions. If we do enhance the API for stateless operations, that would be a reasonable addition. Thanks for the input Tony On 6/15/20 6:43 PM, Bernd Eckenfels wrote: > Hello, > > The change seems reasonable, but should there maybe a method to refresh > temporary keys used for those session tokens - I.e. "invalidate all" and > link to that so specific implementations are encourages to offer such an > API. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------------------------------------------------ > *Von:* security-dev im Auftrag > von Anthony Scarpino > *Gesendet:* Tuesday, June 16, 2020 2:42:32 AM > *An:* OpenJDK Security > *Betreff:* Re: [RFR] 8229148: SSLSession.invalidate() does not > invalidate stateless tickets > The specifications for TLS 1.3 (RFC 8446) and Stateless Resumption for > TLS 1.2 (RFC 5077) does not define session invalidation. Additionally, > RFC 5077 provides research that it is unnecessary. This change is to > clarify that session invalidation method in the Java API, in > javax.net.ssl.SSLSession.invalidate(), may not be supported in some > circumstances. > > The CSR is: https://bugs.openjdk.java.net/browse/JDK-8243678 > The webrev is inline: > > src/java.base/share/classes/javax/net/ssl/SSLSession.java > @@ -129,6 +129,12 @@ > ?????? * using this session can continue to use the session until the > ?????? * connection is closed. > ?????? * > +???? * @apiNote > +???? * This operation is optional as the implementation may not support > +???? * session invalidation.? This could occur with implementations of > +???? * Stateless Resumption (RFC 5077) and/or TLS 1.3 (RFC 8446) which > +???? * do not specify session invalidation. > +???? * > ?????? * @see #isValid() > ?????? */ > ????? public void invalidate(); From valerie.peng at oracle.com Tue Jun 16 17:21:25 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 16 Jun 2020 10:21:25 -0700 Subject: [15] RFR JDK-8246077: Cloneable test in HmacCore seems questionable In-Reply-To: <04515356-4ED9-4BDE-9887-44CE501C784C@oracle.com> References: <8166c135-6f73-8615-ffc1-3e635e7223c4@oracle.com> <9F2A6D1E-C020-48FD-8F39-E63E870622F6@oracle.com> <5b4fc1d8-2b13-bf7d-bc6a-b6bfc3d6ca02@oracle.com> <01dc4ff5-7dd1-7ef4-530f-15f34290e1b4@oracle.com> <6e95ecd5-c29f-1282-4325-1dfa578e47cd@oracle.com> <3a8880dc-b79a-060d-f1ac-ff4cdf7b25bc@oracle.com> <484ad557-f218-9aa2-3330-407064404d8b@oracle.com> <7a49f7de-5165-43c1-d62b-7f9389f8a9d9@oracle.com> <0b6984b2-868f-0fa2-29ff-62d281e5f4d2@oracle.com> <1c7380a9-af6a-23f6-5a2a-ab969ad62835@oracle.com> <04515356-4ED9-4BDE-9887-44CE501C784C@oracle.com> Message-ID: <2e816a45-2cc0-43a6-dddc-69c4a7aaf7ea@oracle.com> Right, I debated about that myself - the changes to the Signature class is more for 3rd party impls and apps which may support Cloning and rely on instanceof check. Made the changes as it's harmless at least. The javadoc wording regarding cloning in MessageDigest class seems more needed for Signature class especially for callers requesting Signature with algorithm only which uses the delayed provider selection mechanism. Pondered for a moment whether to do this as it would involve filing a CSR. Given the main focus is MessageDigest and none of the JDK provider support cloneable signature impl, I didn't include this in the 8246077 fix. Thanks, Valerie On 6/15/2020 6:18 PM, Weijun Wang wrote: > Ah yes, you're correct. > > But because of this delayed selection, the existence of CloneableDelegate is not that useful unless user has specified a provider at the beginning. At first every Signature is a Delegate and thus not a Cloneable, you would have to clone it to make it Cloneable. > > I noticed none of our impls are Cloneable (or did I miss one?). What is the motivation to update Signature in this code change? > > Thanks, > Max > >> On Jun 16, 2020, at 7:29 AM, Valerie Peng wrote: >> >> Hmm, on a second thought, I reverted back on this last suggestion. Signature class has this delayed provider selection mechanism, so the clone() method should always rely on the chosen signatureSpi obj. >> >> Thanks, >> Valerie >> On 6/15/2020 12:59 PM, Valerie Peng wrote: >>> Sure, sounds good. Webrev is updated in place at webrev.01 since the change is just one-line. >>> >>> Will proceed with integration once the mach5 tests finish. >>> >>> Thanks! >>> Valerie >>> On 6/14/2020 2:21 AM, Weijun Wang wrote: >>>> Looks fine to me. Maybe you can also use "if (this instanceof Cloneable)" in Signature$Delegate::clone. >>>> >>>> Thanks, >>>> Max >>>> >>>>> On Jun 11, 2020, at 3:45 AM, Valerie Peng wrote: >>>>> >>>>> Webrev updated at: http://cr.openjdk.java.net/~valeriep/8246077/webrev.01/ >>>>> >>>>> Key changes in this revision are in the Delegate.of() method in java.security.MessageDigest class. >>>>> >>>>> Comments? >>>>> >>>>> Thanks, >>>>> Valerie >>>>> On 6/8/2020 1:42 PM, Valerie Peng wrote: >>>>>> "md instanceof Cloneable && md is not from PKCS11" is not entirely precise. What I mean is that for MessageDigestSpi impls from PKCS11 provider, we will need to call the clone() to know for sure whether cloning is supported. If we decide to employ these extra logic for saving clone() call, it's better to do it inside the MessageDigest.of(...) so the callers don't have to repeat the same logic. Comments? >>>>>> >>>>>> Valerie >>>>>> >>>>>> On 6/8/2020 1:34 PM, Valerie Peng wrote: >>>>>>> Hmm, I checked all MessageDigestSpi impls of JDK providers... The story is more complicated than we expect. >>>>>>> >>>>>>> For SUN provider which implement the digest spi, implementing Cloneable means it supports clone functionality. >>>>>>> >>>>>>> However, for SunPKCS11 provider which wraps native PKCS11 library, it always implements Cloneable interface, but when clone() is called, it will then perform the equivalent PKCS11 calls and throw CNSE if any PKCS11 error is observed. >>>>>>> >>>>>>> So, there is a possibility that the instanceof check and the clone() check leads to different result in this particular scenario. >>>>>>> >>>>>>> The chance of 3rd non-PKCS11 party provider whose MessageDigest/MessageDigestSpi impl implements Cloneable but throws CNSE when clone() is called should be very low? So, I think it should be sufficient to use "md instanceof Cloneable && md is not from PKCS11"? >>>>>>> >>>>>>> Valerie >>>>>>> >>>>>>> On 6/6/2020 9:10 AM, Xuelei Fan wrote: >>>>>>>> As the the Delegate class takes care of the Cloneable SPI implementation, it should be sufficient to use "md instanceof Cloneable" only. It is not a expected behavior that a provider implements Cloneable but does not really support it. >>>>>>>> >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 6/5/2020 10:54 PM, Weijun Wang wrote: >>>>>>>>> Is it possible to try "md instanceof Cloneable || md.clone() returns"? Hopefully this is fast enough in most cases and also has the chance to recognize more actually-cloneable ones. >>>>>>>>> >>>>>>>>> I'm also OK with simply using "md instanceof Cloneable". >>>>>>>>> >>>>>>>>> --Max >>>>>>>>> >>>>>>>>>> On Jun 6, 2020, at 12:02 PM, Valerie Peng wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am merely following the spec's recommendation of trying the clone() for cloneability check. >>>>>>>>>> >>>>>>>>>> If you both are ok with it and prefer the instanceof check, I can sure reverting back the changes in HmacCore and HandshakeHash classes. >>>>>>>>>> >>>>>>>>>> Valerie >>>>>>>>>> >>>>>>>>>> On 6/5/2020 2:04 AM, Se?n Coffey wrote: >>>>>>>>>>> I share the same concern. clone() is a heavy weight operation in constructors that can be called alot during intensive crypto operations. >>>>>>>>>>> >>>>>>>>>>> Now that you've done work on Delegate class - why not also keep the (instanceof Cloneable) test ? That can serve as your fastpath for the default JDK configuration AFAIK. >>>>>>>>>>> >>>>>>>>>>> regards, >>>>>>>>>>> Sean. >>>>>>>>>>> >>>>>>>>>>> On 05/06/2020 00:16, Weijun Wang wrote: >>>>>>>>>>>>> ? 2020?6?5??03:19?Valerie Peng ??? >>>>>>>>>>>>> >>>>>>>>>>>>>> Can you give an example when these 2 rules have different results? Is this only true for those implementation that directly subclass MessageDigest? >>>>>>>>>>>>> Before this fix, even the Spi impl implements Cloneable the instanceof check will always fail because the wrapper class, i.e. MessageDigest.Delegate does not. However, if you call the clone() (made public by the MessageDigest class), it will succeed because Delegate.clone() checks to see if the spi object implements the Cloneable interface, if yes, it will proceed to call the spi clone(). So, for this scenario, the results are different, e.g. instanceof returns false, but clone() succeeds. This is just one example. Is this what you are asking? >>>>>>>>>>>> No. >>>>>>>>>>>> >>>>>>>>>>>> I understand this case, but this has already been fixed. Is there any other example? Or are you only follow the words in the spec? i.e. try clone() to see if it?s cloneable. >>>>>>>>>>>> >>>>>>>>>>>> I am worried that try clone() is much heavier than just check instanof Cloneable. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max From alexey at azul.com Wed Jun 17 11:26:25 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 17 Jun 2020 11:26:25 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> Message-ID: <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> Hello Daniel, Thank you for review. As you suggested I?ve added static factory methods to create TlsChannelBinding class and changed connectionTimeout verification to "if (connectTimeout <= 0)" Also, I?ve added simple regression test to verify Channel Binding parameters. Please find updated webrev at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v8/ The link to CSR for this feature : https://bugs.openjdk.java.net/browse/JDK-8247311 Regards Alexey > On 12 Jun 2020, at 12:20, Daniel Fuchs wrote: > > Hi Alexey, > > This is starting to look good. > Thank you for persisting! > > I have a couple of comments - on the LDAP/JNDI side. > > There are several places where your new code is supposed to > trigger the throwing of a NamingException: > > LdapSasl.java: lines 76, 85, 140, 168 > > Please write a test to verify that it does so. Since the > exceptions are all supposed to be thrown before the actual > binding happens, there's no need to have an actual LDAP server > that supports any kind of authentication to test that. > > The simple dummy servers that we have in the test base should > be enough to write such a test. > > In addition, there are a couple of places where stray exceptions > could theoretically be thrown, and where they should be wrapped in NamingException (but are not). Maybe it's OK, because this has > been checked before - but it would be better if we had a test that > proves that it is so: > > For instance: LdapSasl.java > 82 connectTimeout = Integer.parseInt((String)propVal); > What if the value of the propVal is "Foo" - or not a String? > What unexpected exception might be relayed to the calling code? > > Still in that same file: > 84 if (connectTimeout == -1) > > should probably be if (connectTimeout <= 0) since > Connection.java checks for connectTimeout > 0 to determine > whether to start the initial handshake. > > Which makes me wonder if we should find a better way to > instruct Connection to start the initial handshake... > > TlsChannelBinding.java: > > It would be much better if static factories methods were used instead of > public constructors. That would allow you to check all arguments before > actually constructing your object: > > public static TlsChannelBinding create((byte[] finishedMessage) throws SaslException { > throw new UnsupportedOperationException("tls-unique channel binding is not supported"); > } > > public statuic TlsChannelBinding create(X509Certificate serverCertificate) throws SaslException { > var cbType = TlsChannelBindingType.TLS_SERVER_END_POINT; > byte[] cbData; > try { > // compute cbdata > ... > > return new TlsChannelBinding(cbType, cbData); > } > > private TlsChannelBinding(TlsChannelBindingType cbType, byte[] cbData) { > this.cbType = cbType; > this.cbData = cbData; > } > > That's all I have for now. > > best regards, > > -- daniel > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mbalao at redhat.com Thu Jun 18 18:33:42 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 18 Jun 2020 15:33:42 -0300 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> Message-ID: Hi, On 6/5/20 5:46 PM, Simon Tooke wrote: > Please let me know what you think. > > updated webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/ > Overall, the intrinsics looks good to me. A few minor comments: * sharedRuntime_x86_64.cpp * L3685 * Do we still need 'long long' type for 'i' and 'cnt' local variables? * L3724 * The last argument of 'sub' has type 'int', while in the not-Windows variant is a long. Can we align this? * L3729 * Is it possible to directly store in a[i]? (instead of going through 'tmp') * I guess the compiler will easily optimize this, but we may still get rid of the 2nd line * I've seen in L3753 you directly store Note: it's a bit unfortunate that we don't have x86-64 inline assembly in CL to maintain the same logic, as there is nothing OS-specific here. Note 2: I'm not an official jdk-mainline reviewer, so we still need someone else who approves. Thanks, Martin.- From sha.jiang at oracle.com Fri Jun 19 11:41:25 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 19 Jun 2020 19:41:25 +0800 Subject: RFR 8245520: Provide a way to add CA certificate to cacerts during test run In-Reply-To: References: <124fa783-00d3-f140-07c6-40aac08c466d@oracle.com> <90ABC528-D206-4BCF-A500-35C41E0F9D52@oracle.com> Message-ID: Move this patch to sun/security/util/module_patch Webrev: http://cr.openjdk.java.net/~jjiang/8245520/webrev.01/ Best regards, John Jiang On 2020/6/11 15:55, sha.jiang at oracle.com wrote: > Hi Max, > Thanks for your info! > > It looks that patch for java.base:sun.security.util.FilePaths.java is > used > for specifying an alternative cacerts file. But my requirement is > updating > the existing cacerts with given CAs. > > Both of the functions are useful. I'll submit a new webrev after the fix > for JDK-8244148 is pushed. I also have some comments about Hai-May's > webrev. > > Best regards, > John Jiang > > On 2020/6/11 11:25, Weijun Wang wrote: >> Hai-May has a similar function as a by-product in >> >> ??? https://cr.openjdk.java.net/~hchao/8244148/webrev.02/ >> >> See FilePaths.java and MyOwnCacerts.java for the detail. Her code >> change is in code review now. >> >> Please coordinate with her on how to get this done nicely. >> >> Thanks, >> Max >> >>> On Jun 11, 2020, at 9:39 AM, sha.jiang at oracle.com wrote: >>> >>> Hi, >>> This patch contains a patched version for class >>> sun.security.util.AnchorCertificates. >>> It allows to add CAs to cacerts at runtime for testing purpose. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8245520/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245520 >>> >>> Best regards, >>> John Jiang >>> From weijun.wang at oracle.com Fri Jun 19 14:32:07 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Jun 2020 22:32:07 +0800 Subject: RFR 8247907: XMLDsig logging does not work Message-ID: <6B160A08-B8DC-413F-A301-CDA639FE82FC@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8247907/webrev.00/ I also take this chance to get the class and method names correct in the log. Thanks, Max From daniel.daugherty at oracle.com Fri Jun 19 17:07:13 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 19 Jun 2020 13:07:13 -0400 Subject: RFR(T): 8247876: ProblemList various crypto tests on aarch64 Message-ID: <0711430f-f48a-96a5-980c-925671c2ac9c@oracle.com> Greetings, In order to reduce the noise in the JDK15 and JDK16 CIs, I'm ProblemListing some crypto tests on linux-aarch64. ??? JDK-8247876 ProblemList various crypto tests on aarch64 ??? https://bugs.openjdk.java.net/browse/JDK-8247876 Here's the associated product bug: ??? JDK-8247359 SecureRandom tests timeout on aarch64 ??? https://bugs.openjdk.java.net/browse/JDK-8247359 Here's the context diff for the patch: $ hg diff -r qparent diff -r b5e739802b80 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt??? Thu Jun 11 18:16:26 2020 +0200 +++ b/test/jdk/ProblemList.txt??? Fri Jun 19 12:59:31 2020 -0400 @@ -699,6 +699,10 @@ ?sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java 8039280 generic-all ?sun/security/provider/PolicyParser/ExtDirsChange.java 8039280 generic-all ?sun/security/provider/PolicyParser/PrincipalExpansionError.java 8039280 generic-all +sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java 8247359 linux-aarch64 +sun/security/provider/SecureRandom/SHA1PRNGReseed.java 8247359 linux-aarch64 +sun/security/provider/SecureRandom/StrongSecureRandom.java 8247359 linux-aarch64 +sun/security/provider/SeedGenerator/SeedGeneratorChoice.java 8247359 linux-aarch64 ?############################################################################ I have a Tier2 test job running since yesterday, but it has not run the linux-aarch64 tasks yet (resources limited at the moment) so I have not confirmed that 'linux-aarch64' is the right magic incantation, but it should be. Thanks, in advance, for any questions comments or suggestions. Dan From bradford.wetmore at oracle.com Fri Jun 19 17:44:30 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 19 Jun 2020 10:44:30 -0700 Subject: RFR(T): 8247876: ProblemList various crypto tests on aarch64 In-Reply-To: <0711430f-f48a-96a5-980c-925671c2ac9c@oracle.com> References: <0711430f-f48a-96a5-980c-925671c2ac9c@oracle.com> Message-ID: <512a7d57-e68e-f59e-9301-77357633e199@oracle.com> Assuming 'linux-aarch64' is correct, this looks ok to me. As an aside, we are looking at a possible configuration problem in our test environment that is not linking the host RNG to the VMs. I'm hoping these can come off soon. Brad On 6/19/2020 10:07 AM, Daniel D. Daugherty wrote: > Greetings, > > In order to reduce the noise in the JDK15 and JDK16 CIs, I'm ProblemListing > some crypto tests on linux-aarch64. > > ??? JDK-8247876 ProblemList various crypto tests on aarch64 > ??? https://bugs.openjdk.java.net/browse/JDK-8247876 > > Here's the associated product bug: > > ??? JDK-8247359 SecureRandom tests timeout on aarch64 > ??? https://bugs.openjdk.java.net/browse/JDK-8247359 > > Here's the context diff for the patch: > > $ hg diff -r qparent > diff -r b5e739802b80 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt??? Thu Jun 11 18:16:26 2020 +0200 > +++ b/test/jdk/ProblemList.txt??? Fri Jun 19 12:59:31 2020 -0400 > @@ -699,6 +699,10 @@ > ?sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java > 8039280 generic-all > ?sun/security/provider/PolicyParser/ExtDirsChange.java 8039280 generic-all > ?sun/security/provider/PolicyParser/PrincipalExpansionError.java > 8039280 generic-all > +sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java 8247359 > linux-aarch64 > +sun/security/provider/SecureRandom/SHA1PRNGReseed.java 8247359 > linux-aarch64 > +sun/security/provider/SecureRandom/StrongSecureRandom.java 8247359 > linux-aarch64 > +sun/security/provider/SeedGenerator/SeedGeneratorChoice.java 8247359 > linux-aarch64 > > ?############################################################################ > > I have a Tier2 test job running since yesterday, but it has not run the > linux-aarch64 tasks yet (resources limited at the moment) so I have not > confirmed that 'linux-aarch64' is the right magic incantation, but it > should be. > > Thanks, in advance, for any questions comments or suggestions. > > Dan From daniel.daugherty at oracle.com Fri Jun 19 18:00:40 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 19 Jun 2020 14:00:40 -0400 Subject: RFR(T): 8247876: ProblemList various crypto tests on aarch64 In-Reply-To: <512a7d57-e68e-f59e-9301-77357633e199@oracle.com> References: <0711430f-f48a-96a5-980c-925671c2ac9c@oracle.com> <512a7d57-e68e-f59e-9301-77357633e199@oracle.com> Message-ID: <8901fdab-76a1-7671-0a3c-51597f5cbe31@oracle.com> Thanks for the fast review! I'm still trying to get verification, but haven't been able to. The submitted jobs are getting thru Tier2 faster than my Adhoc job so I'm tempted to push and fix later if it doesn't work... Dan On 6/19/20 1:44 PM, Bradford Wetmore wrote: > Assuming 'linux-aarch64' is correct, this looks ok to me. > > As an aside, we are looking at a possible configuration problem in our > test environment that is not linking the host RNG to the VMs. I'm > hoping these can come off soon. > > Brad > > > > On 6/19/2020 10:07 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> In order to reduce the noise in the JDK15 and JDK16 CIs, I'm >> ProblemListing >> some crypto tests on linux-aarch64. >> >> ???? JDK-8247876 ProblemList various crypto tests on aarch64 >> ???? https://bugs.openjdk.java.net/browse/JDK-8247876 >> >> Here's the associated product bug: >> >> ???? JDK-8247359 SecureRandom tests timeout on aarch64 >> ???? https://bugs.openjdk.java.net/browse/JDK-8247359 >> >> Here's the context diff for the patch: >> >> $ hg diff -r qparent >> diff -r b5e739802b80 test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt??? Thu Jun 11 18:16:26 2020 +0200 >> +++ b/test/jdk/ProblemList.txt??? Fri Jun 19 12:59:31 2020 -0400 >> @@ -699,6 +699,10 @@ >> ??sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java >> 8039280 generic-all >> ??sun/security/provider/PolicyParser/ExtDirsChange.java 8039280 >> generic-all >> ??sun/security/provider/PolicyParser/PrincipalExpansionError.java >> 8039280 generic-all >> +sun/security/provider/SecureRandom/AbstractDrbg/SpecTest.java >> 8247359 linux-aarch64 >> +sun/security/provider/SecureRandom/SHA1PRNGReseed.java 8247359 >> linux-aarch64 >> +sun/security/provider/SecureRandom/StrongSecureRandom.java 8247359 >> linux-aarch64 >> +sun/security/provider/SeedGenerator/SeedGeneratorChoice.java 8247359 >> linux-aarch64 >> >> ??############################################################################ >> >> >> I have a Tier2 test job running since yesterday, but it has not run the >> linux-aarch64 tasks yet (resources limited at the moment) so I have not >> confirmed that 'linux-aarch64' is the right magic incantation, but it >> should be. >> >> Thanks, in advance, for any questions comments or suggestions. >> >> Dan From sean.mullan at oracle.com Fri Jun 19 18:12:12 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 19 Jun 2020 14:12:12 -0400 Subject: RFR 8247907: XMLDsig logging does not work In-Reply-To: <6B160A08-B8DC-413F-A301-CDA639FE82FC@oracle.com> References: <6B160A08-B8DC-413F-A301-CDA639FE82FC@oracle.com> Message-ID: Looks good. Interesting use of StackWalker. I would recommend adding some comments about that, and that the use of "2" is extremely important if any of this code is moved around such that the stack frames are different. --Sean On 6/19/20 10:32 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8247907/webrev.00/ > > I also take this chance to get the class and method names correct in the log. > > Thanks, > Max > From weijun.wang at oracle.com Sat Jun 20 14:47:14 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 20 Jun 2020 22:47:14 +0800 Subject: [15] RFR 8247964: All log0() in com/sun/org/slf4j/internal/Logger.java should be private Message-ID: <4B8F6211-0073-42B2-B267-533B88E74126@oracle.com> The 3 newly added log0() methods in com/sun/org/slf4j/internal/Logger.java are declared public. This is a stupid typo. In fact, in the comment at the beginning of that class [1] I specifically pointed out they are private. Here is the patch. Noreg-trivial. diff --git a/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java b/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java --- a/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java +++ b/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java @@ -103,14 +103,14 @@ } } - public void log0(Level level, String s, Throwable e) { + private void log0(Level level, String s, Throwable e) { if (impl.isLoggable(level)) { var sf = WALKER.walk(f -> f.skip(2).findFirst()).get(); impl.logp(Level.FINE, sf.getClassName(), sf.getMethodName(), s, e); } } - public void log0(Level level, String s, Object... o) { + private void log0(Level level, String s, Object... o) { if (impl.isLoggable(level)) { var sf = WALKER.walk(f -> f.skip(2).findFirst()).get(); impl.logp(Level.FINE, sf.getClassName(), sf.getMethodName(), Thanks, Max [1] https://hg.openjdk.java.net/jdk/jdk15/rev/33b9328a9605#l2.21 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Sat Jun 20 16:01:46 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Sat, 20 Jun 2020 12:01:46 -0400 Subject: [15] RFR 8247964: All log0() in com/sun/org/slf4j/internal/Logger.java should be private In-Reply-To: <4B8F6211-0073-42B2-B267-533B88E74126@oracle.com> References: <4B8F6211-0073-42B2-B267-533B88E74126@oracle.com> Message-ID: Looks good. Good to catch these early. Thanks, Roger On 6/20/20 10:47 AM, Weijun Wang wrote: > The 3 newly added log0() methods > in?com/sun/org/slf4j/internal/Logger.java are declared public. This is > a stupid typo. In fact, in the comment at the beginning of that class > [1] I specifically pointed out they are private. > > Here is the patch. Noreg-trivial. > > *diff --git > a/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java > b/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java* > *--- > a/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java* > *+++ > b/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java* > @@ -103,14 +103,14 @@ > ?? ? ? ? } > ?? ? } > > > -? ? public void log0(Level level, String s, Throwable e) { > +? ? private void log0(Level level, String s, Throwable e) { > ?? ? ? ? if (impl.isLoggable(level)) { > var sf = WALKER.walk(f -> f.skip(2).findFirst()).get(); > impl.logp(Level.FINE, sf.getClassName(), sf.getMethodName(), s, e); > ?? ? ? ? } > ?? ? } > > > -? ? public void log0(Level level, String s, Object... o) { > +? ? private void log0(Level level, String s, Object... o) { > ?? ? ? ? if (impl.isLoggable(level)) { > var sf = WALKER.walk(f -> f.skip(2).findFirst()).get(); > impl.logp(Level.FINE, sf.getClassName(), sf.getMethodName(), > > > Thanks, > Max > > [1] https://hg.openjdk.java.net/jdk/jdk15/rev/33b9328a9605#l2.21 From xuelei.fan at oracle.com Sat Jun 20 16:04:33 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 20 Jun 2020 09:04:33 -0700 Subject: [15] RFR 8247964: All log0() in com/sun/org/slf4j/internal/Logger.java should be private In-Reply-To: <4B8F6211-0073-42B2-B267-533B88E74126@oracle.com> References: <4B8F6211-0073-42B2-B267-533B88E74126@oracle.com> Message-ID: <90e26a62-2abc-415e-70e0-bffbaed3f6d5@oracle.com> Looks good to me. Xuelei On 6/20/2020 7:47 AM, Weijun Wang wrote: > The 3 newly added log0() methods > in?com/sun/org/slf4j/internal/Logger.java are declared public. This is a > stupid typo. In fact, in the comment at the beginning of that class [1] > I specifically pointed out they are private. > > Here is the patch. Noreg-trivial. > > *diff --git > a/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java > b/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java* > *--- > a/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java* > *+++ > b/src/java.xml.crypto/share/classes/com/sun/org/slf4j/internal/Logger.java* > @@ -103,14 +103,14 @@ > ?? ? ? ? } > ?? ? } > > > -? ? public void log0(Level level, String s, Throwable e) { > +? ? private void log0(Level level, String s, Throwable e) { > ?? ? ? ? if (impl.isLoggable(level)) { > ?? ? ? ? ? ? var sf = WALKER.walk(f -> f.skip(2).findFirst()).get(); > ?? ? ? ? ? ? impl.logp(Level.FINE, sf.getClassName(), > sf.getMethodName(), s, e); > ?? ? ? ? } > ?? ? } > > > -? ? public void log0(Level level, String s, Object... o) { > +? ? private void log0(Level level, String s, Object... o) { > ?? ? ? ? if (impl.isLoggable(level)) { > ?? ? ? ? ? ? var sf = WALKER.walk(f -> f.skip(2).findFirst()).get(); > ?? ? ? ? ? ? impl.logp(Level.FINE, sf.getClassName(), sf.getMethodName(), > > > Thanks, > Max > > [1] https://hg.openjdk.java.net/jdk/jdk15/rev/33b9328a9605#l2.21 From jamil.j.nimeh at oracle.com Mon Jun 22 04:07:58 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Sun, 21 Jun 2020 21:07:58 -0700 Subject: RFR JDK-8239950: Update PKCS9 Attributes to PKCS#9 v2.0 Encodings In-Reply-To: <424dd805-c3f6-f1de-eee9-0809364e31af@oracle.com> References: <424dd805-c3f6-f1de-eee9-0809364e31af@oracle.com> Message-ID: <4a7edac6-6611-820e-1ae2-edd09e6e294b@oracle.com> Ping... --Jamil On 6/4/20 10:55 PM, Jamil Nimeh wrote: > Hello all, > > This brings a few PKCS#9 attributes (unstructuredName, > unstructuredAddress, signingTime) into line with v2.0 of the spec (RFC > 2985).? It mostly expands the allowed string or date types for these > attributes.? I also came across a corner-case bug where toString calls > on PKCS9Attribute objects were throwing NPE if the attribute type was > a UniversalString, so that is addressed in this webrev too. > > Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.01 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8239950 > > --Jamil > From weijun.wang at oracle.com Mon Jun 22 07:42:26 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 22 Jun 2020 15:42:26 +0800 Subject: RFR JDK-8239950: Update PKCS9 Attributes to PKCS#9 v2.0 Encodings In-Reply-To: <4a7edac6-6611-820e-1ae2-edd09e6e294b@oracle.com> References: <424dd805-c3f6-f1de-eee9-0809364e31af@oracle.com> <4a7edac6-6611-820e-1ae2-edd09e6e294b@oracle.com> Message-ID: <6993DCD1-BFB3-4CD2-99F3-DF6D2CB232EC@oracle.com> Source change looks fine to me. One small suggestion: Is it possible to encode the bytes in the test as HEX instead of BASE64? If so, I can use my human eyes to look at the content. HexPrinter in test/lib can be used to generate them and Utils.toByteArray can be used to translate them back to byte[]. Thanks, Max > On Jun 22, 2020, at 12:07 PM, Jamil Nimeh wrote: > > Ping... > > --Jamil > > On 6/4/20 10:55 PM, Jamil Nimeh wrote: >> Hello all, >> >> This brings a few PKCS#9 attributes (unstructuredName, unstructuredAddress, signingTime) into line with v2.0 of the spec (RFC 2985). It mostly expands the allowed string or date types for these attributes. I also came across a corner-case bug where toString calls on PKCS9Attribute objects were throwing NPE if the attribute type was a UniversalString, so that is addressed in this webrev too. >> >> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.01 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8239950 >> >> --Jamil >> From aph at redhat.com Mon Jun 22 09:00:01 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 22 Jun 2020 10:00:01 +0100 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> Message-ID: <73153f4a-184c-6848-1ca2-436377536cc4@redhat.com> On 18/06/2020 19:33, Martin Balao wrote: > * sharedRuntime_x86_64.cpp > * L3685 > * Do we still need 'long long' type for 'i' and 'cnt' local variables? No, but this is 64-bit-only code. And len is a long, so let's keep it. > * L3724 > * The last argument of 'sub' has type 'int', while in the not-Windows > variant is a long. Can we align this? We should do that, yes. Better it be long everywhere. > * L3729 > * Is it possible to directly store in a[i]? (instead of going through > 'tmp') I'm not sure this would add anything. In fact, I think this change would make it harder to read. > * I guess the compiler will easily optimize this, but we may still > get rid of the 2nd line > * I've seen in L3753 you directly store > > Note: it's a bit unfortunate that we don't have x86-64 inline assembly > in CL to maintain the same logic, as there is nothing OS-specific here. I think the problem is that MS never had a nice way to do inline assembly in 32-bit C, so they just gave up altogether when they went 64-bit. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sean.coffey at oracle.com Mon Jun 22 11:22:32 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 22 Jun 2020 12:22:32 +0100 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> Message-ID: <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> Thanks Lance. I've updated the patch with some extra offline feedback from yourself and Max. A new warning is printed with use of the new flag. A warning is also printed when file posix permissions are detected on resources being signed. Test updated for that also. https://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/ regards, Sean. On 12/06/2020 17:05, Lance Andersen wrote: > Hi Sean, > > I think your changes look fine so all good FMPOV. > > Best > Lance > >> On Jun 12, 2020, at 6:21 AM, Se?n Coffey > > wrote: >> >> Hi, >> >> I'd like to reboot this jarsigner enhancement request[1]. I've >> removed the problem references to zip file name extensions. Instead, >> there's a new JDK implementation specific jarsigner option: >> -keepposixperms >> >> https://bugs.openjdk.java.net/browse/JDK-8218021 >> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/ >> >> regards, >> Sean. >> >> [1] >> http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From jamil.j.nimeh at oracle.com Mon Jun 22 14:56:45 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 22 Jun 2020 07:56:45 -0700 Subject: RFR JDK-8239950: Update PKCS9 Attributes to PKCS#9 v2.0 Encodings In-Reply-To: <6993DCD1-BFB3-4CD2-99F3-DF6D2CB232EC@oracle.com> References: <424dd805-c3f6-f1de-eee9-0809364e31af@oracle.com> <4a7edac6-6611-820e-1ae2-edd09e6e294b@oracle.com> <6993DCD1-BFB3-4CD2-99F3-DF6D2CB232EC@oracle.com> Message-ID: <01174d9d-6c11-73c6-a69b-dcd906a23534@oracle.com> Sure, I have code in other tests to do the conversions into hexdumps as well.? I'll convert those today and send a new review out.? Thanks for looking this over, Max! --Jamil On 6/22/2020 12:42 AM, Weijun Wang wrote: > Source change looks fine to me. > > One small suggestion: Is it possible to encode the bytes in the test as HEX instead of BASE64? If so, I can use my human eyes to look at the content. HexPrinter in test/lib can be used to generate them and Utils.toByteArray can be used to translate them back to byte[]. > > Thanks, > Max > > >> On Jun 22, 2020, at 12:07 PM, Jamil Nimeh wrote: >> >> Ping... >> >> --Jamil >> >> On 6/4/20 10:55 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This brings a few PKCS#9 attributes (unstructuredName, unstructuredAddress, signingTime) into line with v2.0 of the spec (RFC 2985). It mostly expands the allowed string or date types for these attributes. I also came across a corner-case bug where toString calls on PKCS9Attribute objects were throwing NPE if the attribute type was a UniversalString, so that is addressed in this webrev too. >>> >>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.01 >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8239950 >>> >>> --Jamil >>> From claes.redestad at oracle.com Mon Jun 22 15:04:30 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 22 Jun 2020 17:04:30 +0200 Subject: RFR: 8247995: Avoid use of a mapping function in Permissions.getPermissionCollection Message-ID: <85478146-abf3-0504-4108-9958d6041a4e@oracle.com> Hi, this patch fixes a corner-case performance issue with Permissions.implies(Permission) by not needing to allocate a mapper function (or lambda) on each invocation of getPermissionCollection when there are unresolved permissions present. Bug: https://bugs.openjdk.java.net/browse/JDK-8247995 Patch: http://cr.openjdk.java.net/~redestad/8247995/open.00/ Testing: tier1-2 Thanks! /Claes From lance.andersen at oracle.com Mon Jun 22 16:17:08 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 22 Jun 2020 12:17:08 -0400 Subject: RFR: 8218021: jarsigner strips the execute permission when signing a .zip file In-Reply-To: <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> Message-ID: HI Sean, Looks OK based on our exchanges. Thank you for your time on this one! Best Lance > On Jun 22, 2020, at 7:22 AM, Se?n Coffey wrote: > > Thanks Lance. > > I've updated the patch with some extra offline feedback from yourself and Max. > A new warning is printed with use of the new flag. A warning is also printed when file posix permissions are detected on resources being signed. Test updated for that also. > > https://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/ > regards, > Sean. > > On 12/06/2020 17:05, Lance Andersen wrote: >> Hi Sean, >> >> I think your changes look fine so all good FMPOV. >> >> Best >> Lance >> >>> On Jun 12, 2020, at 6:21 AM, Se?n Coffey > wrote: >>> >>> Hi, >>> >>> I'd like to reboot this jarsigner enhancement request[1]. I've removed the problem references to zip file name extensions. Instead, there's a new JDK implementation specific jarsigner option: -keepposixperms >>> >>> https://bugs.openjdk.java.net/browse/JDK-8218021 >>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/ >>> >>> regards, >>> Sean. >>> >>> [1] http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html >>> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From sergei.tsypanov at yandex.ru Mon Jun 22 18:23:24 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Mon, 22 Jun 2020 20:23:24 +0200 Subject: [PATCH] remove redundant initialization of volatile fields with default values In-Reply-To: <281231592473099@mail.yandex.ru> Message-ID: <616151592850151@mail.yandex.ru> Hello, while investigating an issue I've found out that assignment of default value to volatile fields slows down object instantiation. Consider the benchmark: @State(Scope.Thread) @OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(value = Mode.AverageTime) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"}) public class VolatileFieldBenchmark { ??@Benchmark ??public Object explicitInit() { ????return new ExplicitInit(); ??} ??@Benchmark ??public Object noInit() { ????return new NoInit(); ??} ??private static class ExplicitInit { ????private volatile boolean field = false; ??} ??private static class NoInit { ????private volatile boolean field; ??} } This gives the following results as of my machine: Benchmark Mode Cnt Score Error Units VolatileFieldBenchmark.explicitInit avgt 40 11.087 ? 0.140 ns/op VolatileFieldBenchmark.noInit avgt 40 3.367 ? 0.131 ns/op I've looked into source code of java.base and found out several cases where the default value is assigned to volatile field. Getting rid of such assignements demonstates improvement as of object instantiation, e.g. javax.security.auth.Subject: ???????????Mode Cnt Score Error Units before avgt 40 35.933 ? 2.647 ns/op after avgt 40 30.817 ? 2.384 ns/op As of testing tier1 and tier2 are both ok after the changes. Best regards, Sergey Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: volatile.patch Type: text/x-diff Size: 6253 bytes Desc: not available URL: -------------- next part -------------- An embedded message was scrubbed... From: =?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?= Subject: [PATCH] remove redundant initialization of volatile fields with default values Date: Fri, 19 Jun 2020 06:57:25 +0200 Size: 11984 URL: From Roger.Riggs at oracle.com Mon Jun 22 21:03:14 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 22 Jun 2020 17:03:14 -0400 Subject: RFR: 8247995: Avoid use of a mapping function in Permissions.getPermissionCollection In-Reply-To: <85478146-abf3-0504-4108-9958d6041a4e@oracle.com> References: <85478146-abf3-0504-4108-9958d6041a4e@oracle.com> Message-ID: <8b987951-a332-0d69-3002-55dbe74a5dd4@oracle.com> Hi Claes, Its correct as is but I would have written it without duplicating the 'permsMap.get(p.getClass())' invocation and as a single method (unless the inlining of getPermissionCollection(p,create)) is important. A patch on top of yours: diff --git a/src/java.base/share/classes/java/security/Permissions.java b/src/java.base/share/classes/java/security/Permissions.java --- a/src/java.base/share/classes/java/security/Permissions.java +++ b/src/java.base/share/classes/java/security/Permissions.java @@ -229,20 +229,16 @@ implements Serializable ????? */ ???? private PermissionCollection getPermissionCollection(Permission p, boolean createEmpty) { +??????? PermissionCollection pc = permsMap.get(p.getClass()); ???????? if (!hasUnresolved && !createEmpty) { ???????????? // Collection not to be created -??????????? return permsMap.get(p.getClass()); +??????????? return pc; ???????? } -??????? PermissionCollection pc = permsMap.get(p.getClass()); ???????? if (pc != null) { ???????????? // Collection already created ???????????? return pc; ???????? } -??????? return createPermissionCollection(p, createEmpty); -??? } -??? private PermissionCollection createPermissionCollection(Permission p, - boolean createEmpty) { ???????? synchronized (permsMap) { ???????????? Class c = p.getClass(); ???????????? PermissionCollection pc = permsMap.get(c); Thanks, Roger On 6/22/20 11:04 AM, Claes Redestad wrote: > Hi, > > this patch fixes a corner-case performance issue with > Permissions.implies(Permission) by not needing to allocate a mapper > function (or lambda) on each invocation of getPermissionCollection > when there are unresolved permissions present. > > Bug:?? https://bugs.openjdk.java.net/browse/JDK-8247995 > Patch: http://cr.openjdk.java.net/~redestad/8247995/open.00/ > > Testing: tier1-2 > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Jun 22 21:54:45 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 22 Jun 2020 23:54:45 +0200 Subject: RFR: 8247995: Avoid use of a mapping function in Permissions.getPermissionCollection In-Reply-To: <8b987951-a332-0d69-3002-55dbe74a5dd4@oracle.com> References: <85478146-abf3-0504-4108-9958d6041a4e@oracle.com> <8b987951-a332-0d69-3002-55dbe74a5dd4@oracle.com> Message-ID: <6006109b-f4c7-210b-40d1-106f956e1aa4@oracle.com> Hi Roger, I prototyped it as such, and saw a 0.4ns/op overhead in the PermissionImplies.withoutPermission. Thinking about it a bit now, this should be the rare path taken, since it means the permission is not implied and the performance largely irrelevant. I'll simplify as you suggested. /Claes On 2020-06-22 23:03, Roger Riggs wrote: > Hi Claes, > > Its correct as is but I would have written it without duplicating the > 'permsMap.get(p.getClass())' invocation > and as a single method (unless the inlining of > getPermissionCollection(p,create)) is important. > > A patch on top of yours: > > diff --git a/src/java.base/share/classes/java/security/Permissions.java > b/src/java.base/share/classes/java/security/Permissions.java > --- a/src/java.base/share/classes/java/security/Permissions.java > +++ b/src/java.base/share/classes/java/security/Permissions.java > @@ -229,20 +229,16 @@ implements Serializable > ????? */ > ???? private PermissionCollection getPermissionCollection(Permission p, > boolean createEmpty) { > +??????? PermissionCollection pc = permsMap.get(p.getClass()); > ???????? if (!hasUnresolved && !createEmpty) { > ???????????? // Collection not to be created > -??????????? return permsMap.get(p.getClass()); > +??????????? return pc; > ???????? } > -??????? PermissionCollection pc = permsMap.get(p.getClass()); > ???????? if (pc != null) { > ???????????? // Collection already created > ???????????? return pc; > ???????? } > -??????? return createPermissionCollection(p, createEmpty); > -??? } > > -??? private PermissionCollection createPermissionCollection(Permission p, > - boolean createEmpty) { > ???????? synchronized (permsMap) { > ???????????? Class c = p.getClass(); > ???????????? PermissionCollection pc = permsMap.get(c); > > Thanks, Roger > > > On 6/22/20 11:04 AM, Claes Redestad wrote: >> Hi, >> >> this patch fixes a corner-case performance issue with >> Permissions.implies(Permission) by not needing to allocate a mapper >> function (or lambda) on each invocation of getPermissionCollection >> when there are unresolved permissions present. >> >> Bug:?? https://bugs.openjdk.java.net/browse/JDK-8247995 >> Patch: http://cr.openjdk.java.net/~redestad/8247995/open.00/ >> >> Testing: tier1-2 >> >> Thanks! >> >> /Claes > From claes.redestad at oracle.com Mon Jun 22 22:29:21 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 23 Jun 2020 00:29:21 +0200 Subject: RFR: 8247995: Avoid use of a mapping function in Permissions.getPermissionCollection In-Reply-To: <6006109b-f4c7-210b-40d1-106f956e1aa4@oracle.com> References: <85478146-abf3-0504-4108-9958d6041a4e@oracle.com> <8b987951-a332-0d69-3002-55dbe74a5dd4@oracle.com> <6006109b-f4c7-210b-40d1-106f956e1aa4@oracle.com> Message-ID: Hi, inlining the new method actually messed up microbenchmark scores a lot (15-80% overhead). I settled for simplifying the duplicate permsMap.get in the outer method in a way that keeps scores neutral: http://cr.openjdk.java.net/~redestad/8247995/open.01/ Benchmark Mode Cnt Score Error Units PermissionsImplies.withPermission avgt 15 27.857 ? 0.137 ns/op PermissionsImplies.withUnresolvedPermission avgt 15 27.918 ? 0.178 ns/op PermissionsImplies.withoutPermission avgt 15 4.559 ? 0.115 ns/op Thanks! /Claes On 2020-06-22 23:54, Claes Redestad wrote: > Hi Roger, > > I prototyped it as such, and saw a 0.4ns/op overhead in the > PermissionImplies.withoutPermission. Thinking about it a bit now, this > should be the rare path taken, since it means the permission is not > implied and the performance largely irrelevant. I'll simplify as you > suggested. > > /Claes > > On 2020-06-22 23:03, Roger Riggs wrote: >> Hi Claes, >> >> Its correct as is but I would have written it without duplicating the >> 'permsMap.get(p.getClass())' invocation >> and as a single method (unless the inlining of >> getPermissionCollection(p,create)) is important. >> >> A patch on top of yours: >> >> diff --git >> a/src/java.base/share/classes/java/security/Permissions.java >> b/src/java.base/share/classes/java/security/Permissions.java >> --- a/src/java.base/share/classes/java/security/Permissions.java >> +++ b/src/java.base/share/classes/java/security/Permissions.java >> @@ -229,20 +229,16 @@ implements Serializable >> ?????? */ >> ????? private PermissionCollection getPermissionCollection(Permission p, >> boolean createEmpty) { >> +??????? PermissionCollection pc = permsMap.get(p.getClass()); >> ????????? if (!hasUnresolved && !createEmpty) { >> ????????????? // Collection not to be created >> -??????????? return permsMap.get(p.getClass()); >> +??????????? return pc; >> ????????? } >> -??????? PermissionCollection pc = permsMap.get(p.getClass()); >> ????????? if (pc != null) { >> ????????????? // Collection already created >> ????????????? return pc; >> ????????? } >> -??????? return createPermissionCollection(p, createEmpty); >> -??? } >> >> -??? private PermissionCollection >> createPermissionCollection(Permission p, >> - boolean createEmpty) { >> ????????? synchronized (permsMap) { >> ????????????? Class c = p.getClass(); >> ????????????? PermissionCollection pc = permsMap.get(c); >> >> Thanks, Roger >> >> >> On 6/22/20 11:04 AM, Claes Redestad wrote: >>> Hi, >>> >>> this patch fixes a corner-case performance issue with >>> Permissions.implies(Permission) by not needing to allocate a mapper >>> function (or lambda) on each invocation of getPermissionCollection >>> when there are unresolved permissions present. >>> >>> Bug:?? https://bugs.openjdk.java.net/browse/JDK-8247995 >>> Patch: http://cr.openjdk.java.net/~redestad/8247995/open.00/ >>> >>> Testing: tier1-2 >>> >>> Thanks! >>> >>> /Claes >> From Roger.Riggs at oracle.com Mon Jun 22 22:30:50 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 22 Jun 2020 18:30:50 -0400 Subject: RFR: 8247995: Avoid use of a mapping function in Permissions.getPermissionCollection In-Reply-To: References: <85478146-abf3-0504-4108-9958d6041a4e@oracle.com> <8b987951-a332-0d69-3002-55dbe74a5dd4@oracle.com> <6006109b-f4c7-210b-40d1-106f956e1aa4@oracle.com> Message-ID: <54f5388b-c326-17f0-803e-57e01450ca4a@oracle.com> Hi Claes, Looks good. Thanks for the followup. Roger On 6/22/20 6:29 PM, Claes Redestad wrote: > Hi, > > inlining the new method actually messed up microbenchmark scores a > lot (15-80% overhead). I settled for simplifying the duplicate > permsMap.get in the outer method in a way that keeps scores neutral: > > http://cr.openjdk.java.net/~redestad/8247995/open.01/ > > Benchmark??????????????????????????????????? Mode? Cnt?? Score Error > Units > PermissionsImplies.withPermission??????????? avgt?? 15? 27.857 ? 0.137 > ns/op > PermissionsImplies.withUnresolvedPermission? avgt?? 15? 27.918 ? 0.178 > ns/op > PermissionsImplies.withoutPermission???????? avgt?? 15?? 4.559 ? 0.115 > ns/op > > Thanks! > > /Claes > > On 2020-06-22 23:54, Claes Redestad wrote: >> Hi Roger, >> >> I prototyped it as such, and saw a 0.4ns/op overhead in the >> PermissionImplies.withoutPermission. Thinking about it a bit now, this >> should be the rare path taken, since it means the permission is not >> implied and the performance largely irrelevant. I'll simplify as you >> suggested. >> >> /Claes >> >> On 2020-06-22 23:03, Roger Riggs wrote: >>> Hi Claes, >>> >>> Its correct as is but I would have written it without duplicating >>> the 'permsMap.get(p.getClass())' invocation >>> and as a single method (unless the inlining of >>> getPermissionCollection(p,create)) is important. >>> >>> A patch on top of yours: >>> >>> diff --git >>> a/src/java.base/share/classes/java/security/Permissions.java >>> b/src/java.base/share/classes/java/security/Permissions.java >>> --- a/src/java.base/share/classes/java/security/Permissions.java >>> +++ b/src/java.base/share/classes/java/security/Permissions.java >>> @@ -229,20 +229,16 @@ implements Serializable >>> ?????? */ >>> ????? private PermissionCollection >>> getPermissionCollection(Permission p, >>> boolean createEmpty) { >>> +??????? PermissionCollection pc = permsMap.get(p.getClass()); >>> ????????? if (!hasUnresolved && !createEmpty) { >>> ????????????? // Collection not to be created >>> -??????????? return permsMap.get(p.getClass()); >>> +??????????? return pc; >>> ????????? } >>> -??????? PermissionCollection pc = permsMap.get(p.getClass()); >>> ????????? if (pc != null) { >>> ????????????? // Collection already created >>> ????????????? return pc; >>> ????????? } >>> -??????? return createPermissionCollection(p, createEmpty); >>> -??? } >>> >>> -??? private PermissionCollection >>> createPermissionCollection(Permission p, >>> - boolean createEmpty) { >>> ????????? synchronized (permsMap) { >>> ????????????? Class c = p.getClass(); >>> ????????????? PermissionCollection pc = permsMap.get(c); >>> >>> Thanks, Roger >>> >>> >>> On 6/22/20 11:04 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> this patch fixes a corner-case performance issue with >>>> Permissions.implies(Permission) by not needing to allocate a mapper >>>> function (or lambda) on each invocation of getPermissionCollection >>>> when there are unresolved permissions present. >>>> >>>> Bug:?? https://bugs.openjdk.java.net/browse/JDK-8247995 >>>> Patch: http://cr.openjdk.java.net/~redestad/8247995/open.00/ >>>> >>>> Testing: tier1-2 >>>> >>>> Thanks! >>>> >>>> /Claes >>> From claes.redestad at oracle.com Mon Jun 22 22:35:13 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 23 Jun 2020 00:35:13 +0200 Subject: RFR: 8247995: Avoid use of a mapping function in Permissions.getPermissionCollection In-Reply-To: <54f5388b-c326-17f0-803e-57e01450ca4a@oracle.com> References: <85478146-abf3-0504-4108-9958d6041a4e@oracle.com> <8b987951-a332-0d69-3002-55dbe74a5dd4@oracle.com> <6006109b-f4c7-210b-40d1-106f956e1aa4@oracle.com> <54f5388b-c326-17f0-803e-57e01450ca4a@oracle.com> Message-ID: <22a7e89c-872e-ed73-6e13-e4117905e596@oracle.com> On 2020-06-23 00:30, Roger Riggs wrote: > Hi Claes, > > Looks good. Thanks! > > Thanks for the followup. No problem. /Claes > > Roger > > On 6/22/20 6:29 PM, Claes Redestad wrote: >> Hi, >> >> inlining the new method actually messed up microbenchmark scores a >> lot (15-80% overhead). I settled for simplifying the duplicate >> permsMap.get in the outer method in a way that keeps scores neutral: >> >> http://cr.openjdk.java.net/~redestad/8247995/open.01/ >> >> Benchmark??????????????????????????????????? Mode? Cnt?? Score Error >> Units >> PermissionsImplies.withPermission??????????? avgt?? 15? 27.857 ? 0.137 >> ns/op >> PermissionsImplies.withUnresolvedPermission? avgt?? 15? 27.918 ? 0.178 >> ns/op >> PermissionsImplies.withoutPermission???????? avgt?? 15?? 4.559 ? 0.115 >> ns/op >> >> Thanks! >> >> /Claes >> >> On 2020-06-22 23:54, Claes Redestad wrote: >>> Hi Roger, >>> >>> I prototyped it as such, and saw a 0.4ns/op overhead in the >>> PermissionImplies.withoutPermission. Thinking about it a bit now, this >>> should be the rare path taken, since it means the permission is not >>> implied and the performance largely irrelevant. I'll simplify as you >>> suggested. >>> >>> /Claes >>> >>> On 2020-06-22 23:03, Roger Riggs wrote: >>>> Hi Claes, >>>> >>>> Its correct as is but I would have written it without duplicating >>>> the 'permsMap.get(p.getClass())' invocation >>>> and as a single method (unless the inlining of >>>> getPermissionCollection(p,create)) is important. >>>> >>>> A patch on top of yours: >>>> >>>> diff --git >>>> a/src/java.base/share/classes/java/security/Permissions.java >>>> b/src/java.base/share/classes/java/security/Permissions.java >>>> --- a/src/java.base/share/classes/java/security/Permissions.java >>>> +++ b/src/java.base/share/classes/java/security/Permissions.java >>>> @@ -229,20 +229,16 @@ implements Serializable >>>> ?????? */ >>>> ????? private PermissionCollection >>>> getPermissionCollection(Permission p, >>>> boolean createEmpty) { >>>> +??????? PermissionCollection pc = permsMap.get(p.getClass()); >>>> ????????? if (!hasUnresolved && !createEmpty) { >>>> ????????????? // Collection not to be created >>>> -??????????? return permsMap.get(p.getClass()); >>>> +??????????? return pc; >>>> ????????? } >>>> -??????? PermissionCollection pc = permsMap.get(p.getClass()); >>>> ????????? if (pc != null) { >>>> ????????????? // Collection already created >>>> ????????????? return pc; >>>> ????????? } >>>> -??????? return createPermissionCollection(p, createEmpty); >>>> -??? } >>>> >>>> -??? private PermissionCollection >>>> createPermissionCollection(Permission p, >>>> - boolean createEmpty) { >>>> ????????? synchronized (permsMap) { >>>> ????????????? Class c = p.getClass(); >>>> ????????????? PermissionCollection pc = permsMap.get(c); >>>> >>>> Thanks, Roger >>>> >>>> >>>> On 6/22/20 11:04 AM, Claes Redestad wrote: >>>>> Hi, >>>>> >>>>> this patch fixes a corner-case performance issue with >>>>> Permissions.implies(Permission) by not needing to allocate a mapper >>>>> function (or lambda) on each invocation of getPermissionCollection >>>>> when there are unresolved permissions present. >>>>> >>>>> Bug:?? https://bugs.openjdk.java.net/browse/JDK-8247995 >>>>> Patch: http://cr.openjdk.java.net/~redestad/8247995/open.00/ >>>>> >>>>> Testing: tier1-2 >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>> > From jamil.j.nimeh at oracle.com Mon Jun 22 23:39:38 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 22 Jun 2020 16:39:38 -0700 Subject: RFR JDK-8239950: Update PKCS9 Attributes to PKCS#9 v2.0 Encodings In-Reply-To: <01174d9d-6c11-73c6-a69b-dcd906a23534@oracle.com> References: <424dd805-c3f6-f1de-eee9-0809364e31af@oracle.com> <4a7edac6-6611-820e-1ae2-edd09e6e294b@oracle.com> <6993DCD1-BFB3-4CD2-99F3-DF6D2CB232EC@oracle.com> <01174d9d-6c11-73c6-a69b-dcd906a23534@oracle.com> Message-ID: Hi Weijun, I've got a new webrev with the test vectors as hexdumps of the DER encoding.? Let me know what you think. https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.02 --Jamil On 6/22/20 7:56 AM, Jamil Nimeh wrote: > Sure, I have code in other tests to do the conversions into hexdumps > as well.? I'll convert those today and send a new review out.? Thanks > for looking this over, Max! > > --Jamil > > On 6/22/2020 12:42 AM, Weijun Wang wrote: >> Source change looks fine to me. >> >> One small suggestion: Is it possible to encode the bytes in the test >> as HEX instead of BASE64? If so, I can use my human eyes to look at >> the content. HexPrinter in test/lib can be used to generate them and >> Utils.toByteArray can be used to translate them back to byte[]. >> >> Thanks, >> Max >> >> >>> On Jun 22, 2020, at 12:07 PM, Jamil Nimeh >>> wrote: >>> >>> Ping... >>> >>> --Jamil >>> >>> On 6/4/20 10:55 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This brings a few PKCS#9 attributes (unstructuredName, >>>> unstructuredAddress, signingTime) into line with v2.0 of the spec >>>> (RFC 2985).? It mostly expands the allowed string or date types for >>>> these attributes.? I also came across a corner-case bug where >>>> toString calls on PKCS9Attribute objects were throwing NPE if the >>>> attribute type was a UniversalString, so that is addressed in this >>>> webrev too. >>>> >>>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.01 >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8239950 >>>> >>>> --Jamil >>>> From weijun.wang at oracle.com Tue Jun 23 02:37:54 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Jun 2020 10:37:54 +0800 Subject: RFR JDK-8239950: Update PKCS9 Attributes to PKCS#9 v2.0 Encodings In-Reply-To: References: <424dd805-c3f6-f1de-eee9-0809364e31af@oracle.com> <4a7edac6-6611-820e-1ae2-edd09e6e294b@oracle.com> <6993DCD1-BFB3-4CD2-99F3-DF6D2CB232EC@oracle.com> <01174d9d-6c11-73c6-a69b-dcd906a23534@oracle.com> Message-ID: Perfect, thank you for encoding exact 16 bytes on each line and have them aligned. Thanks, Max > On Jun 23, 2020, at 7:39 AM, Jamil Nimeh wrote: > > Hi Weijun, > > I've got a new webrev with the test vectors as hexdumps of the DER encoding. Let me know what you think. > > https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.02 > > --Jamil > > On 6/22/20 7:56 AM, Jamil Nimeh wrote: >> Sure, I have code in other tests to do the conversions into hexdumps as well. I'll convert those today and send a new review out. Thanks for looking this over, Max! >> >> --Jamil >> >> On 6/22/2020 12:42 AM, Weijun Wang wrote: >>> Source change looks fine to me. >>> >>> One small suggestion: Is it possible to encode the bytes in the test as HEX instead of BASE64? If so, I can use my human eyes to look at the content. HexPrinter in test/lib can be used to generate them and Utils.toByteArray can be used to translate them back to byte[]. >>> >>> Thanks, >>> Max >>> >>> >>>> On Jun 22, 2020, at 12:07 PM, Jamil Nimeh wrote: >>>> >>>> Ping... >>>> >>>> --Jamil >>>> >>>> On 6/4/20 10:55 PM, Jamil Nimeh wrote: >>>>> Hello all, >>>>> >>>>> This brings a few PKCS#9 attributes (unstructuredName, unstructuredAddress, signingTime) into line with v2.0 of the spec (RFC 2985). It mostly expands the allowed string or date types for these attributes. I also came across a corner-case bug where toString calls on PKCS9Attribute objects were throwing NPE if the attribute type was a UniversalString, so that is addressed in this webrev too. >>>>> >>>>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.01 >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8239950 >>>>> >>>>> --Jamil >>>>> From valerie.peng at oracle.com Tue Jun 23 22:31:38 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 23 Jun 2020 15:31:38 -0700 Subject: RFR JDK-8239950: Update PKCS9 Attributes to PKCS#9 v2.0 Encodings In-Reply-To: References: <424dd805-c3f6-f1de-eee9-0809364e31af@oracle.com> <4a7edac6-6611-820e-1ae2-edd09e6e294b@oracle.com> <6993DCD1-BFB3-4CD2-99F3-DF6D2CB232EC@oracle.com> <01174d9d-6c11-73c6-a69b-dcd906a23534@oracle.com> Message-ID: <3fd11b80-cd98-63b5-1484-e9f5e71cac26@oracle.com> Hi Jamil, I have a question: how about line 366 of DerValue.java? Do we just let the exception going upward if the UTF_32BE charset not found/supported? Thanks, Valerie On 6/22/2020 7:37 PM, Weijun Wang wrote: > Perfect, thank you for encoding exact 16 bytes on each line and have them aligned. > > Thanks, > Max > >> On Jun 23, 2020, at 7:39 AM, Jamil Nimeh wrote: >> >> Hi Weijun, >> >> I've got a new webrev with the test vectors as hexdumps of the DER encoding. Let me know what you think. >> >> https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.02 >> >> --Jamil >> >> On 6/22/20 7:56 AM, Jamil Nimeh wrote: >>> Sure, I have code in other tests to do the conversions into hexdumps as well. I'll convert those today and send a new review out. Thanks for looking this over, Max! >>> >>> --Jamil >>> >>> On 6/22/2020 12:42 AM, Weijun Wang wrote: >>>> Source change looks fine to me. >>>> >>>> One small suggestion: Is it possible to encode the bytes in the test as HEX instead of BASE64? If so, I can use my human eyes to look at the content. HexPrinter in test/lib can be used to generate them and Utils.toByteArray can be used to translate them back to byte[]. >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> On Jun 22, 2020, at 12:07 PM, Jamil Nimeh wrote: >>>>> >>>>> Ping... >>>>> >>>>> --Jamil >>>>> >>>>> On 6/4/20 10:55 PM, Jamil Nimeh wrote: >>>>>> Hello all, >>>>>> >>>>>> This brings a few PKCS#9 attributes (unstructuredName, unstructuredAddress, signingTime) into line with v2.0 of the spec (RFC 2985). It mostly expands the allowed string or date types for these attributes. I also came across a corner-case bug where toString calls on PKCS9Attribute objects were throwing NPE if the attribute type was a UniversalString, so that is addressed in this webrev too. >>>>>> >>>>>> Webrev: https://cr.openjdk.java.net/~jnimeh/reviews/8239950/webrev.01 >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8239950 >>>>>> >>>>>> --Jamil >>>>>> From daniel.fuchs at oracle.com Wed Jun 24 18:56:03 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 24 Jun 2020 19:56:03 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> Message-ID: <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> Hi Alexey, The JNDI/LDAP part looks mostly good. You will need someone from the security libs to review the security lib part of the changes. In the test I would recommend using the test URIBuilder to avoid strange intermittent errors if the test is run on a machine where looking up "localhost" doesn't yield back InetAddress.getLoopbackAddress(): ------------------ * @library /test/lib ... import java.net.URI; import jdk.test.lib.net.URIBuilder; ... URI uri = URIBuilder.newBuilder() .scheme("ldaps") .loopback() .port(serverPort) .build(); env.put(Context.PROVIDER_URL, uri.toString()); ------------------ So we have now two new properties: jdk.internal.sasl.tlschannelbinding which is a private contract between java.naming and jdk.security.jgss; com.sun.jndi.ldap.tls.cbtype which is a new JDK implementation specific environment property for the InitialLdapContext, and is depending on another JDK specific environment property: "com.sun.jndi.ldap.connect.timeout" None of these properties are currently documented in the JDK itself. Although jdk.internal.sasl.tlschannelbinding probably doesn't need to be documented (but I'll defer to the security experts for that), the other two probably should. Where is the question. If we had a jdk.namimg.ldap module then the documentation for these jndi properties would probably need to go in its module-info.java API documentation, but we don't. Obviously we will want to write a release note for this fix that documents the new com.sun.jndi.ldap.tls.cbtype property - but will that be sufficient? The CSR committee might wish for more. Anyone has advice to share on this? best regards, -- daniel On 17/06/2020 12:26, Alexey Bakhtin wrote: > Hello Daniel, > > Thank you for review. > > As you suggested I?ve added static factory methods to create TlsChannelBinding class and changed connectionTimeout verification to "if (connectTimeout <= 0)" > Also, I?ve added simple regression test to verify Channel Binding parameters. > > Please find updated webrev at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v8/ > > The link to CSR for this feature :https://bugs.openjdk.java.net/browse/JDK-8247311 > > Regards > Alexey From gnu.andrew at redhat.com Wed Jun 24 20:25:30 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 24 Jun 2020 21:25:30 +0100 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <73153f4a-184c-6848-1ca2-436377536cc4@redhat.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> <73153f4a-184c-6848-1ca2-436377536cc4@redhat.com> Message-ID: <4d99c712-d991-5dea-78c8-9915e6286177@redhat.com> On 22/06/2020 10:00, Andrew Haley wrote: > On 18/06/2020 19:33, Martin Balao wrote: snip... >> * L3724 >> * The last argument of 'sub' has type 'int', while in the not-Windows >> variant is a long. Can we align this? > > We should do that, yes. Better it be long everywhere. > Patch looks good to me too. Simon, if you are happy with changing the final argument of sub to long on the Windows side, I'll sponsor this patch, make that minor change and push: https://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/jdk.patch to jdk/jdk Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From stooke at redhat.com Wed Jun 24 20:43:16 2020 From: stooke at redhat.com (Simon Tooke) Date: Wed, 24 Jun 2020 16:43:16 -0400 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <4d99c712-d991-5dea-78c8-9915e6286177@redhat.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> <2442a046-6640-f759-6330-e971405f0c78@oracle.com> <6cb701cd-5652-6b9d-8051-b37adb3ce63f@oracle.com> <44d1daf2-7124-9b4b-b039-d35d1f8e96c6@oracle.com> <101b5758-3660-d2e4-e20a-ffc362907b45@redhat.com> <73153f4a-184c-6848-1ca2-436377536cc4@redhat.com> <4d99c712-d991-5dea-78c8-9915e6286177@redhat.com> Message-ID: <16119e79-8047-e781-6137-870b766f986c@redhat.com> On 2020-06-24 4:25 p.m., Andrew Hughes wrote: > On 22/06/2020 10:00, Andrew Haley wrote: >> On 18/06/2020 19:33, Martin Balao wrote: > snip... > >>> * L3724 >>> * The last argument of 'sub' has type 'int', while in the not-Windows >>> variant is a long. Can we align this? >> We should do that, yes. Better it be long everywhere. Sorry, I should have responded to this sooner. 'long' is 32 bits on Windows x64, and 64 bits on other platforms. sub() is only ever called with an 'int', so this change would actually cause the windows code to move to a jlong (i.e. int64_t), if we're talking about function signature. If we're only talking about aesthetics, the type 'long' works, but it's somewhat misleading and doesn't actually change the code >> > Patch looks good to me too. > > Simon, if you are happy with changing the final argument of sub to long > on the Windows side, I'll sponsor this patch, make that minor change and > push: I'm fine with this change, and thank you. > > https://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/01/01/jdk.patch > > to jdk/jdk > > Thanks, From ecki at zusammenkunft.net Wed Jun 24 20:58:20 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 24 Jun 2020 20:58:20 +0000 Subject: KWP instead of AESWrap Message-ID: Hello, JCE implements the AESWrap cipher, but it's does not offer the KWP mode of NIST 800-38F. KW and KWP use the same wrapping algorithm W which is also used by AESWrap, however do to different initialisation vectors the existing implementation can not be used to implement the padded wrapping. Is it possible to offer KWP as a special padding mode for AESWrap or have the W mode be it's own block mode so you can implement the padding externally? Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Jun 24 21:41:51 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 24 Jun 2020 14:41:51 -0700 Subject: KWP instead of AESWrap In-Reply-To: References: Message-ID: Hi Bernd, I filed https://bugs.openjdk.java.net/browse/JDK-8248268 on your behalf to track this enhancement. Is there additional info that you'd like me to enter into the issue? Thanks, Valerie On 6/24/2020 1:58 PM, Bernd Eckenfels wrote: > Hello, > > JCE implements the AESWrap cipher, but it's does not offer the KWP > mode of NIST 800-38F. KW and KWP use the same wrapping algorithm W > which is also used by AESWrap, however do to different initialisation > vectors the existing implementation can not be used to implement the > padded wrapping. > > Is it possible to offer KWP as a special padding mode for AESWrap or > have the W mode be it's own block mode so you can implement the > padding externally? > > Gruss > Bernd > > -- > http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Wed Jun 24 21:58:54 2020 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 24 Jun 2020 17:58:54 -0400 Subject: KWP instead of AESWrap In-Reply-To: References: Message-ID: On 6/24/2020 4:58 PM, Bernd Eckenfels wrote: > Hello, > > JCE implements the AESWrap cipher, but it's does not offer the KWP > mode of NIST 800-38F. KW and KWP use the same wrapping algorithm W > which is also used by AESWrap, however do to different initialisation > vectors the existing implementation can not be used to implement the > padded wrapping. > > Is it possible to offer KWP as a special padding mode for AESWrap or > have the W mode be it's own block mode so you can implement the > padding externally? > > Gruss > Bernd > > -- > http://bernd.eckenfels.net You probably know that BouncyCastle implements KWP? Reading the comments in the AESWrapCipher code, this was created against the XML encryption standards even though the underlying code is a straight implementation of RFC3394. Rather than twiddle with this current implementation and name mapping,? it may make more sense to redo this as a normal // mapping.? E.g. "AES/KeyWrap-NIST/NoPadding" or KWPPadding or AutoPadding? rather than the current "AESWrap".?? That would then allow for "ChaCha20/KeyWrap-NIST/AutoPadding" and others. I.e., copy the code from the current AESWrapCipher and convert it to a mode.? More work now, less later.? The AutoPadding would select the no padding if the encoded key size was a multiple of the block length, and the KWP padding if the encoded key size was not a multiple.? Or read the IV to determine which for unwrapping. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Jun 24 23:37:21 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 24 Jun 2020 16:37:21 -0700 Subject: KWP instead of AESWrap In-Reply-To: References: Message-ID: <14e7c3b0-9f9e-c87d-f3a7-b6cdaffb7d3e@oracle.com> Yes, the mode suggestion sounds reasonable. I will include all of the suggestions into the RFE for completeness sake. Thanks for the feedback, Valerie On 6/24/2020 2:58 PM, Michael StJohns wrote: > On 6/24/2020 4:58 PM, Bernd Eckenfels wrote: >> Hello, >> >> JCE implements the AESWrap cipher, but it's does not offer the KWP >> mode of NIST 800-38F. KW and KWP use the same wrapping algorithm W >> which is also used by AESWrap, however do to different initialisation >> vectors the existing implementation can not be used to implement the >> padded wrapping. >> >> Is it possible to offer KWP as a special padding mode for AESWrap or >> have the W mode be it's own block mode so you can implement the >> padding externally? >> >> Gruss >> Bernd >> >> -- >> http://bernd.eckenfels.net > > You probably know that BouncyCastle implements KWP? > > Reading the comments in the AESWrapCipher code, this was created > against the XML encryption standards even though the underlying code > is a straight implementation of RFC3394. > > Rather than twiddle with this current implementation and name > mapping,? it may make more sense to redo this as a normal > // mapping.? E.g. "AES/KeyWrap-NIST/NoPadding" or > KWPPadding or AutoPadding rather than the current "AESWrap".?? That > would then allow for "ChaCha20/KeyWrap-NIST/AutoPadding" and others. > > I.e., copy the code from the current AESWrapCipher and convert it to a > mode.? More work now, less later.? The AutoPadding would select the no > padding if the encoded key size was a multiple of the block length, > and the KWP padding if the encoded key size was not a multiple.? Or > read the IV to determine which for unwrapping. > > Mike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sibabrata.sahoo at oracle.com Thu Jun 25 09:11:00 2020 From: sibabrata.sahoo at oracle.com (sibabrata.sahoo at oracle.com) Date: Thu, 25 Jun 2020 14:41:00 +0530 Subject: [16] RFR: 8247968: test/jdk/javax/crypto/SecretKeyFactory/security.properties has wrong header Message-ID: <5F5A47D7-5EAE-4176-A251-D6882914E44F@oracle.com> Hi, Please review a minor fix for the following patch, JBS: https://bugs.openjdk.java.net/browse/JDK-8247968 Diff: diff -r 5f90d52615de test/jdk/javax/crypto/SecretKeyFactory/security.properties --- a/test/jdk/javax/crypto/SecretKeyFactory/security.properties Thu Jun 25 03:11:32 2020 +0200 +++ b/test/jdk/javax/crypto/SecretKeyFactory/security.properties Thu Jun 25 02:05:29 2020 -0700 @@ -1,6 +1,3 @@ -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. -# ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. - jdk.security.provider.preferred= jdk.jar.disabledAlgorithms= Change: Copyright header from the property file is removed as it is not necessary to have in a property file. Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Jun 25 10:38:53 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 25 Jun 2020 18:38:53 +0800 Subject: [16] RFR: 8247968: test/jdk/javax/crypto/SecretKeyFactory/security.properties has wrong header In-Reply-To: <5F5A47D7-5EAE-4176-A251-D6882914E44F@oracle.com> References: <5F5A47D7-5EAE-4176-A251-D6882914E44F@oracle.com> Message-ID: Hi Siba, Change looks fine to me. Thanks, Max > On Jun 25, 2020, at 5:11 PM, sibabrata.sahoo at oracle.com wrote: > > Hi, > > Please review a minor fix for the following patch, > JBS: https://bugs.openjdk.java.net/browse/JDK-8247968 > Diff: > > diff -r 5f90d52615de test/jdk/javax/crypto/SecretKeyFactory/security.properties > --- a/test/jdk/javax/crypto/SecretKeyFactory/security.properties Thu Jun 25 03:11:32 2020 +0200 > +++ b/test/jdk/javax/crypto/SecretKeyFactory/security.properties Thu Jun 25 02:05:29 2020 -0700 > @@ -1,6 +1,3 @@ > -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > -# ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. > - > jdk.security.provider.preferred= > jdk.jar.disabledAlgorithms= > > > Change: > Copyright header from the property file is removed as it is not necessary to have in a property file. > > Thanks, > Siba > > > From mikael.vidstedt at oracle.com Fri Jun 26 20:48:33 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 26 Jun 2020 13:48:33 -0700 Subject: RFR(T): 8248044: Backout ProblemList-ed tests introduced by JDK-8247876 Message-ID: <46302527-E3AE-4731-B4CF-DC572A655315@oracle.com> Please review this trivial change which reenables the tests which were problem listed because of a linux-aarch64 machine configuration issue which has since been fixed: Note: I intend to push this to jdk15. JBS: https://bugs.openjdk.java.net/browse/JDK-8248044 webrev: https://cr.openjdk.java.net/~mikael/webrevs/8248044/webrev.00/open/webrev Testing: I ran a few jobs and verified that the four tests passed (they did) and completed in reasonable times (they did). Cheers, Mikael From daniel.daugherty at oracle.com Fri Jun 26 20:56:04 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 26 Jun 2020 16:56:04 -0400 Subject: RFR(T): 8248044: Backout ProblemList-ed tests introduced by JDK-8247876 In-Reply-To: <46302527-E3AE-4731-B4CF-DC572A655315@oracle.com> References: <46302527-E3AE-4731-B4CF-DC572A655315@oracle.com> Message-ID: <3d906f92-d916-cc13-3968-fd05d056442b@oracle.com> Thumbs up. I agree that this is a trivial fix. Dan On 6/26/20 4:48 PM, Mikael Vidstedt wrote: > Please review this trivial change which reenables the tests which were problem listed because of a linux-aarch64 machine configuration issue which has since been fixed: > > Note: I intend to push this to jdk15. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8248044 > webrev: https://cr.openjdk.java.net/~mikael/webrevs/8248044/webrev.00/open/webrev > > Testing: > > I ran a few jobs and verified that the four tests passed (they did) and completed in reasonable times (they did). > > Cheers, > Mikael > From ikakavas at protonmail.com Mon Jun 29 05:14:19 2020 From: ikakavas at protonmail.com (Ioannis Kakavas) Date: Mon, 29 Jun 2020 05:14:19 +0000 Subject: SecureRandom regression with certain security providers Message-ID: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> Hi folks, Since the latest changes to SecureRandom[0], using certain ( I can reproduce with one but others might have the same issue, see below ) security providers, it is impossible to get an instance of SecurityRandom. The following is reproducible with the BouncyCastle FIPS 140-2 provider [1]: public class TestSecureRandom { public static void main(String[] args){ assert Security.getProviders()[0].getName().equals("BCFIPS"); SecureRandom random = new SecureRandom(); } } will fail with Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom attributes: {ImplementedIn=Software} at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) at java.base/java.security.SecureRandom.(SecureRandom.java:219) at TestSecureRandomBug.main(TestSecureRandomBug.java:8) Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom attributes: {ImplementedIn=Software} at java.base/java.security.Provider$Service.newInstance(Provider.java:1857) at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) ... 2 more I reported this to the authors of the security provider [2] and I will share part of the analysis on why this fails here for the sake of completeness of the report. The BCFIPS security provider overrides getService() and getServices() of Provider and it has its own extension of the Provider.Service which getService() returns. However, getDefaultSecureRandomService() will always return a java.security.Provider.Service and since we are calling newInstance [3] on it, this fails as the if (provider.getService(type, algorithm) != this) { throw new NoSuchAlgorithmException("Service not registered with Provider " + provider.getName() + ": " + this); } can not be true. getService will return a org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.BcService and `this` is a java.security.Provider.Service. I am not aware of other providers being affected by this ( the non FIPS BouncyCastle Provider is not, since it's a legacy style security provider ) but given the reason for the issue, I think there might be others affected. With [0] being backported to all supported versions and BCFIPS being one of the few available security providers that is FIPS 140-2 approved, this introduces a significant issue for folks with fips compliance requirements. One potential fix that was proposed in [2] was to replace if (prngServices != null && !prngServices.isEmpty()) { return prngServices.iterator().next(); } with: if (prngServices != null && !prngServices.isEmpty()) { Service rng = prngServices.iterator().next(); return getService(rng.getType(), rng.getAlgorithm()); } so that any provider extending Service, could work fine. Best Regards Ioannis [0] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff [1] https://www.bouncycastle.org/fips-java/ [2] http://bouncy-castle.1462172.n4.nabble.com/Default-SecureRandom-issue-in-BCFIPS-and-latest-JDK15-td4659964.html [3] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff#l2.55 From valerie.peng at oracle.com Mon Jun 29 20:55:40 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 29 Jun 2020 13:55:40 -0700 Subject: SecureRandom regression with certain security providers In-Reply-To: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> References: <2HnXazk66-nxoiS5rxih3yQnqfj2EePRDjdw0P7z8YN4Dr3iqR5WBcHoIM7U8ZIquneZ60ridpBTRPjuYaAmTvTZ11lOT2twH2PlEwzBfm8=@protonmail.com> Message-ID: <85ac45ca-28c7-a17b-57cb-b7f35d1ce731@oracle.com> Hi Ioannis, Thanks for reporting this issue and the detailed info. I've filed https://bugs.openjdk.java.net/browse/JDK-8248505 for this. It seems that this is mostly due to the mixing of both legacy and service-based registration in the BC provider not working well with the fix in JDK-8246613. Another possible fix may be to prefer the SecureRandom service object from the putService call. Anyway, I will take a look. Regards, Valerie On 6/28/2020 10:14 PM, Ioannis Kakavas wrote: > Hi folks, > > Since the latest changes to SecureRandom[0], using certain ( I can reproduce with one but others might have the same issue, see below ) security providers, it is impossible to get an instance of SecurityRandom. The following is reproducible with the BouncyCastle FIPS 140-2 provider [1]: > > public class TestSecureRandom { > > public static void main(String[] args){ > assert Security.getProviders()[0].getName().equals("BCFIPS"); > SecureRandom random = new SecureRandom(); > } > } > > will fail with > > Exception in thread "main" java.lang.RuntimeException: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom > attributes: {ImplementedIn=Software} > > at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:294) > at java.base/java.security.SecureRandom.(SecureRandom.java:219) > at TestSecureRandomBug.main(TestSecureRandomBug.java:8) > Caused by: java.security.NoSuchAlgorithmException: Service not registered with Provider BCFIPS: BCFIPS: SecureRandom.DEFAULT -> org.bouncycastle.jcajce.provider.random.DefSecureRandom > attributes: {ImplementedIn=Software} > > at java.base/java.security.Provider$Service.newInstance(Provider.java:1857) > at java.base/java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:290) > ... 2 more > > > I reported this to the authors of the security provider [2] and I will share part of the analysis on why this fails here for the sake of completeness of the report. > > The BCFIPS security provider overrides getService() and getServices() of Provider and it has its own extension of the Provider.Service which getService() returns. > However, getDefaultSecureRandomService() will always return a java.security.Provider.Service and since we are calling newInstance [3] on it, this fails as the > > if (provider.getService(type, algorithm) != this) { > throw new NoSuchAlgorithmException("Service not registered with Provider " + provider.getName() + ": " + this); > } > > can not be true. getService will return a org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider.BcService and `this` is a java.security.Provider.Service. > > > I am not aware of other providers being affected by this ( the non FIPS BouncyCastle Provider is not, since it's a legacy style security provider ) but given the reason for the issue, I think there might be others affected. With [0] being backported to all supported versions and BCFIPS being one of the few available security providers that is FIPS 140-2 approved, this introduces a significant issue for folks with fips compliance requirements. > > One potential fix that was proposed in [2] was to replace > > if (prngServices != null && !prngServices.isEmpty()) { > return prngServices.iterator().next(); > } > > with: > > if (prngServices != null && !prngServices.isEmpty()) { > Service rng = prngServices.iterator().next(); > return getService(rng.getType(), rng.getAlgorithm()); > } > > so that any provider extending Service, could work fine. > > Best Regards > Ioannis > > > [0] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff > [1] https://www.bouncycastle.org/fips-java/ > [2] http://bouncy-castle.1462172.n4.nabble.com/Default-SecureRandom-issue-in-BCFIPS-and-latest-JDK15-td4659964.html > [3] https://hg.openjdk.java.net/jdk/jdk15/rev/6eeaa40131ff#l2.55 From alexey at azul.com Tue Jun 30 12:22:55 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 30 Jun 2020 12:22:55 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> Message-ID: Hello Daniel, Thank you for review. I have updated LdapCBPropertiesTest according to your comments. Updated webrev at http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v9/ Regards Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sean.coffey at oracle.com Tue Jun 30 13:51:57 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 30 Jun 2020 14:51:57 +0100 Subject: RFR: 8218021: Have jarsigner preserve posix permission attributes In-Reply-To: References: <6a34a99c-ed06-5e38-0932-788e944a70df@oracle.com> <22AD74BE-6E90-45CA-AEEF-73E5FCCC0BF5@oracle.com> <60ef9824-bb1c-9ff1-11a8-76290f8f8882@oracle.com> Message-ID: <9903a925-a93e-d712-1d6c-80db047e2907@oracle.com> Thanks Lance. During the CSR review, a suggestion was made to have jarsigner preserve such attributes by default. Warnings about these attributes will also be added during signing and verify operations (if detected). webrev: https://cr.openjdk.java.net/~coffeys/webrev.8218021.v4/webrev/ regards, Sean. On 22/06/2020 17:17, Lance Andersen wrote: > HI Sean, > > Looks OK based on our exchanges. ?Thank you for your time on this one! > > Best > Lance > >> On Jun 22, 2020, at 7:22 AM, Se?n Coffey > > wrote: >> >> Thanks Lance. >> >> I've updated the patch with some extra offline feedback from yourself >> and Max. >> A new warning is printed with use of the new flag. A warning is also >> printed when file posix permissions are detected on resources being >> signed. Test updated for that also. >> >> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/ >> >> regards, >> Sean. >> >> On 12/06/2020 17:05, Lance Andersen wrote: >>> Hi Sean, >>> >>> I think your changes look fine so all good FMPOV. >>> >>> Best >>> Lance >>> >>>> On Jun 12, 2020, at 6:21 AM, Se?n Coffey >>> > wrote: >>>> >>>> Hi, >>>> >>>> I'd like to reboot this jarsigner enhancement request[1]. I've >>>> removed the problem references to zip file name extensions. >>>> Instead, there's a new JDK implementation specific jarsigner >>>> option: -keepposixperms >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8218021 >>>> https://cr.openjdk.java.net/~coffeys/webrev.8218021.v2/webrev/ >>>> >>>> regards, >>>> Sean. >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2020-January/021141.html >>>> >>> >>> >>> >>> >>> Lance >>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle?Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From michael.osipov at siemens.com Tue Jun 30 14:57:22 2020 From: michael.osipov at siemens.com (Osipov, Michael) Date: Tue, 30 Jun 2020 16:57:22 +0200 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> Message-ID: <37729529-1c91-222e-1ba6-8a3dcae824e5@siemens.com> Am 2020-06-30 um 14:22 schrieb Alexey Bakhtin: > Hello Daniel, > > Thank you for review. > I have updated LdapCBPropertiesTest according to your comments. > Updated webrev at http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v9/ A few notes > + throw new NamingException(TlsChannelBinding.CHANNEL_BINDING_TYPE + > + " property requires " + > + "com.sun.jndi.ldap.connect.timeout property is set."); "...requires ... to be set." The current text reads strange in English. > + env.get("jdk.internal.sasl.tlschannelbinding") != null) { and alike. Any reason to use the literal instead of the static symbol? Module import issues? In TlsChannelBinding.java: > + // TLS channel binding type property > + public static final String CHANNEL_BINDING_TYPE = > + "com.sun.jndi.ldap.tls.cbtype"; and > + public static TlsChannelBindingType parseType(String prop) throws NamingException { TLS channel binding is not tied to LDAP, it can be used with other protocols, even custom ones. I see no good reason to have the property contain jndi.ldap or use NamingException. IllegalArgumentException would be approriate here. Also on this class you have the wonderful enum TlsChannelBindingType, but still use litrals throughout for the possible values. Why? Why isn't this class part of the Sun SASL impl? > #parseType() I would not use the term 'prop'. I miss the loose coupling here. Ideally, the class does not even know that is might be passed around with a env property from LDAP, SMTP, foo protocol to SASL. It is merely a record to contain the calculcated data. I'd remove all props from here. TlsChannelBindingImpl.java: I like this idea. This basically solves the problem with the same approach I have proposed from the first time, a specialized subimpl, but this time not for the address, but for the binding type. Nice! I consider this webrev version much much better than v1. I really miss the TLS Channel Binding abstraction from LDAP. The current situation bascially means that no one with Java can implement TLS-CB with anything else than the Sun JNDI LDAP provider over SASL. Kind of disappointing. Michael From daniel.fuchs at oracle.com Tue Jun 30 17:40:11 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 30 Jun 2020 18:40:11 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <37729529-1c91-222e-1ba6-8a3dcae824e5@siemens.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <3E55A2A4-6B7B-4F2A-90B6-A32CE691DDF2@azul.com> <9013C8D0-33D9-4D09-8953-F8618020A7F7@oracle.com> <8A2C4DEF-FC61-4574-B49D-1133F5349BCE@azul.com> <15fa46f2-0352-a111-a9c7-0d5fc31d9159@oracle.com> <6167ea24-e7f9-c259-e2c5-8be96d74a40d@oracle.com> <228BA21D-836A-46D7-B273-738AFFE639E4@azul.com> <97a4f719-e0f5-96f7-6637-432b4b746685@oracle.com> <567C1F82-0EE7-46F3-90E9-3A1B5FDD5E13@azul.com> <959ffeaa-a8ef-87fb-6a21-0f125fa3d891@oracle.com> <37729529-1c91-222e-1ba6-8a3dcae824e5@siemens.com> Message-ID: <7145f0b2-3559-8bcb-6182-4bbbda8e2134@oracle.com> Hi Michael, On 30/06/2020 15:57, Osipov, Michael wrote: > TLS channel binding is not tied to LDAP, it can be used with other > protocols, even custom ones. I see no good reason to have the property > contain jndi.ldap or use NamingException. IllegalArgumentException would > be approriate here It is not appropriate for new InitialContext() to throw IllegalArgumentException. I would be thrilled if everything could be handled in the security libs and the SASL implementation but AFAICT some interaction from the JNDI code is still required. At the moment the only place where this property is used is with the LDAP provider so I believe com.sun.jndi.ldap is appropriate for this changeset. best regards, -- daniel From francois.lamoureux at rsa.com Fri Jun 5 12:25:33 2020 From: francois.lamoureux at rsa.com (Lamoureux, Francois) Date: Fri, 05 Jun 2020 12:25:33 -0000 Subject: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering In-Reply-To: References: <41a876c7-eb8d-dc40-5c8d-bd876a3b1368@oracle.com> <2ecde92d-16eb-3e89-026d-0017b8d55732@oracle.com> Message-ID: Likewise, planning for the future, should a new JDK property such as "jdk.securerandom.disabledAlgorithms" be implemented, which could impact the value returned from getDefaultSecureRandomAlgorithm() ? Thanks, Fran?ois -----Original Message----- From: security-dev On Behalf Of Prasadrao Koppula Sent: Friday, June 5, 2020 1:44 AM To: Valerie Peng; security-dev at openjdk.java.net Subject: RE: [15] RFR JDK-8246613: Choose the default SecureRandom algo based on registration ordering [EXTERNAL EMAIL] Hi, Looks good to me, one question If first registered SecureRandom algo gets removed, getDefaultSecureRandomAlgorithm return stale data, a refresh required in remove? Thanks, Prasad.K >-----Original Message----- >From: Valerie Peng >Sent: Friday, June 5, 2020 2:52 AM >To: security-dev at openjdk.java.net >Subject: Re: [15] RFR JDK-8246613: Choose the default SecureRandom algo >based on registration ordering > >Hi, Sean, > >Thanks for the review and feedback. Webrev updated: >http://cr.openjdk.java.net/~valeriep/8246613/webrev.01/ > >getTypeAndAlgorithm(...) was not static due to an instance variable >used by debugging output. I have removed it and made both method static. > >I will wait for others' review comments also. > >Thanks, >Valerie >On 6/4/2020 2:01 PM, Sean Mullan wrote: >> On 6/4/20 3:34 PM, Valerie Peng wrote: >>> Hi, >>> >>> Could someone help reviewing this fix? This change keep tracks of >>> the first registered SecureRandom algorithm and returns it upon the >>> request of SecureRandom class. >> >> This looks good to me. I would recommend that Max or someone else >> review it as well. >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246613 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8246613/webrev.00/ >> >> A couple of minor comments, feel free to fix or ignore. >> >> * SecureRandom.java >> >> 879???????????? // For SUN provider, we use >> SunEntries.DEFF_SECURE_RANDOM_ALGO >> >> Might as well fix the typo while you are in there: s/DEFF/DEF/ >> >> * Provider.java >> >> 1156???? private String parseSecureRandomPut(String name, String >> value) { >> >> Could be static if you also make getTypeAndAlgorithm static, I think. >> >> --Sean