From pgnet.dev at gmail.com Thu Aug 1 00:46:57 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Wed, 31 Jul 2019 17:46:57 -0700 Subject: TLSv1.3 TLS_CHACHA20_POLY1305_SHA256 ciphersuite support/backport for JDK 11 LTS ? Message-ID: Although JDK 11 already contains TLSv1.3 protocol support. TLS 1.3 Implementation https://bugs.openjdk.java.net/browse/JDK-8202625 JDK-8145252 : JEP 332: Transport Layer Security (TLS) 1.3 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8145252 and, 'related' bugs suggest ChaCha20 cipher support is 'in', JDK-8153029 : ChaCha20 Cipher Implementation (11 b17, "Fixed") https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8140466 JDK-8140466 : ChaCha20 and Poly1305 TLS Cipher Suites https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8140466 (12 b12, "Fixed") TLSv1.3 connections via JDBC, using TSLv1.3 + its ChaCha20 cipher FAILed here, Error: Unsupported SSL cipher 'TLS_CHACHA20_POLY1305_SHA256' It appears that JDK 11 release supports only 2 of the 3 default TLSv1.3 ciphersuites, https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names ... 0x13,0x01 TLS_AES_128_GCM_SHA256 Yes No N/A TLSv1.3 RFC 8446 0x13,0x02 TLS_AES_256_GCM_SHA384 Yes No N/A TLSv1.3 RFC 8446 ... JDK12 adds ChaCha20 support, https://docs.oracle.com/en/java/javase/12/docs/specs/security/standard-names.html#jsse-cipher-suite-names ... 0x13,0x01 TLS_AES_128_GCM_SHA256 Yes No N/A TLSv1.3 RFC 8446 0x13,0x02 TLS_AES_256_GCM_SHA384 Yes No N/A TLSv1.3 RFC 8446 >> 0x13,0x03 TLS_CHACHA20_POLY1305_SHA256 No No N/A TLSv1.3 RFC 7905 ... TLSv1.2/ChaCha20 connections with BOTH JDK 11 & 12 clients work. ONLY, TLSv1.3/ChaCha20 connections with JDK 12 client work without error. Is there a current plan/work to backport TLSv1.3/ChaCha20 support to JDK 11 LTS so it, too, can provide 'full' TLSv1.3 ciphersuite support? From sean.mullan at oracle.com Thu Aug 1 21:02:40 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 1 Aug 2019 17:02:40 -0400 Subject: [13] RFR 8228431: sun/security/tools/jarsigner/PreserveRawManifestEntryAndDigest.java fails intermittently on solaris In-Reply-To: References: <82F2FCDF-ACA1-4435-A629-DBF393ACAA7B@oracle.com> <97441EBB-3F30-49CD-988B-4C8D49EFAF12@oracle.com> <713ea305-3832-c85b-2651-769711d0b44c@oracle.com> <30FE7A0D-9C16-4B85-A1F7-F50313E23DE1@oracle.com> Message-ID: On 7/31/19 1:30 PM, Valerie Peng wrote: > > I think it's easier to just skip this test for Solaris if this test runs > fine on all other non-Solaris platforms. I would leave it in the ProblemList (for solaris-all) and leave 8228431 open -- this way we still have an open issue if someone needs to look further into the ucrypto issue later on. --Sean > > Just my .02, > Valerie > On 7/30/2019 11:48 PM, Weijun Wang wrote: >> >>> On Jul 31, 2019, at 1:11 PM, Xuelei Fan wrote: >>> >>> I'm fine as well if you want to exclude the test for Solaris >>> platforms (my preference).? But please file a new bug if you find >>> something unusual for Solaris platforms. >> Why file a new bug if this one already exists? >> >> Since the bug is now in problem list for solaris, and I am quite >> confident this is related to ucrypto. Is it better to leave it open >> and delay it to a future release? I can now reproduce the failure on a >> solaris machine but if I simplify the test into only the single method >> that triggers the error, the test succeeds. Maybe many calls into >> ucrypto has corrupted the internal state and a final update call >> destroys it. >> >> Thanks, >> Max >> >> From weijun.wang at oracle.com Fri Aug 2 07:28:06 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 2 Aug 2019 15:28:06 +0800 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> Message-ID: > On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Can you please explain why not simple PEM bundles like OpenSSL have been > chosen? Is that /etc/ssl/certs on Ubuntu? It's a directory containing a lot of PEM files. Do you prefer this style or a big file containing multiple PEM blocks? Thanks, Max > This could have eased maintenance by factors, plus it is easy > greppable. From sha.jiang at oracle.com Fri Aug 2 08:29:46 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 2 Aug 2019 16:29:46 +0800 Subject: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests Message-ID: Hi, This enhancement provides a set of utilities for creating certificate, trust/key store and SSL context. It provides the default trust and key stores with RSA, ECDSA, RSASSA-PSS and DSA certificates, and also the default TLS and DTLS contexts with the default trust and key stores. Three tests are modified for demonstrating the usages. Webrev: http://cr.openjdk.java.net/~jjiang/8228967/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8228967 Best regards, John Jiang From 1983-01-06 at gmx.net Fri Aug 2 09:20:55 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Fri, 2 Aug 2019 11:20:55 +0200 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> Message-ID: > > On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > > > Can you please explain why not simple PEM bundles like OpenSSL have been > > chosen? > > Is that /etc/ssl/certs on Ubuntu? It's a directory containing a lot of PEM files. Do you prefer this style or a big file containing multiple PEM blocks? Hi Max, I prefer the latter. This works flawlessly for OpenSSL-based apps on FreeBSD, RHEL and HP-UX for me: RHEL: $ ll /etc/ssl/certs/ca-bundle.crt lrwxrwxrwx. 1 root root 49 2018-11-02 15:15 /etc/ssl/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem FreeBSD: # ll /usr/local/etc/ssl/cert.pem -rw-r--r-- 1 root wheel 1073753 2019-07-31 10:14 /usr/local/etc/ssl/cert.pem HP-UX: # ll /opt/openssl/cert.pem -rw-r--r-- 1 root sys 1081003 2019-04-18 11:45 /opt/openssl/cert.pem These bundles contain public-known CAs from Mozilla as well as all intermediate and root CAs from our company: https://new.siemens.com/global/en/general/legal/ca-certificates.html I think this is the function doing the magic: https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_load_verify_locations.html Michael From weijun.wang at oracle.com Fri Aug 2 09:59:45 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 2 Aug 2019 17:59:45 +0800 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> Message-ID: Great. This is also easy for me. --Max > On Aug 2, 2019, at 5:20 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: > >>> On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>> >>> Can you please explain why not simple PEM bundles like OpenSSL have been >>> chosen? >> >> Is that /etc/ssl/certs on Ubuntu? It's a directory containing a lot of PEM files. Do you prefer this style or a big file containing multiple PEM blocks? > > Hi Max, > > I prefer the latter. This works flawlessly for OpenSSL-based apps on FreeBSD, RHEL and HP-UX for me: > > RHEL: > $ ll /etc/ssl/certs/ca-bundle.crt > lrwxrwxrwx. 1 root root 49 2018-11-02 15:15 /etc/ssl/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem > FreeBSD: > # ll /usr/local/etc/ssl/cert.pem > -rw-r--r-- 1 root wheel 1073753 2019-07-31 10:14 /usr/local/etc/ssl/cert.pem > HP-UX: > # ll /opt/openssl/cert.pem > -rw-r--r-- 1 root sys 1081003 2019-04-18 11:45 /opt/openssl/cert.pem > > These bundles contain public-known CAs from Mozilla as well as all intermediate and root CAs from our company: > https://new.siemens.com/global/en/general/legal/ca-certificates.html > > I think this is the function doing the magic: https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_load_verify_locations.html > > Michael From sean.mullan at oracle.com Fri Aug 2 11:26:01 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 2 Aug 2019 07:26:01 -0400 Subject: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests In-Reply-To: References: Message-ID: Not a full review but there is already a utility class for creating certificates, etc in test/jdk/java/security/testlibrary/CertUtils.java Could you combine/merge that with your new CertUtils class? --Sean On 8/2/19 4:29 AM, sha.jiang at oracle.com wrote: > Hi, > This enhancement provides a set of utilities for creating certificate, > trust/key store and SSL context. > It provides the default trust and key stores with RSA, ECDSA, RSASSA-PSS > and DSA certificates, and also the default TLS and DTLS contexts with > the default trust and key stores. > Three tests are modified for demonstrating the usages. > > Webrev: http://cr.openjdk.java.net/~jjiang/8228967/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8228967 > > Best regards, > John Jiang > From 1983-01-06 at gmx.net Fri Aug 2 17:37:30 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Fri, 2 Aug 2019 19:37:30 +0200 Subject: RFR CSR for 8162628: Migrating cacerts keystore to password-less PKCS12 format In-Reply-To: References: <4597F51E-BE33-4081-BE99-0B9710375CE9@oracle.com> Message-ID: Thank you, looking forward to. Am 2019-08-02 um 11:59 schrieb Weijun Wang: > Great. This is also easy for me. > > --Max > >> On Aug 2, 2019, at 5:20 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >>>> On Jun 1, 2019, at 7:17 PM, Michael Osipov <1983-01-06 at gmx.net> wrote: >>>> >>>> Can you please explain why not simple PEM bundles like OpenSSL have been >>>> chosen? >>> >>> Is that /etc/ssl/certs on Ubuntu? It's a directory containing a lot of PEM files. Do you prefer this style or a big file containing multiple PEM blocks? >> >> Hi Max, >> >> I prefer the latter. This works flawlessly for OpenSSL-based apps on FreeBSD, RHEL and HP-UX for me: >> >> RHEL: >> $ ll /etc/ssl/certs/ca-bundle.crt >> lrwxrwxrwx. 1 root root 49 2018-11-02 15:15 /etc/ssl/certs/ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem >> FreeBSD: >> # ll /usr/local/etc/ssl/cert.pem >> -rw-r--r-- 1 root wheel 1073753 2019-07-31 10:14 /usr/local/etc/ssl/cert.pem >> HP-UX: >> # ll /opt/openssl/cert.pem >> -rw-r--r-- 1 root sys 1081003 2019-04-18 11:45 /opt/openssl/cert.pem >> >> These bundles contain public-known CAs from Mozilla as well as all intermediate and root CAs from our company: >> https://new.siemens.com/global/en/general/legal/ca-certificates.html >> >> I think this is the function doing the magic: https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_load_verify_locations.html >> >> Michael > > From valerie.peng at oracle.com Sat Aug 3 00:08:37 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 2 Aug 2019 17:08:37 -0700 Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. In-Reply-To: <680c3821-de1e-5f17-0e8b-765837eca888@oracle.com> References: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> <6563F381B547594081EF9DE181D079129615C797@fmsmsx123.amr.corp.intel.com> <7944585b-924c-ee2f-7880-ea8566c2b608@oracle.com> <8D6F463991A1574A8A803B8DA605414F411880D8@ORSMSX111.amr.corp.intel.com> <8D6F463991A1574A8A803B8DA605414F4118A53C@ORSMSX111.amr.corp.intel.com> <11bc5dad-0787-193b-fe69-9bf568f377f0@oracle.com> <8D6F463991A1574A8A803B8DA605414F4118E5B4@ORSMSX111.amr.corp.intel.com> <680c3821-de1e-5f17-0e8b-765837eca888@oracle.com> Message-ID: <4af33597-6c91-4cda-0c44-29a9e83678b3@oracle.com> Changes to the ElectronicCodeBook.java looks fine to me. Thanks, Valerie* * On 7/31/2019 2:38 PM, Vladimir Kozlov wrote: > Good. Lets wait review from security team. > > Thank you > Vladimir > > On 7/31/19 2:20 PM, Rukmannagari, Shravya wrote: >> Hi Vladimir, >> Thanks a lot for the review. I have responded to the JBS bug with the >> use cases for ECB. Please find the updated webrev with no changes to >> the config file. >> http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.02/ >> >> Thanks, >> Shravya. >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Sunday, July 28, 2019 3:31 PM >> To: Rukmannagari, Shravya ; Kamath, >> Smita ; 'Anthony Scarpino' >> >> Cc: Viswanathan, Sandhya ; Deshpande, >> Vivek R ; 'hotspot compiler' >> ; Shemy, Regev >> ; OpenJDK Security >> >> Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) >> encryption and decryption optimizations using AVX512 + VAES >> instructions. >> >> CCing to security-dev since you touched their class. >> >> Please answer Sean's question in the bug report. >> >> I don't think .jcheck/conf change should be part of this. >> >> Thanks, >> Vladimir >> >> On 7/23/19 1:44 PM, Rukmannagari, Shravya wrote: >>> Hi Vladimir, >>> I have updated the patch as per your suggestions. The JMH test >>> test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java has been >>> modified to add support for different key lengths. Please take a look >>> and let me know if you have any questions or comments. >>> http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.01/ >>> >>> Thanks, >>> Shravya. >>> >>> -----Original Message----- >>> From: Rukmannagari, Shravya >>> Sent: Monday, July 22, 2019 7:52 AM >>> To: Vladimir Kozlov ; Kamath, Smita >>> ; 'Anthony Scarpino' >>> >>> Cc: Viswanathan, Sandhya ; Deshpande, >>> Vivek R ; 'hotspot compiler' >>> ; Shemy, Regev >>> >>> Subject: RE: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) >>> encryption and decryption optimizations using AVX512 + VAES >>> instructions. >>> >>> Hi Vladimir, >>> For checking the correctness, we have run the >>> hotspot/jtreg/compiler/codegen/aes/TestAESMain.java and the entire >>> jtreg test suite. For the JMH benchmark tests, >>> test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java tests >>> ECB for a key length of 128. I will extend the test for other key >>> lengths and send out an updated patch. >>> >>> Thanks, >>> Shravya. >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Thursday, July 18, 2019 4:02 PM >>> To: Kamath, Smita ; 'Anthony Scarpino' >>> >>> Cc: Viswanathan, Sandhya ; >>> Rukmannagari, Shravya ; Deshpande, >>> Vivek R ; 'hotspot compiler' >>> ; Shemy, Regev >>> >>> Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) >>> encryption and decryption optimizations using AVX512 + VAES >>> instructions. >>> >>> Hi Smita >>> >>> I looked on changes and they seem fine in general (mostrly copy/past >>> of cipherBlockChaining code). >>> >>> Few comments: >>> >>> Don't use _AVX3 in macroasm method names because you have only >>> avx512 implementation. >>> >>> Indentions are bad in inline_electronicCodeBook_AESCrypt(). >>> >>> Add test to check results of optimization. >>> >>> Would be nice to have JMH test to see performance benefits. >>> >>> You also need to add checks to Graal's test [1] to prevent failure >>> until this intrinsic is implemented in Graal. >>> >>> Thanks, >>> Vladimir >>> >>> [1] >>> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspo >>> t.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java >>> >>> On 6/26/19 4:27 PM, Kamath, Smita wrote: >>>> Hi All, >>>> >>>> Could you please review AES-ECB implemented using AVX512+VAES >>>> instructions. >>>> >>>> Thanks and Regards, >>>> >>>> Smita Kamath >>>> >>>> *From:* Kamath, Smita >>>> *Sent:* Tuesday, June 11, 2019 4:23 PM >>>> *To:* 'Vladimir Kozlov' ; Anthony >>>> Scarpino >>>> *Cc:* Viswanathan, Sandhya ; Shravya >>>> Rukmannagari >>>> (shravya.rukmannagari at intel.com) ; >>>> hotspot compiler ; Shemy, >>>> Regev >>>> *Subject:* RFR(S) JDK-8225625: AES Electronic Codebook (ECB) >>>> encryption and decryption optimizations using AVX512 + VAES >>>> instructions. >>>> >>>> Hi Vladimir, >>>> >>>> As per Intel Architecture Instruction Set Reference [1] Vector AES >>>> Encrypt and Decrypt Operations will be supported in future Intel ISA. >>>> We would like to contribute optimizations for AES-ECB algorithm to >>>> support encryption and decryption operations using AVX512+VAES >>>> instructions. These optimizations are for x86_64 architecture that >>>> have AVX512-VAES enabled. >>>> >>>> Shravya(cc'ed) and I are co-contributors. Shay >>>> Gueron(shay.gueron at intel.com >>>> ) and Regev Shemy >>>> (regev.shemy at intel.com >>>> ) are the authors of the algorithm. >>>> >>>> I have tested the algorithm with Intel SDE [2] to confirm encoding >>>> and semantics are correctly implemented. >>>> >>>> Please take a look and let me know if you have any questions or >>>> comments. >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.00/ >>>> >>>> Bug Id: https://bugs.openjdk.java.net/browse/JDK-8225625 >>>> >>>> [1] >>>> https://software.intel.com/sites/default/files/managed/ad/01/253666-s >>>> d >>>> m-vol-2a.pdf ?(Page 152 - 159) >>>> >>>> [2] >>>> https://software.intel.com/en-us/articles/intel-software-development- >>>> e >>>> mulator >>>> >>>> Regards, >>>> >>>> Smita Kamath >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Sat Aug 3 00:26:34 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 2 Aug 2019 17:26:34 -0700 Subject: [14] RFR Release Note for JDK-8180392 "SunJCE provider should throw exceptions for unsupported mode and padding combinations" Message-ID: <497361c6-3be5-1a48-4787-3c08b5bc03c5@oracle.com> Adding a release note as Sean suggested. Please review it at https://bugs.openjdk.java.net/browse/JDK-8229043 Thanks, Valerie From sha.jiang at oracle.com Sat Aug 3 23:32:11 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Sun, 4 Aug 2019 07:32:11 +0800 Subject: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests In-Reply-To: References: Message-ID: Hi Sean, I moved test/jdk/java/security/testlibrary/CertUtils.java? to test/lib/jdk/test/lib/security/CertUtils.java, and added the new methods to this class. The affected existing tests are also modified. http://cr.openjdk.java.net/~jjiang/8228967/webrev.01/ Best regards, John Jiang On 2019/8/2 19:26, Sean Mullan wrote: > Not a full review but there is already a utility class for creating > certificates, etc in test/jdk/java/security/testlibrary/CertUtils.java > Could you combine/merge that with your new CertUtils class? > > --Sean > > On 8/2/19 4:29 AM, sha.jiang at oracle.com wrote: >> Hi, >> This enhancement provides a set of utilities for creating >> certificate, trust/key store and SSL context. >> It provides the default trust and key stores with RSA, ECDSA, >> RSASSA-PSS and DSA certificates, and also the default TLS and DTLS >> contexts with the default trust and key stores. >> Three tests are modified for demonstrating the usages. >> >> Webrev: http://cr.openjdk.java.net/~jjiang/8228967/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8228967 >> >> Best regards, >> John Jiang >> > From sean.mullan at oracle.com Mon Aug 5 13:10:14 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 5 Aug 2019 09:10:14 -0400 Subject: [14] RFR Release Note for JDK-8180392 "SunJCE provider should throw exceptions for unsupported mode and padding combinations" In-Reply-To: <497361c6-3be5-1a48-4787-3c08b5bc03c5@oracle.com> References: <497361c6-3be5-1a48-4787-3c08b5bc03c5@oracle.com> Message-ID: <852b6eb7-6953-3dc3-c45b-3ccffe86acfc@oracle.com> Reviewed. Please mark Delivered. --Sean On 8/2/19 8:26 PM, Valerie Peng wrote: > > Adding a release note as Sean suggested. > > Please review it at https://bugs.openjdk.java.net/browse/JDK-8229043 > > Thanks, > Valerie From valerie.peng at oracle.com Wed Aug 7 00:59:33 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 6 Aug 2019 17:59:33 -0700 Subject: [14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic" Message-ID: Anyone can help review this fix? SUN provider supports multiple impls of SecureRandom and rely on the ordering of the set returned by Provider.getServices() to choose the most preferred RNG algo for new SecureRandom() calls. Instead of maintaining the ordering, I think it's faster and more robust to use an alias "DEFAULT" to indicate the most preferred RNG algo for SUN provider. Bug: https://bugs.openjdk.java.net/browse/JDK-8228613 Webrev: http://cr.openjdk.java.net/~valeriep/8228613/webrev.00/ Thanks, Valerie From valerie.peng at oracle.com Wed Aug 7 02:28:21 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 6 Aug 2019 19:28:21 -0700 Subject: [14] RFR JDK-8228835 "Memory leak in PKCS11 provider when using AES GCM" Message-ID: <86ddf8f4-7fd4-4e6d-2364-043d351cb4bc@oracle.com> Anyone have spare cycles for reviewing this? The current PKCS11 JNI code for handling native mechanism and its parameters is a bit too all over the place. To make the tracing and verification easier, I consolidated the memory deallocation to the freeCKMechanismPtr(...) method in p11_util.c (some was in p11_keymgmt.c). Also, fixed the j_XXX_ToCK_XXXX_ methods in p11_convert.c to allocate the memory inside each method and return NULL upon error and make sure allocated memories are free'd upon any failure. Bug: https://bugs.openjdk.java.net/browse/JDK-8228835 Webrev: http://cr.openjdk.java.net/~valeriep/8228835/webrev.00/ Mach5 run is clean. Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed Aug 7 02:34:29 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 6 Aug 2019 19:34:29 -0700 Subject: [14] RFR JDK-8229214 "Don't use GCM with PKCS5Padding in test/micro/org/openjdk/bench/javax/crypto/" Message-ID: <1fab97af-fd1d-7dee-56d3-3ae936ddd9e1@oracle.com> Anyone can help review this trivial test update? Bug: https://bugs.openjdk.java.net/browse/JDK-8229214 Webrev: http://cr.openjdk.java.net/~valeriep/8229214/webrev.00/ Thanks, Valerie From Xuelei.Fan at Oracle.Com Wed Aug 7 02:46:17 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 6 Aug 2019 19:46:17 -0700 Subject: [14] RFR JDK-8229214 "Don't use GCM with PKCS5Padding in test/micro/org/openjdk/bench/javax/crypto/" In-Reply-To: <1fab97af-fd1d-7dee-56d3-3ae936ddd9e1@oracle.com> References: <1fab97af-fd1d-7dee-56d3-3ae936ddd9e1@oracle.com> Message-ID: <3172A540-B2D2-46B3-883B-BA83A2761A65@Oracle.Com> Looks good to me. Xuelei > On Aug 6, 2019, at 7:34 PM, Valerie Peng wrote: > > > Anyone can help review this trivial test update? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229214 > > Webrev: http://cr.openjdk.java.net/~valeriep/8229214/webrev.00/ > > Thanks, > Valerie From eric.caspole at oracle.com Wed Aug 7 13:28:06 2019 From: eric.caspole at oracle.com (eric.caspole at oracle.com) Date: Wed, 7 Aug 2019 09:28:06 -0400 Subject: [14] RFR JDK-8229214 "Don't use GCM with PKCS5Padding in test/micro/org/openjdk/bench/javax/crypto/" In-Reply-To: <1fab97af-fd1d-7dee-56d3-3ae936ddd9e1@oracle.com> References: <1fab97af-fd1d-7dee-56d3-3ae936ddd9e1@oracle.com> Message-ID: <6486a1f5-1916-7397-7bdb-40346d8600a2@oracle.com> Thanks for fixing this, looks good. Eric On 8/6/19 10:34 PM, Valerie Peng wrote: > > Anyone can help review this trivial test update? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229214 > > Webrev: http://cr.openjdk.java.net/~valeriep/8229214/webrev.00/ > > Thanks, > Valerie From valerie.peng at oracle.com Wed Aug 7 17:19:44 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 7 Aug 2019 10:19:44 -0700 Subject: [14] RFR JDK-8229214 "Don't use GCM with PKCS5Padding in test/micro/org/openjdk/bench/javax/crypto/" In-Reply-To: <6486a1f5-1916-7397-7bdb-40346d8600a2@oracle.com> References: <1fab97af-fd1d-7dee-56d3-3ae936ddd9e1@oracle.com> <6486a1f5-1916-7397-7bdb-40346d8600a2@oracle.com> Message-ID: <0c315701-2d95-2044-a136-17109d398051@oracle.com> Thanks Xuelei and Eric for the review~ Valerie On 8/7/2019 6:28 AM, eric.caspole at oracle.com wrote: > Thanks for fixing this, looks good. > Eric > > > On 8/6/19 10:34 PM, Valerie Peng wrote: >> >> Anyone can help review this trivial test update? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229214 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8229214/webrev.00/ >> >> Thanks, >> Valerie From xuelei.fan at oracle.com Thu Aug 8 04:41:57 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 7 Aug 2019 21:41:57 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> <0cd49f35-f636-9f4c-c324-191a5a6dbc0d@oracle.com> Message-ID: The latest webrev: http://cr.openjdk.java.net/~xuelei/8226374/webrev.04/ Updated the java.security to use the right document for standard names. Xuelei On 7/29/2019 8:55 AM, Xuelei Fan wrote: > > > On 7/29/2019 7:57 AM, Sean Mullan wrote: >> On 7/28/19 1:42 PM, Xuelei Fan wrote: >>> On 7/26/2019 7:08 AM, Xuelei Fan wrote: >>>> New webrev: >>>> http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/ >>>> >>> >>>> >>>>> * >>>>> src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java >>>>> >>>>> >>>>> 114???????????? if ((namedGroup == null) || >>>>> (!namedGroup.isAvailable)) { >>>>> >>>>> You don't do this check for null and isAvailable in other places, >>>>> for example >>>>> ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - >>>>> should you? >>>>> >>>> Good point!? Currently, the restriction is only checked for the >>>> supported group extension.? I should add more check points in other >>>> places where named groups are used, for example client key exchange >>>> and certificate.? Stay tune for the next webrev. >>>> >>> The ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() >>> should be fine as the namedGroup has been checked in the previous >>> steps >>> (X509Authentication.X509PossessionGenerator.createServerPossession()). >>> >>> However, I missed the check for certificate.? The consumer of >>> certificate should check the named groups to make sure the supported >>> named group is used.? It was not a problem in the past as the >>> supported named groups are used to indicate the EC curve or DH group >>> is able to be handled in both side. >>> >>> It could be a problem now when we want to restrict named groups.? The >>> named groups used in a certificate should be checked in key manager >>> and trust manager for TLS 1.2 and prior versions.? Similar to the >>> signature schemes for TLS 1.3.? As may required new APIs >>> (SSLParameters.getPeerSupportedNamedGroups()) for a generic solution. >>> >>> Would you mind if I file a new RFE and make the improvement in JDK 14 >>> later? >> >> Ok. I had a comment/question on the CSR [1]. In the Solution section, >> you list the legacy signature schemes as: >> >> dsa_sha256 >> ecdsa_sha224 >> rsa_sha224 >> dsa_sha224 >> ecdsa_sha1 >> rsa_pkcs1_sha1 >> dsa_sha1 >> rsa_md5 >> >> However, the IANA registry for TLS defines them differently: >> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 >> >> >> Can you clarify why we have this difference and how the JDK uses these >> legacy algorithms? > I added some description above these legacy signature schemes. > > ??? https://bugs.openjdk.java.net/browse/JDK-8227445 > >> I don't want to define them as standard names unless I can reference a >> TLS specification. >> > These names should not be used for future applications.? It's fine to me > if they are not part of the standard names. > > Thanks, > Xuelei From jamil.j.nimeh at oracle.com Fri Aug 9 00:30:52 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 8 Aug 2019 17:30:52 -0700 Subject: [14] RFR JDK-8228835 "Memory leak in PKCS11 provider when using AES GCM" In-Reply-To: <86ddf8f4-7fd4-4e6d-2364-043d351cb4bc@oracle.com> References: <86ddf8f4-7fd4-4e6d-2364-043d351cb4bc@oracle.com> Message-ID: <6e3edb28-18a1-362f-273e-5a87d2c5339f@oracle.com> Hi Valerie, looks pretty good.? I only had a few minor comments. * pkcs11wrapper.h o 210-212: Do you intend to leave these trace macros in there but commented?? It seems like they could be safely left uncommented in case you needed to use them for debugging. o 388: This looks like a duplicate of line 387. * libj2pkcs11.c o 271/277 (and others) - If you know you're going to zero the memory right off the bat you could use calloc() rather than malloc and get the benefit of the memory being zeroed automatically.? Just a suggestion, there's nothing wrong with the code as it is. o 395: nit - extra space between ckpdate and ";" o 843: unnecessary double-parenthesis --Jamil On 8/6/19 7:28 PM, Valerie Peng wrote: > > Anyone have spare cycles for reviewing this? > > The current PKCS11 JNI code for handling native mechanism and its > parameters is a bit too all over the place. To make the tracing and > verification easier, I consolidated the memory deallocation to the > freeCKMechanismPtr(...) method in p11_util.c (some was in p11_keymgmt.c). > > Also, fixed the j_XXX_ToCK_XXXX_ methods in p11_convert.c to allocate > the memory inside each method and return NULL upon error and make sure > allocated memories are free'd upon any failure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228835 > > Webrev: http://cr.openjdk.java.net/~valeriep/8228835/webrev.00/ > > Mach5 run is clean. > > Thanks, > Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Aug 9 15:04:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 9 Aug 2019 15:04:30 +0000 Subject: [11u] RFR(XS): 8224991: Problemlist javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java Message-ID: Hi, please review the problemlisting of javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java in jdk11u. There's an issue with the test, tracked by JDK-8212096. We see this issue in 11u testing, too. In jdk/jdk resp. jdk/jdk13, the test is excluded, so I think we should exclude it in 11u as well. Since the exclusion lists diverged, I had to resolve the patch manually. Bug: https://bugs.openjdk.java.net/browse/JDK-8224991 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/3e5dba06a663 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224991.11u-dev.0/ Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgehwolf at redhat.com Fri Aug 9 15:18:45 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 09 Aug 2019 17:18:45 +0200 Subject: [11u] RFR(XS): 8224991: Problemlist javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java In-Reply-To: References: Message-ID: Hi Christoph, On Fri, 2019-08-09 at 15:04 +0000, Langer, Christoph wrote: > Hi, > > please review the problemlisting of > javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java in jdk11u. > There's an issue with the test, tracked by JDK-8212096. We see this > issue in 11u testing, too. In jdk/jdk resp. jdk/jdk13, the test is > excluded, so I think we should exclude it in 11u as well. Since the > exclusion lists diverged, I had to resolve the patch manually. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224991 > Original change: http://hg.openjdk.java.net/jdk/jdk/rev/3e5dba06a663 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224991.11u-dev.0/ Context differs in JDK 11u. OK. This looks fine to me. Thanks, Severin From weijun.wang at oracle.com Sun Aug 11 02:32:59 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 11 Aug 2019 10:32:59 +0800 Subject: [14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic" In-Reply-To: References: Message-ID: The spec for SecureRandom has: /** * Constructs a secure random number generator (RNG) implementing the * default random number algorithm. * * .... */ public SecureRandom() { What does "the default random number algorithm" mean? I suggest we invent some new concepts in a CSR first. Or, if we simply want to keep the expected behavior, I feel a little uncomfortable to make the "DEFAULT" alias visible to the public. Can we make all these logic internal? Maybe like this? + if (p.getName().equals("SUN")) { + return SunEntries.DEFAULT; // and assign DEFAULT somewhere in SunEntries + } --Max > On Aug 7, 2019, at 8:59 AM, Valerie Peng wrote: > > > Anyone can help review this fix? SUN provider supports multiple impls of SecureRandom and rely on the ordering of the set returned by Provider.getServices() to choose the most preferred RNG algo for new SecureRandom() calls. Instead of maintaining the ordering, I think it's faster and more robust to use an alias "DEFAULT" to indicate the most preferred RNG algo for SUN provider. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228613 > > Webrev: http://cr.openjdk.java.net/~valeriep/8228613/webrev.00/ > > Thanks, > Valerie From eugene.adell at gmail.com Sun Aug 11 23:26:30 2019 From: eugene.adell at gmail.com (=?UTF-8?Q?Eug=C3=A8ne_Adell?=) Date: Mon, 12 Aug 2019 01:26:30 +0200 Subject: the GMT timestamp given in the trace is sometimes wrong Message-ID: Hello, When using the well-known javax.net.debug=all property we get outputs similar to this : ... Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1 %% No cached client session update handshake state: client_hello[1] upcoming handshake states: server_hello[2] *** ClientHello, TLSv1.2 RandomCookie: GMT: 1565495356 bytes = { 119, 88, 206, 84, 104, 18, 56, 110, 157, 162, 50, 247, 142, 47, 46, 11, 133, 196, 21, 108, 17, 205, 121, 220, 52, 127, 169, 241 } Session ID: {} Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, ... Compression Methods: { 0 } Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1} Extension ec_point_formats, formats: [uncompressed] Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA Extension extended_master_secret Extension server_name, server_name: [type=host_name (0), value=bugs.openjdk.java.net] *** [write] MD5 and SHA1 hashes: len = 229 0000: 01 00 00 E1 03 03 5D 50 90 3C 77 58 CE 54 68 12 ......]P. References: <3EDF161E-62AC-4C05-BF1C-DD81126F4C62@amazon.com> Message-ID: Forwarding to security-dev as this was backported from later JDK versions: On 09/08/2019 20:52, Alvarez, David wrote: > Hello, > > We have detected that JDK-8219988 [1], that has been included in OpenJDK 8u222 > included a non-documented change in the behavior of the > javax.net.ssl.trustStore property. In previous versions, should this property > point to a non-existent file, an empty KeyStore would be used instead. [2] > > In newer versions, if the value of the property contains an invalid URL, the > code will instead fall back and use the lib/security/cacerts file. [3] > > However, there are two things about that change that caught our attention: > - Whenever there is no javax.net.ssl.trustStore property set, the code will > first look for lib/security/jssecacerts. If that file does not exist, then it > will look for lib/security/cacerts. However, when the property is set to an > invalid file, the fallback mechanism jumps directly to lib/security/cacerts, > never checking lib/security/jssecacerts. > > - This fallback mechanism for invalid javax.net.ssl.trustStore values reuses the > value of javax.net.ssl.trustStorePassword. If that property is set in > conjunction with an invalid value in javax.net.ssl.trustStore the specified > password will be used when attempting to read the lib/security/cacerts store. > It seems unclear why this path of action is chosen here. > > If the lib/security/cacerts has no password (and as far as I'm aware, that is > the case in the majority of OpenJDK distributions, if not all), the operation > will raise an exception. This exception mentions that 'Password verification > failed', hiding the underlying cause (the property pointing to a bad store).[4] > > Although the new behavior isn't necessarily wrong, I think there is room for > Improvement. Suggestions: > > - Make sure lib/security/jssecacerts is checked during the fallback process. > - Ignore the value of javax.net.ssl.trustStorePassword when we fallback to use > the bundled jssecacerts or cacerts file. > - Change the exception message to avoid confusion. > > I would like to have your opinion on this. > > Thanks, > > David > > -- > [1] https://bugs.openjdk.java.net/browse/JDK-8129988 > [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/ac2ef877d3e8/src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java#l132 > [3] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/2a9bea6e5e03/src/share/classes/sun/security/ssl/TrustStoreManager.java#l128 > [4] Here is a copy of the exception: > Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect > at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:785) > at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:56) > at sun.security.provider.KeyStoreDelegator.engineLoad(KeyStoreDelegator.java:224) > at sun.security.provider.JavaKeyStore$DualFormatJKS.engineLoad(JavaKeyStore.java:70) > at java.security.KeyStore.load(KeyStore.java:1445) > at sun.security.ssl.TrustStoreManager$TrustAnchorManager.loadKeyStore(TrustStoreManager.java:367) > at sun.security.ssl.TrustStoreManager$TrustAnchorManager.getTrustedCerts(TrustStoreManager.java:315) > at sun.security.ssl.TrustStoreManager.getTrustedCerts(TrustStoreManager.java:59) > at sun.security.ssl.TrustManagerFactoryImpl.engineInit(TrustManagerFactoryImpl.java:51) > Caused by: java.security.UnrecoverableKeyException: Password verification failed > at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:783) > -- 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 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From sean.mullan at oracle.com Mon Aug 12 18:36:03 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 12 Aug 2019 14:36:03 -0400 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> <0cd49f35-f636-9f4c-c324-191a5a6dbc0d@oracle.com> Message-ID: * java.security 702 # Example: 703 # jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048, 704 # rsa_pkcs1_sha256, secp224r1 Since this is a property that is typically used for disabling weak algorithms, I think we should use a weaker signature scheme in this example. Suggest: 704 # rsa_pkcs1_sha1, secp224r1 Looks good otherwise. --Sean On 8/8/19 12:41 AM, Xuelei Fan wrote: > The latest webrev: > ??? http://cr.openjdk.java.net/~xuelei/8226374/webrev.04/ > > Updated the java.security to use the right document for standard names. > > Xuelei > > > On 7/29/2019 8:55 AM, Xuelei Fan wrote: >> >> >> On 7/29/2019 7:57 AM, Sean Mullan wrote: >>> On 7/28/19 1:42 PM, Xuelei Fan wrote: >>>> On 7/26/2019 7:08 AM, Xuelei Fan wrote: >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/ >>>>> >>>> >>>>> >>>>>> * >>>>>> src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java >>>>>> >>>>>> >>>>>> 114???????????? if ((namedGroup == null) || >>>>>> (!namedGroup.isAvailable)) { >>>>>> >>>>>> You don't do this check for null and isAvailable in other places, >>>>>> for example >>>>>> ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - >>>>>> should you? >>>>>> >>>>> Good point!? Currently, the restriction is only checked for the >>>>> supported group extension.? I should add more check points in other >>>>> places where named groups are used, for example client key exchange >>>>> and certificate.? Stay tune for the next webrev. >>>>> >>>> The ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() >>>> should be fine as the namedGroup has been checked in the previous >>>> steps >>>> (X509Authentication.X509PossessionGenerator.createServerPossession()). >>>> >>>> However, I missed the check for certificate.? The consumer of >>>> certificate should check the named groups to make sure the supported >>>> named group is used.? It was not a problem in the past as the >>>> supported named groups are used to indicate the EC curve or DH group >>>> is able to be handled in both side. >>>> >>>> It could be a problem now when we want to restrict named groups. >>>> The named groups used in a certificate should be checked in key >>>> manager and trust manager for TLS 1.2 and prior versions.? Similar >>>> to the signature schemes for TLS 1.3.? As may required new APIs >>>> (SSLParameters.getPeerSupportedNamedGroups()) for a generic solution. >>>> >>>> Would you mind if I file a new RFE and make the improvement in JDK >>>> 14 later? >>> >>> Ok. I had a comment/question on the CSR [1]. In the Solution section, >>> you list the legacy signature schemes as: >>> >>> dsa_sha256 >>> ecdsa_sha224 >>> rsa_sha224 >>> dsa_sha224 >>> ecdsa_sha1 >>> rsa_pkcs1_sha1 >>> dsa_sha1 >>> rsa_md5 >>> >>> However, the IANA registry for TLS defines them differently: >>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 >>> >>> >>> Can you clarify why we have this difference and how the JDK uses >>> these legacy algorithms? >> I added some description above these legacy signature schemes. >> >> ???? https://bugs.openjdk.java.net/browse/JDK-8227445 >> >>> I don't want to define them as standard names unless I can reference >>> a TLS specification. >>> >> These names should not be used for future applications.? It's fine to >> me if they are not part of the standard names. >> >> Thanks, >> Xuelei From xuelei.fan at oracle.com Mon Aug 12 18:45:59 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 12 Aug 2019 11:45:59 -0700 Subject: RFR [14] JDK-8226374 Restrict signature algorithms and named groups In-Reply-To: References: <714cec91-3888-c5ae-c790-f27887a6dbf9@oracle.com> <168305f9-d3ec-887b-c94d-92fe164a5c48@oracle.com> <0a1aced0-235d-e7a3-2ac7-cc4367193652@oracle.com> <748a353d-7d27-0045-6b07-e188728f8e30@oracle.com> <0cd49f35-f636-9f4c-c324-191a5a6dbc0d@oracle.com> Message-ID: <4fcda9c9-a043-b50d-ad88-629c684b43b5@oracle.com> It makes sense to me. I will update the example before I push the changeset. Thanks, Xuelei On 8/12/2019 11:36 AM, Sean Mullan wrote: > * java.security > > 702 # Example: > 703 #?? jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048, > 704 #?????? rsa_pkcs1_sha256, secp224r1 > > Since this is a property that is typically used for disabling weak > algorithms, I think we should use a weaker signature scheme in this > example. Suggest: > > 704 #?????? rsa_pkcs1_sha1, secp224r1 > > Looks good otherwise. > > --Sean > > On 8/8/19 12:41 AM, Xuelei Fan wrote: >> The latest webrev: >> ???? http://cr.openjdk.java.net/~xuelei/8226374/webrev.04/ >> >> Updated the java.security to use the right document for standard names. >> >> Xuelei >> >> >> On 7/29/2019 8:55 AM, Xuelei Fan wrote: >>> >>> >>> On 7/29/2019 7:57 AM, Sean Mullan wrote: >>>> On 7/28/19 1:42 PM, Xuelei Fan wrote: >>>>> On 7/26/2019 7:08 AM, Xuelei Fan wrote: >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~xuelei/8226374/webrev.03/ >>>>>> >>>>> >>>>>> >>>>>>> * >>>>>>> src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java >>>>>>> >>>>>>> >>>>>>> 114???????????? if ((namedGroup == null) || >>>>>>> (!namedGroup.isAvailable)) { >>>>>>> >>>>>>> You don't do this check for null and isAvailable in other places, >>>>>>> for example >>>>>>> ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() - >>>>>>> should you? >>>>>>> >>>>>> Good point!? Currently, the restriction is only checked for the >>>>>> supported group extension.? I should add more check points in >>>>>> other places where named groups are used, for example client key >>>>>> exchange and certificate.? Stay tune for the next webrev. >>>>>> >>>>> The ECDHClientKeyExchange.ECDHEClientKeyExchangeConsumer.consume() >>>>> should be fine as the namedGroup has been checked in the previous >>>>> steps >>>>> (X509Authentication.X509PossessionGenerator.createServerPossession()). >>>>> >>>>> However, I missed the check for certificate.? The consumer of >>>>> certificate should check the named groups to make sure the >>>>> supported named group is used.? It was not a problem in the past as >>>>> the supported named groups are used to indicate the EC curve or DH >>>>> group is able to be handled in both side. >>>>> >>>>> It could be a problem now when we want to restrict named groups. >>>>> The named groups used in a certificate should be checked in key >>>>> manager and trust manager for TLS 1.2 and prior versions.? Similar >>>>> to the signature schemes for TLS 1.3.? As may required new APIs >>>>> (SSLParameters.getPeerSupportedNamedGroups()) for a generic solution. >>>>> >>>>> Would you mind if I file a new RFE and make the improvement in JDK >>>>> 14 later? >>>> >>>> Ok. I had a comment/question on the CSR [1]. In the Solution >>>> section, you list the legacy signature schemes as: >>>> >>>> dsa_sha256 >>>> ecdsa_sha224 >>>> rsa_sha224 >>>> dsa_sha224 >>>> ecdsa_sha1 >>>> rsa_pkcs1_sha1 >>>> dsa_sha1 >>>> rsa_md5 >>>> >>>> However, the IANA registry for TLS defines them differently: >>>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 >>>> >>>> >>>> Can you clarify why we have this difference and how the JDK uses >>>> these legacy algorithms? >>> I added some description above these legacy signature schemes. >>> >>> ???? https://bugs.openjdk.java.net/browse/JDK-8227445 >>> >>>> I don't want to define them as standard names unless I can reference >>>> a TLS specification. >>>> >>> These names should not be used for future applications.? It's fine to >>> me if they are not part of the standard names. >>> >>> Thanks, >>> Xuelei From jamil.j.nimeh at oracle.com Mon Aug 12 19:58:16 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 12 Aug 2019 12:58:16 -0700 Subject: [RFR] JDK-8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException Message-ID: Hello all, This fix addresses a problem first found by Netty/Jetty when decrypting payloads in excess of ~4096 bytes using one of the ChaCha20-Poly1305 cipher suites.? The root cause of the issue is not in the TLS code, it is actually an issue with how ChaCha20-Poly1305 was implementing CipherSpi.engineGetOutputSize(). The bug was also partially worked around due to changes in CipherSpi from 8181386, but this properly addresses the output buffer sizing. Thanks to Adrian Todt and Bradley Wagner for the Catnip and Jetty support while trying to replicate the issue originally. Bug: https://bugs.openjdk.java.net/browse/JDK-8224997 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8224997/webrev.01/ --Jamil From valerie.peng at oracle.com Mon Aug 12 23:22:52 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 12 Aug 2019 16:22:52 -0700 Subject: [14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic" In-Reply-To: References: Message-ID: <5aebed1f-d50a-8eb2-40a2-4d38a8c93d15@oracle.com> Sure, I considered the internal approach as well, but feel an alias of DEFAULT seems cleaner than a static constant in SunEntries class. I can go the other way if you prefer. The spec didn't spell clearly as to how the default random number algorithm is determined and I think it can be provider-specific. This is a regression and we need to backport this. Hope that a new concept/CSR won't shut the door for backport? Valerie On 8/10/2019 7:32 PM, Weijun Wang wrote: > The spec for SecureRandom has: > > /** > * Constructs a secure random number generator (RNG) implementing the > * default random number algorithm. > * > * .... > */ > public SecureRandom() { > > What does "the default random number algorithm" mean? > > I suggest we invent some new concepts in a CSR first. > > Or, if we simply want to keep the expected behavior, I feel a little uncomfortable to make the "DEFAULT" alias visible to the public. Can we make all these logic internal? Maybe like this? > > + if (p.getName().equals("SUN")) { > + return SunEntries.DEFAULT; // and assign DEFAULT somewhere in SunEntries > + } > > > --Max > >> On Aug 7, 2019, at 8:59 AM, Valerie Peng wrote: >> >> >> Anyone can help review this fix? SUN provider supports multiple impls of SecureRandom and rely on the ordering of the set returned by Provider.getServices() to choose the most preferred RNG algo for new SecureRandom() calls. Instead of maintaining the ordering, I think it's faster and more robust to use an alias "DEFAULT" to indicate the most preferred RNG algo for SUN provider. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228613 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8228613/webrev.00/ >> >> Thanks, >> Valerie From valerie.peng at oracle.com Tue Aug 13 01:02:19 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 12 Aug 2019 18:02:19 -0700 Subject: [14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic" In-Reply-To: <5aebed1f-d50a-8eb2-40a2-4d38a8c93d15@oracle.com> References: <5aebed1f-d50a-8eb2-40a2-4d38a8c93d15@oracle.com> Message-ID: Webrev updated to use a static constant in SunEntries: http://cr.openjdk.java.net/~valeriep/8228613/webrev.01/ Thanks~ Valerie On 8/12/2019 4:22 PM, Valerie Peng wrote: > > Sure, I considered the internal approach as well, but feel an alias of > DEFAULT seems cleaner than a static constant in SunEntries class. I > can go the other way if you prefer. > > The spec didn't spell clearly as to how the default random number > algorithm is determined and I think it can be provider-specific. This > is a regression and we need to backport this. Hope that a new > concept/CSR won't shut the door for backport? > > Valerie > > > On 8/10/2019 7:32 PM, Weijun Wang wrote: >> The spec for SecureRandom has: >> >> /** >> ? * Constructs a secure random number generator (RNG) implementing the >> ? * default random number algorithm. >> ? * >> ? * .... >> ? */ >> public SecureRandom() { >> >> What does "the default random number algorithm" mean? >> >> I suggest we invent some new concepts in a CSR first. >> >> Or, if we simply want to keep the expected behavior, I feel a little >> uncomfortable to make the "DEFAULT" alias visible to the public. Can >> we make all these logic internal? Maybe like this? >> >> +??????????? if (p.getName().equals("SUN")) { >> +??????????????? return SunEntries.DEFAULT; // and assign DEFAULT >> somewhere in SunEntries >> +??????????? } >> >> >> --Max >> >>> On Aug 7, 2019, at 8:59 AM, Valerie Peng >>> wrote: >>> >>> >>> Anyone can help review this fix? SUN provider supports multiple >>> impls of SecureRandom and rely on the ordering of the set returned >>> by Provider.getServices() to choose the most preferred RNG algo for >>> new SecureRandom() calls. Instead of maintaining the ordering, I >>> think it's faster and more robust to use an alias "DEFAULT" to >>> indicate the most preferred RNG algo for SUN provider. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228613 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8228613/webrev.00/ >>> >>> Thanks, >>> Valerie From weijun.wang at oracle.com Tue Aug 13 02:20:58 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 13 Aug 2019 10:20:58 +0800 Subject: [14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic" In-Reply-To: References: <5aebed1f-d50a-8eb2-40a2-4d38a8c93d15@oracle.com> Message-ID: <4874E43F-885C-4D82-9BC1-80A14414444A@oracle.com> Hi Valerie, I prefer this fix which is totally internal and expose nothing to the public. It looks fine to me. > On Aug 13, 2019, at 9:02 AM, Valerie Peng wrote: > > > Webrev updated to use a static constant in SunEntries: > > http://cr.openjdk.java.net/~valeriep/8228613/webrev.01/ > > Thanks~ > Valerie > On 8/12/2019 4:22 PM, Valerie Peng wrote: >> >> Sure, I considered the internal approach as well, but feel an alias of DEFAULT seems cleaner than a static constant in SunEntries class. I can go the other way if you prefer. >> >> The spec didn't spell clearly as to how the default random number algorithm is determined and I think it can be provider-specific. This is a regression and we need to backport this. Hope that a new concept/CSR won't shut the door for backport? Maybe we can do this later, and maybe you can take back the "DEFAULT" algorithm if that's the suggested way to indicate a default algorithm, or maybe it can be described somewhere inside the attributes. Thanks, Max >> >> Valerie >> >> >> On 8/10/2019 7:32 PM, Weijun Wang wrote: >>> The spec for SecureRandom has: >>> >>> /** >>> * Constructs a secure random number generator (RNG) implementing the >>> * default random number algorithm. >>> * >>> * .... >>> */ >>> public SecureRandom() { >>> >>> What does "the default random number algorithm" mean? >>> >>> I suggest we invent some new concepts in a CSR first. >>> >>> Or, if we simply want to keep the expected behavior, I feel a little uncomfortable to make the "DEFAULT" alias visible to the public. Can we make all these logic internal? Maybe like this? >>> >>> + if (p.getName().equals("SUN")) { >>> + return SunEntries.DEFAULT; // and assign DEFAULT somewhere in SunEntries >>> + } >>> >>> >>> --Max >>> >>>> On Aug 7, 2019, at 8:59 AM, Valerie Peng wrote: >>>> >>>> >>>> Anyone can help review this fix? SUN provider supports multiple impls of SecureRandom and rely on the ordering of the set returned by Provider.getServices() to choose the most preferred RNG algo for new SecureRandom() calls. Instead of maintaining the ordering, I think it's faster and more robust to use an alias "DEFAULT" to indicate the most preferred RNG algo for SUN provider. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228613 >>>> >>>> Webrev: http://cr.openjdk.java.net/~valeriep/8228613/webrev.00/ >>>> >>>> Thanks, >>>> Valerie From weijun.wang at oracle.com Tue Aug 13 16:23:01 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 14 Aug 2019 00:23:01 +0800 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS Message-ID: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> Please take a preliminary review at https://cr.openjdk.java.net/~weijun/8162628/webrev.00 There is no test yet. I mainly want you to see if this is doable and whether there can be any unexpected compatibility impact. So, the major points are: 1. Invent a new KeyStore type named "PEM", which is a stack of PEM-format certificates. It only support X.509 certificates and is read-only (at the moment). 2. Migrate lib/security/cacerts to this format. Some details: 1. JKS/PKCS12/PEM is now aliases to each other, which means you can load a PKCS12 keystore using KeyStore.getInstance("pem"). This is an expansion of the former JKS/PKCS12 dual type. 2. PEM supports engineProbe(), and returns true as long as the first 5 bytes are readable ASCII. This is because people might put comment before "-----BEGIN CERT-----". 3. @attr can be added into comment as attributes in the comment area. cacerts will contain "@alias: aliasname". I'm still using the "[jdk]" label in the alias for jdkCA recognition. Thanks, Max From 1983-01-06 at gmx.net Tue Aug 13 18:03:06 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Tue, 13 Aug 2019 20:03:06 +0200 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> Message-ID: Am 2019-08-13 um 18:23 schrieb Weijun Wang: > Please take a preliminary review at > > https://cr.openjdk.java.net/~weijun/8162628/webrev.00 > > There is no test yet. I mainly want you to see if this is doable and whether there can be any unexpected compatibility impact. > > So, the major points are: > > 1. Invent a new KeyStore type named "PEM", which is a stack of PEM-format certificates. It only support X.509 certificates and is read-only (at the moment). > 2. Migrate lib/security/cacerts to this format. > > Some details: > > 1. JKS/PKCS12/PEM is now aliases to each other, which means you can load a PKCS12 keystore using KeyStore.getInstance("pem"). This is an expansion of the former JKS/PKCS12 dual type. > 2. PEM supports engineProbe(), and returns true as long as the first 5 bytes are readable ASCII. This is because people might put comment before "-----BEGIN CERT-----". > 3. @attr can be added into comment as attributes in the comment area. cacerts will contain "@alias: aliasname". I'm still using the "[jdk]" label in the alias for jdkCA recognition. Thanks, that's awesome. I will have a look. Some questions upfront: 1. How did you manage to assign virtual aliases? The PEM format does not have any. 2. I have a PKCS12 keystore issued by our CA with a public cert and a private key in it. I can export it with openssl(1) into single PEM file and feed it to curl with OpenSSL binding. Does this work too? Regards, Michael From 1983-01-06 at gmx.net Tue Aug 13 19:23:53 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Tue, 13 Aug 2019 21:23:53 +0200 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> Message-ID: <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> Am 2019-08-13 um 18:23 schrieb Weijun Wang: > Please take a preliminary review at > > https://cr.openjdk.java.net/~weijun/8162628/webrev.00 > > There is no test yet. I mainly want you to see if this is doable and whether there can be any unexpected compatibility impact. > > So, the major points are: > > 1. Invent a new KeyStore type named "PEM", which is a stack of PEM-format certificates. It only support X.509 certificates and is read-only (at the moment). > 2. Migrate lib/security/cacerts to this format. > > Some details: > > 1. JKS/PKCS12/PEM is now aliases to each other, which means you can load a PKCS12 keystore using KeyStore.getInstance("pem"). This is an expansion of the former JKS/PKCS12 dual type. > 2. PEM supports engineProbe(), and returns true as long as the first 5 bytes are readable ASCII. This is because people might put comment before "-----BEGIN CERT-----". > 3. @attr can be added into comment as attributes in the comment area. cacerts will contain "@alias: aliasname". I'm still using the "[jdk]" label in the alias for jdkCA recognition. My comments: GenerateCacerts: * Why not use Files#newBufferedWriter(Path)? * How does the input look like? Do we only have base 64 data? It might be really helpful to write at least the DN of the cert for analysis purposes. I have written some decent Java code with does this. Will to share if you want to. KeyStoreDelegator: * Please avoid iterating a list like an array and using List#get(int). PemKeyStore: * It pretty much looks like you don't support private keys. Do you intend to deliver that in a seperate issue? * engineStore(): Why is that not supported? Without password of course. * engineLoad(): ** Why not use Reader r = new Buffered...? ** split(":\\s*", 2): expect the unexpected: "@", kv might be null. ** attr.add(new PemAttribute(kv[0], kv.length == 2 ? kv[1] : "true")); This one is for adding arbitrary attributes, but not alias? I will also pass a pretty large cacerts with public CA and our CAs and see wether your parser doesn't choke on it. Michael From valerie.peng at oracle.com Tue Aug 13 21:21:48 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 13 Aug 2019 14:21:48 -0700 Subject: [14] RFR JDK-8228835 "Memory leak in PKCS11 provider when using AES GCM" In-Reply-To: <6e3edb28-18a1-362f-273e-5a87d2c5339f@oracle.com> References: <86ddf8f4-7fd4-4e6d-2364-043d351cb4bc@oracle.com> <6e3edb28-18a1-362f-273e-5a87d2c5339f@oracle.com> Message-ID: Hi Jamil, Thanks for the review, webrev updated at http://cr.openjdk.java.net/~valeriep/8228835/webrev.01/ More replies in line below. On 8/8/2019 5:30 PM, Jamil Nimeh wrote: > > Hi Valerie, looks pretty good.? I only had a few minor comments. > > * pkcs11wrapper.h > o 210-212: Do you intend to leave these trace macros in there > but commented?? It seems like they could be safely left > uncommented in case you needed to use them for debugging. > o 388: This looks like a duplicate of line 387. > Yes, I have used those trace macros quite extensively, so I left them in and commented out. More convenient this way. Removed line 388. > * libj2pkcs11.c > o 271/277 (and others) - If you know you're going to zero the > memory right off the bat you could use calloc() rather than > malloc and get the benefit of the memory being zeroed > automatically.? Just a suggestion, there's nothing wrong with > the code as it is. > o 395: nit - extra space between ckpdate and ";" > o 843: unnecessary double-parenthesis > Fixed. Mach5 run is clean. Please let me know if you have more comments. Thanks, Valerie > --Jamil > > On 8/6/19 7:28 PM, Valerie Peng wrote: >> >> Anyone have spare cycles for reviewing this? >> >> The current PKCS11 JNI code for handling native mechanism and its >> parameters is a bit too all over the place. To make the tracing and >> verification easier, I consolidated the memory deallocation to the >> freeCKMechanismPtr(...) method in p11_util.c (some was in >> p11_keymgmt.c). >> >> Also, fixed the j_XXX_ToCK_XXXX_ methods in p11_convert.c to allocate >> the memory inside each method and return NULL upon error and make >> sure allocated memories are free'd upon any failure. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228835 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8228835/webrev.00/ >> >> Mach5 run is clean. >> >> Thanks, >> Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Aug 13 21:37:50 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 13 Aug 2019 14:37:50 -0700 Subject: [14] RFR JDK-8228835 "Memory leak in PKCS11 provider when using AES GCM" In-Reply-To: References: <86ddf8f4-7fd4-4e6d-2364-043d351cb4bc@oracle.com> <6e3edb28-18a1-362f-273e-5a87d2c5339f@oracle.com> Message-ID: <4638b163-3de5-6f3c-4614-7420579a737f@oracle.com> Nope, no other comments, looks good to me. --Jamil On 8/13/2019 2:21 PM, Valerie Peng wrote: > > Hi Jamil, > > Thanks for the review, webrev updated at > http://cr.openjdk.java.net/~valeriep/8228835/webrev.01/ > > More replies in line below. > > On 8/8/2019 5:30 PM, Jamil Nimeh wrote: >> >> Hi Valerie, looks pretty good.? I only had a few minor comments. >> >> * pkcs11wrapper.h >> o 210-212: Do you intend to leave these trace macros in there >> but commented?? It seems like they could be safely left >> uncommented in case you needed to use them for debugging. >> o 388: This looks like a duplicate of line 387. >> > Yes, I have used those trace macros quite extensively, so I left them > in and commented out. More convenient this way. > > Removed line 388. > >> * libj2pkcs11.c >> o 271/277 (and others) - If you know you're going to zero the >> memory right off the bat you could use calloc() rather than >> malloc and get the benefit of the memory being zeroed >> automatically.? Just a suggestion, there's nothing wrong with >> the code as it is. >> o 395: nit - extra space between ckpdate and ";" >> o 843: unnecessary double-parenthesis >> > Fixed. > > Mach5 run is clean. Please let me know if you have more comments. > > Thanks, > > Valerie > >> --Jamil >> >> On 8/6/19 7:28 PM, Valerie Peng wrote: >>> >>> Anyone have spare cycles for reviewing this? >>> >>> The current PKCS11 JNI code for handling native mechanism and its >>> parameters is a bit too all over the place. To make the tracing and >>> verification easier, I consolidated the memory deallocation to the >>> freeCKMechanismPtr(...) method in p11_util.c (some was in >>> p11_keymgmt.c). >>> >>> Also, fixed the j_XXX_ToCK_XXXX_ methods in p11_convert.c to >>> allocate the memory inside each method and return NULL upon error >>> and make sure allocated memories are free'd upon any failure. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228835 >>> >>> Webrev: http://cr.openjdk.java.net/~valeriep/8228835/webrev.00/ >>> >>> Mach5 run is clean. >>> >>> Thanks, >>> Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Tue Aug 13 22:33:22 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 13 Aug 2019 15:33:22 -0700 Subject: [14] RFR JDK-8228613 "java.security.Provider#getServices order is no longer deterministic" In-Reply-To: <4874E43F-885C-4D82-9BC1-80A14414444A@oracle.com> References: <5aebed1f-d50a-8eb2-40a2-4d38a8c93d15@oracle.com> <4874E43F-885C-4D82-9BC1-80A14414444A@oracle.com> Message-ID: <1568a310-6564-3648-4d3e-04866d583e1e@oracle.com> Thanks for the review~ For this fix, let's just address the regression. I will file a separate RFE to track how providers can indicate their preferred secure random algorithm for new SecureRandom() calls. Valerie On 8/12/2019 7:20 PM, Weijun Wang wrote: > Hi Valerie, > > I prefer this fix which is totally internal and expose nothing to the public. It looks fine to me. > >> On Aug 13, 2019, at 9:02 AM, Valerie Peng wrote: >> >> >> Webrev updated to use a static constant in SunEntries: >> >> http://cr.openjdk.java.net/~valeriep/8228613/webrev.01/ >> >> Thanks~ >> Valerie >> On 8/12/2019 4:22 PM, Valerie Peng wrote: >>> Sure, I considered the internal approach as well, but feel an alias of DEFAULT seems cleaner than a static constant in SunEntries class. I can go the other way if you prefer. >>> >>> The spec didn't spell clearly as to how the default random number algorithm is determined and I think it can be provider-specific. This is a regression and we need to backport this. Hope that a new concept/CSR won't shut the door for backport? > Maybe we can do this later, and maybe you can take back the "DEFAULT" algorithm if that's the suggested way to indicate a default algorithm, or maybe it can be described somewhere inside the attributes. > > Thanks, > Max > > >>> Valerie >>> >>> >>> On 8/10/2019 7:32 PM, Weijun Wang wrote: >>>> The spec for SecureRandom has: >>>> >>>> /** >>>> * Constructs a secure random number generator (RNG) implementing the >>>> * default random number algorithm. >>>> * >>>> * .... >>>> */ >>>> public SecureRandom() { >>>> >>>> What does "the default random number algorithm" mean? >>>> >>>> I suggest we invent some new concepts in a CSR first. >>>> >>>> Or, if we simply want to keep the expected behavior, I feel a little uncomfortable to make the "DEFAULT" alias visible to the public. Can we make all these logic internal? Maybe like this? >>>> >>>> + if (p.getName().equals("SUN")) { >>>> + return SunEntries.DEFAULT; // and assign DEFAULT somewhere in SunEntries >>>> + } >>>> >>>> >>>> --Max >>>> >>>>> On Aug 7, 2019, at 8:59 AM, Valerie Peng wrote: >>>>> >>>>> >>>>> Anyone can help review this fix? SUN provider supports multiple impls of SecureRandom and rely on the ordering of the set returned by Provider.getServices() to choose the most preferred RNG algo for new SecureRandom() calls. Instead of maintaining the ordering, I think it's faster and more robust to use an alias "DEFAULT" to indicate the most preferred RNG algo for SUN provider. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228613 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8228613/webrev.00/ >>>>> >>>>> Thanks, >>>>> Valerie From weijun.wang at oracle.com Wed Aug 14 02:19:21 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 14 Aug 2019 10:19:21 +0800 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> Message-ID: <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> > On Aug 14, 2019, at 3:23 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Am 2019-08-13 um 18:23 schrieb Weijun Wang: >> Please take a preliminary review at >> >> https://cr.openjdk.java.net/~weijun/8162628/webrev.00 >> >> There is no test yet. I mainly want you to see if this is doable and whether there can be any unexpected compatibility impact. >> >> So, the major points are: >> >> 1. Invent a new KeyStore type named "PEM", which is a stack of PEM-format certificates. It only support X.509 certificates and is read-only (at the moment). >> 2. Migrate lib/security/cacerts to this format. >> >> Some details: >> >> 1. JKS/PKCS12/PEM is now aliases to each other, which means you can load a PKCS12 keystore using KeyStore.getInstance("pem"). This is an expansion of the former JKS/PKCS12 dual type. >> 2. PEM supports engineProbe(), and returns true as long as the first 5 bytes are readable ASCII. This is because people might put comment before "-----BEGIN CERT-----". >> 3. @attr can be added into comment as attributes in the comment area. cacerts will contain "@alias: aliasname". I'm still using the "[jdk]" label in the alias for jdkCA recognition. > > My comments: > GenerateCacerts: > * Why not use Files#newBufferedWriter(Path)? I like println. > * How does the input look like? Do we only have base 64 data? Here is an example: https://hg.openjdk.java.net/jdk/jdk/file/29ab1f3bd353/make/data/cacerts/actalisauthenticationrootca > It might be really helpful to write at least the DN of the cert > for analysis purposes. I have written some decent Java code with does > this. > Will to share if you want to. Thanks. The input already includes something. > KeyStoreDelegator: > * Please avoid iterating a list like an array and using List#get(int). But I have 2 lists. It is a Pair but Java does not have it, and I don't like Map::Entry very much. > PemKeyStore: > * It pretty much looks like you don't support private keys. Do you intend > to deliver that in a seperate issue? To be determined, but no requirement now. Also, I don't want to invent a competitor for pkcs12. > * engineStore(): Why is that not supported? Without password of course. No requirement. I also don't want to see people losing their comments. > * engineLoad(): > ** Why not use Reader r = new Buffered...? readLine() is only in BufferedReader. > ** split(":\\s*", 2): expect the unexpected: "@", kv might be null. jshell> "@".substring(1).split(":\\s*", 2) $1 ==> String[1] { "" } > ** attr.add(new PemAttribute(kv[0], kv.length == 2 ? kv[1] : "true")); > This one is for adding arbitrary attributes, but not alias? Yes, though I don't have a usage now. > > I will also pass a pretty large cacerts with public CA and our CAs and > see wether your parser doesn't choke on it. PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. In your other mail, you asked about aliases. If there is no "@alias", it will be the finderprint of the cert. Thanks, Max > > Michael From sean.mullan at oracle.com Wed Aug 14 13:31:10 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 14 Aug 2019 09:31:10 -0400 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> Message-ID: <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> On 8/13/19 10:19 PM, Weijun Wang wrote: >> I will also pass a pretty large cacerts with public CA and our CAs and >> see wether your parser doesn't choke on it. > PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 I would not want to see a regression in performance. --Sean From weijun.wang at oracle.com Wed Aug 14 14:07:39 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 14 Aug 2019 22:07:39 +0800 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> Message-ID: <9367A39F-2863-48D5-BE4A-7995187A8973@oracle.com> The difference will be big. I've simplified the logic into 1. read bytes between first ": " and \r\n as alias 2. read bytes between first \r\n after first "-" and next "-" as a cert 3. goto 1 And I only store the cert bytes and do not create a Certificate until getCertificate() is read. I even haven't de-BASE64 them. Time spent is still ~2.5x of JKS (when reading from a ByteArrayInputStream). I guess the major reason is that there is no length field for the cert, so we must read-and-check all the time. --Max > On Aug 14, 2019, at 9:31 PM, Sean Mullan wrote: > > On 8/13/19 10:19 PM, Weijun Wang wrote: >>> I will also pass a pretty large cacerts with public CA and our CAs and >>> see wether your parser doesn't choke on it. >> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. > > This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 > > I would not want to see a regression in performance. > > --Sean From vladimir.kozlov at oracle.com Wed Aug 14 19:04:19 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Aug 2019 12:04:19 -0700 Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2AAB72087D@fmsmsx121.amr.corp.intel.com> References: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> <6563F381B547594081EF9DE181D079129615C797@fmsmsx123.amr.corp.intel.com> <7944585b-924c-ee2f-7880-ea8566c2b608@oracle.com> <8D6F463991A1574A8A803B8DA605414F411880D8@ORSMSX111.amr.corp.intel.com> <8D6F463991A1574A8A803B8DA605414F4118A53C@ORSMSX111.amr.corp.intel.com> <11bc5dad-0787-193b-fe69-9bf568f377f0@oracle.com> <8D6F463991A1574A8A803B8DA605414F4118E5B4@ORSMSX111.amr.corp.intel.com> <680c3821-de1e-5f17-0e8b-765837eca888@oracle.com> <4af33597-6c91-4cda-0c44-29a9e83678b3@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB72087D@fmsmsx121.amr.corp.intel.com> Message-ID: Yes, we got agreement from all parties. Vladimir On 8/14/19 10:44 AM, Deshpande, Vivek R wrote: > Hi Vladimir > > Can I sponsor and push the patch since you and ?Valerie have reviewed the patch? > > Regards, > > Vivek > > *From:*Valerie Peng [mailto:valerie.peng at oracle.com] > *Sent:* Friday, August 2, 2019 5:09 PM > *To:* Vladimir Kozlov ; Rukmannagari, Shravya ; Kamath, > Smita ; 'Anthony Scarpino' > *Cc:* OpenJDK Security ; Viswanathan, Sandhya ; Deshpande, > Vivek R ; Shemy, Regev > *Subject:* Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + > VAES instructions. > > Changes to the ElectronicCodeBook.java looks fine to me. > > Thanks, > > Valerie > > On 7/31/2019 2:38 PM, Vladimir Kozlov wrote: > > Good. Lets wait review from security team. > > Thank you > Vladimir > > On 7/31/19 2:20 PM, Rukmannagari, Shravya wrote: > > Hi Vladimir, > Thanks a lot for the review. I have responded to the JBS bug with the use cases for ECB. Please find the updated > webrev with no changes to the config file. > http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.02/ > > Thanks, > Shravya. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Sunday, July 28, 2019 3:31 PM > To: Rukmannagari, Shravya ; Kamath, > Smita ; 'Anthony Scarpino' > > Cc: Viswanathan, Sandhya ; Deshpande, > Vivek R ; 'hotspot compiler' > ; Shemy, Regev > ; OpenJDK Security > > Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using > AVX512 + VAES instructions. > > CCing to security-dev since you touched their class. > > Please answer Sean's question in the bug report. > > I don't think .jcheck/conf change should be part of this. > > Thanks, > Vladimir > > On 7/23/19 1:44 PM, Rukmannagari, Shravya wrote: > > Hi Vladimir, > I have updated the patch as per your suggestions. The JMH test > test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java has been > modified to add support for different key lengths. Please take a look > and let me know if you have any questions or comments. > http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.01/ > > Thanks, > Shravya. > > -----Original Message----- > From: Rukmannagari, Shravya > Sent: Monday, July 22, 2019 7:52 AM > To: Vladimir Kozlov ; Kamath, Smita > ; 'Anthony Scarpino' > > Cc: Viswanathan, Sandhya ; Deshpande, > Vivek R ; 'hotspot compiler' > ; Shemy, Regev > > Subject: RE: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using > AVX512 + VAES instructions. > > Hi Vladimir, > For checking the correctness, we have run the hotspot/jtreg/compiler/codegen/aes/TestAESMain.java and the > entire jtreg test suite. For the JMH benchmark tests, > test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java tests ECB for a key length of 128. I will > extend the test for other key lengths and send out an updated patch. > > Thanks, > Shravya. > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, July 18, 2019 4:02 PM > To: Kamath, Smita ; 'Anthony Scarpino' > > Cc: Viswanathan, Sandhya ; > Rukmannagari, Shravya ; Deshpande, > Vivek R ; 'hotspot compiler' > ; Shemy, Regev > > Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using > AVX512 + VAES instructions. > > Hi Smita > > I looked on changes and they seem fine in general (mostrly copy/past of cipherBlockChaining code). > > Few comments: > > Don't use _AVX3 in macroasm method names because you have only avx512 implementation. > > Indentions are bad in inline_electronicCodeBook_AESCrypt(). > > Add test to check results of optimization. > > Would be nice to have JMH test to see performance benefits. > > You also need to add checks to Graal's test [1] to prevent failure until this intrinsic is implemented in > Graal. > > Thanks, > Vladimir > > [1] > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspo > t.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java > > On 6/26/19 4:27 PM, Kamath, Smita wrote: > > Hi All, > > Could you please review AES-ECB implemented using AVX512+VAES instructions. > > Thanks and Regards, > > Smita Kamath > > *From:* Kamath, Smita > *Sent:* Tuesday, June 11, 2019 4:23 PM > *To:* 'Vladimir Kozlov' ; Anthony > Scarpino > *Cc:* Viswanathan, Sandhya ; Shravya > Rukmannagari > (shravya.rukmannagari at intel.com ) > ; > hotspot compiler ; > Shemy, > Regev > *Subject:* RFR(S) JDK-8225625: AES Electronic Codebook (ECB) > encryption and decryption optimizations using AVX512 + VAES instructions. > > Hi Vladimir, > > As per Intel Architecture Instruction Set Reference [1] Vector AES > Encrypt and Decrypt Operations will be supported in future Intel ISA. > We would like to contribute optimizations for AES-ECB algorithm to > support encryption and decryption operations using AVX512+VAES instructions. These optimizations are for > x86_64 architecture that have AVX512-VAES enabled. > > Shravya(cc'ed) and I are co-contributors. Shay > Gueron(shay.gueron at intel.com > ) and Regev Shemy > (regev.shemy at intel.com > ) are the authors of the algorithm. > > I have tested the algorithm with Intel SDE [2] to confirm encoding > and semantics are correctly implemented. > > Please take a look and let me know if you have any questions or comments. > > http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.00/ > > Bug Id: https://bugs.openjdk.java.net/browse/JDK-8225625 > > [1] > https://software.intel.com/sites/default/files/managed/ad/01/253666-s > d > m-vol-2a.pdf ?(Page 152 - 159) > > [2] > https://software.intel.com/en-us/articles/intel-software-development- > e > mulator > > Regards, > > Smita Kamath > From weijun.wang at oracle.com Thu Aug 15 02:21:11 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Aug 2019 10:21:11 +0800 Subject: [14] RFR 8229767: Typo in java.security: Sasl.createClient and Sasl.createServer Message-ID: <6643DA92-100E-4D90-AAD1-E75BD56F0C24@oracle.com> Bug is at https://bugs.openjdk.java.net/browse/JDK-8229767 . Please review the patch below: diff --git a/src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security --- a/src/java.base/share/conf/security/java.security +++ b/src/java.base/share/conf/security/java.security @@ -1166,7 +1166,7 @@ # # Disabled mechanisms will not be negotiated by both SASL clients and servers. # These mechanisms will be ignored if they are specified in the mechanisms argument -# of `Sasl.createClient` or the mechanism argument of `Sasl.createServer`. +# of `Sasl.createSaslClient` or the mechanism argument of `Sasl.createSaslServer`. # # The value of this property is a comma-separated list of SASL mechanisms. # The mechanisms are case-sensitive. Whitespaces around the commas are ignored. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From Xuelei.Fan at Oracle.Com Thu Aug 15 03:50:34 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Wed, 14 Aug 2019 20:50:34 -0700 Subject: [14] RFR 8229767: Typo in java.security: Sasl.createClient and Sasl.createServer In-Reply-To: <6643DA92-100E-4D90-AAD1-E75BD56F0C24@oracle.com> References: <6643DA92-100E-4D90-AAD1-E75BD56F0C24@oracle.com> Message-ID: <6497F38E-8FB7-40B4-9842-41EE16C930CE@Oracle.Com> Looks good to me. Xuelei > On Aug 14, 2019, at 7:21 PM, Weijun Wang wrote: > > Bug is at https://bugs.openjdk.java.net/browse/JDK-8229767. > > Please review the patch below: > > diff --git a/src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security > --- a/src/java.base/share/conf/security/java.security > +++ b/src/java.base/share/conf/security/java.security > @@ -1166,7 +1166,7 @@ > # > # Disabled mechanisms will not be negotiated by both SASL clients and servers. > # These mechanisms will be ignored if they are specified in the mechanisms argument > -# of `Sasl.createClient` or the mechanism argument of `Sasl.createServer`. > +# of `Sasl.createSaslClient` or the mechanism argument of `Sasl.createSaslServer`. > # > # The value of this property is a comma-separated list of SASL mechanisms. > # The mechanisms are case-sensitive. Whitespaces around the commas are ignored. > > Thanks, > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgnet.dev at gmail.com Thu Aug 15 03:56:12 2019 From: pgnet.dev at gmail.com (PGNet Dev) Date: Wed, 14 Aug 2019 20:56:12 -0700 Subject: TLSv1.3 TLS_CHACHA20_POLY1305_SHA256 ciphersuite support/backport for JDK 11 LTS ? In-Reply-To: References: Message-ID: <85f3a0e7-4dd3-5ae5-8cab-bf0278028708@gmail.com> anyone have any info on this? On 7/31/19 5:46 PM, PGNet Dev wrote: > Although JDK 11 already contains TLSv1.3 protocol support. > > TLS 1.3 Implementation > https://bugs.openjdk.java.net/browse/JDK-8202625 > > JDK-8145252 : JEP 332: Transport Layer Security (TLS) 1.3 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8145252 > > and, 'related' bugs suggest ChaCha20 cipher support is 'in', > > JDK-8153029 : ChaCha20 Cipher Implementation (11 b17, "Fixed") > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8140466 > > JDK-8140466 : ChaCha20 and Poly1305 TLS Cipher Suites > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8140466 (12 b12, "Fixed") > > TLSv1.3 connections via JDBC, using TSLv1.3 + its ChaCha20 cipher FAILed here, > > Error: Unsupported SSL cipher 'TLS_CHACHA20_POLY1305_SHA256' > > It appears that JDK 11 release supports only 2 of the 3 default TLSv1.3 ciphersuites, > > https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names > > ... > 0x13,0x01 TLS_AES_128_GCM_SHA256 Yes No N/A TLSv1.3 RFC 8446 > 0x13,0x02 TLS_AES_256_GCM_SHA384 Yes No N/A TLSv1.3 RFC 8446 > ... > > JDK12 adds ChaCha20 support, > > https://docs.oracle.com/en/java/javase/12/docs/specs/security/standard-names.html#jsse-cipher-suite-names > > ... > 0x13,0x01 TLS_AES_128_GCM_SHA256 Yes No N/A TLSv1.3 RFC 8446 > 0x13,0x02 TLS_AES_256_GCM_SHA384 Yes No N/A TLSv1.3 RFC 8446 >>> 0x13,0x03 TLS_CHACHA20_POLY1305_SHA256 No No N/A TLSv1.3 RFC 7905 > ... > > TLSv1.2/ChaCha20 connections with BOTH JDK 11 & 12 clients work. > > ONLY, TLSv1.3/ChaCha20 connections with JDK 12 client work without error. > > Is there a current plan/work to backport TLSv1.3/ChaCha20 support to JDK 11 LTS so it, too, can provide 'full' TLSv1.3 ciphersuite support? > From claes.redestad at oracle.com Thu Aug 15 10:03:45 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Aug 2019 12:03:45 +0200 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily Message-ID: Hi, by resolving permissions for code source URLs lazily, we can reduce early class loading during bootstrap, which improves footprint, startup and reduces the typical bootstrap dependency graph. Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 Webrev: http://cr.openjdk.java.net/~redestad/8229773/webrev.00/ A note on the System.java changes: The laziness makes it so that FilePermission isn't initialized eagerly, which has an implicit bootstrap dependency on that the default file system provider has been initialized before a SecurityManager has been installed (since initializing FilePermission will otherwise do recursive calls into FilePermission). We already force load of the image reader on SecurityManager due similar bootstrap issues, which transitively loads the DefaultFileSystemProvider.instance(), but explicitly adding the dependency on the file system provider to System::setSecurityManager seems prudent: it's effectively a no-op on jdk/jdk right now, but documents the dependency and safeguards against future implementation changes to image reader subsystem. A note on the HelloClasslist changes: The patch drops a number of classes from being loaded on typical bootstrap and small apps, including the HelloClasslist tool. Since the HelloClasslist establishes what's to be included in the default CDS archive this can lead to a small regression on apps which actually do use the (nio) file system provider, so explicitly adding it in avoids tiny regression on those while not diminishing the speed-up to other apps. Testing: tier1-3 Thanks! /Claes From Alan.Bateman at oracle.com Thu Aug 15 10:56:30 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Aug 2019 11:56:30 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: On 15/08/2019 11:03, Claes Redestad wrote: > Hi, > > by resolving permissions for code source URLs lazily, we can reduce > early class loading during bootstrap, which improves footprint, startup > and reduces the typical bootstrap dependency graph. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8229773 > Webrev: http://cr.openjdk.java.net/~redestad/8229773/webrev.00/ > > : I think the approach is okay as URL::openConnection doesn't actually open the connection to the resource and the creation of the URLStreamdHandler shouldn't depend on permissions granted to the caller. If a handler needs permissions when creating the URLConnection then it should do so in a privileged block. I think it would be a bit cleaner if the supporting class would lazily add the permissions for a CodeSource to the collection. That is, create it with a permissions collection and code source rather than a URL to match SecureClassLoader::getPermissions. You could potentially use it in URLClassLoader getPermission(CodeSource) method too. In System.setSecurityManager then you might need DefaultFileSystemProvider.theFileSystem() to ensure that the default file system is fully initialized before setting the SM. A minor nit this adds a spurious import BuiltinClassLoader. Also it can import the sun.security.uti class to be consistent with the existing code. -Alan From claes.redestad at oracle.com Thu Aug 15 12:44:37 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Aug 2019 14:44:37 +0200 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: Hi, On 2019-08-15 12:56, Alan Bateman wrote: > On 15/08/2019 11:03, Claes Redestad wrote: >> Hi, >> >> by resolving permissions for code source URLs lazily, we can reduce >> early class loading during bootstrap, which improves footprint, startup >> and reduces the typical bootstrap dependency graph. >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8229773 >> Webrev: ... >> >> : > I think the approach is okay as URL::openConnection doesn't actually > open the connection to the resource and the creation of the > URLStreamdHandler shouldn't depend on permissions granted to the caller. > If a handler needs permissions when creating the URLConnection then it > should do so in a privileged block. thanks! I checked most of the handlers and the openConnection implementations and couldn't find any path that isn't either free of permission checks or doing permission sensitive steps in a privileged block already. Many handlers are already potentially created lazily after a SM has already been installed, so I don't think we need additional tests for this. > I think it would be a bit cleaner if > the supporting class would lazily add the permissions for a CodeSource > to the collection. That is, create it with a permissions collection and > code source rather than a URL to match > SecureClassLoader::getPermissions. You could potentially use it in > URLClassLoader getPermission(CodeSource) method too. That'd be cool. The logic in URLClassLoader is mostly a super-set of the logic I'm hoisting from BuiltinClassLoader here, but the logic in URLClassLoader also has a security check acting on the ACC of the classloader which would be hard to move to the supporting class, and it seems that check need to happen eagerly. I'll readjust the API to wrap the CodeSource rather than the URL, but I think we should leave URLClassLoader alone for now. > > In System.setSecurityManager then you might need > DefaultFileSystemProvider.theFileSystem() to ensure that the default > file system is fully initialized before setting the SM. Right, doesn't make much of a difference since all providers currently set up their singleton file system on creation, but using theFileSystem better captures intent. > > A minor nit this adds a spurious import BuiltinClassLoader. Also it can > import the sun.security.uti class to be consistent with the existing code. Cleaned up imports, too: http://cr.openjdk.java.net/~redestad/8229773/webrev.01/ /Claes From sean.mullan at oracle.com Thu Aug 15 13:07:32 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 15 Aug 2019 09:07:32 -0400 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: Hi Claes, I already reviewed an earlier version of this and this is pretty similar. I did have a question about whether the default serialization was ok - did you look into that more? --Sean On 8/15/19 6:03 AM, Claes Redestad wrote: > Hi, > > by resolving permissions for code source URLs lazily, we can reduce > early class loading during bootstrap, which improves footprint, startup > and reduces the typical bootstrap dependency graph. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8229773 > Webrev: http://cr.openjdk.java.net/~redestad/8229773/webrev.00/ > > A note on the System.java changes: > > The laziness makes it so that FilePermission isn't initialized > eagerly, which has an implicit bootstrap dependency on that the default > file system provider has been initialized before a SecurityManager has > been installed (since initializing FilePermission will otherwise do > recursive calls into FilePermission). We already force load of the image > reader on SecurityManager due similar bootstrap issues, which > transitively loads the DefaultFileSystemProvider.instance(), but > explicitly adding the dependency on the file system provider to > System::setSecurityManager seems prudent: it's effectively a no-op on > jdk/jdk right now, but documents the dependency and safeguards against > future implementation changes to image reader subsystem. > > A note on the HelloClasslist changes: > > The patch drops a number of classes from being loaded on typical > bootstrap and small apps, including the HelloClasslist tool. Since the > HelloClasslist establishes what's to be included in the default CDS > archive this can lead to a small regression on apps which actually do > use the (nio) file system provider, so explicitly adding it in avoids > tiny regression on those while not diminishing the speed-up to other > apps. > > Testing: tier1-3 > > Thanks! > > /Claes From weijun.wang at oracle.com Thu Aug 15 13:34:45 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Aug 2019 21:34:45 +0800 Subject: [14] RFR 8229775: Incorrect warning when jar was signed with -sectionsonly Message-ID: <4C856C67-5D1C-4B6D-8A92-4EE2A474BCFB@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8229775/webrev.00/ The updated code checks both SHA-256-Digest-Manifest and SHA-256-Digest-Manifest-Main-Attributes. The latter should always appear in a SF file generated by our own jarsigner but theoretically it could be missing if MANIFEST.MF has no header. Anyway, checking both is more reliable. Thanks, Max From claes.redestad at oracle.com Thu Aug 15 14:30:19 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Aug 2019 16:30:19 +0200 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> Hi Sean, On 2019-08-15 15:07, Sean Mullan wrote: > Hi Claes, > > I already reviewed an earlier version of this and this is pretty > similar. I did have a question about whether the default serialization > was ok - did you look into that more? ah, yes.. all the constituents are serializable (whether we wrap the CodeSource or its URL) so the new Lazy..Collection should be too. I was entertaining the idea that we could writeReplace the lazy collection with a PermissionCollection to avoid polluting serialization use cases with new type, but couldn't think of any real upside to that. /Clae From Roger.Riggs at oracle.com Thu Aug 15 14:54:53 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 15 Aug 2019 10:54:53 -0400 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> Message-ID: Hi Claes, I would recommend using writeReplace to serialize the PermissionCollection so the serialized form does not change. Though these are unlikely to be serialized, it will be less likely to trigger some interoperability issue between different version. It may need to be documented that serializing/deserializing does not retain the lazyness. Roger On 8/15/19 10:30 AM, Claes Redestad wrote: > Hi Sean, > > On 2019-08-15 15:07, Sean Mullan wrote: >> Hi Claes, >> >> I already reviewed an earlier version of this and this is pretty >> similar. I did have a question about whether the default >> serialization was ok - did you look into that more? > > ah, yes.. all the constituents are serializable (whether we wrap the > CodeSource or its URL) so the new Lazy..Collection should be too. I was > entertaining the idea that we could writeReplace the lazy collection > with a PermissionCollection to avoid polluting serialization use cases > with new type, but couldn't think of any real upside to that. > > /Clae From daniel.fuchs at oracle.com Thu Aug 15 15:10:49 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 15 Aug 2019 16:10:49 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: <4862da5f-6c53-98ad-df9a-9236ba8e2e24@oracle.com> Hi Claes, I wonder if initialize() should check the state of the readOnly() flag - and if that's true, call perms.setReadOnly() ? see SecureClassLoader::getProtectionDomain(..) best regards, -- daniel On 15/08/2019 13:44, Claes Redestad wrote: > Hi, > > On 2019-08-15 12:56, Alan Bateman wrote: >> On 15/08/2019 11:03, Claes Redestad wrote: >>> Hi, >>> >>> by resolving permissions for code source URLs lazily, we can reduce >>> early class loading during bootstrap, which improves footprint, startup >>> and reduces the typical bootstrap dependency graph. >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8229773 >>> Webrev: ... >>> >>> : >> I think the approach is okay as URL::openConnection doesn't actually >> open the connection to the resource and the creation of the >> URLStreamdHandler shouldn't depend on permissions granted to the >> caller. If a handler needs permissions when creating the URLConnection >> then it should do so in a privileged block. > > thanks! > > I checked most of the handlers and the openConnection implementations > and couldn't find any path that isn't either free of permission checks > or doing permission sensitive steps in a privileged block already. Many > handlers are already potentially created lazily after a SM has already > been installed, so I don't think we need additional tests for this. > >> I think it would be a bit cleaner if the supporting class would lazily >> add the permissions for a CodeSource to the collection. That is, >> create it with a permissions collection and code source rather than a >> URL to match SecureClassLoader::getPermissions. You could potentially >> use it in URLClassLoader getPermission(CodeSource) method too. > > That'd be cool. The logic in URLClassLoader is mostly a super-set of the > logic I'm hoisting from BuiltinClassLoader here, but the logic in > URLClassLoader also has a security check acting on the ACC of the > classloader which would be hard to move to the supporting class, and it > seems that check need to happen eagerly. > > I'll readjust the API to wrap the CodeSource rather than the URL, but I > think we should leave URLClassLoader alone for now. > >> >> In System.setSecurityManager then you might need >> DefaultFileSystemProvider.theFileSystem() to ensure that the default >> file system is fully initialized before setting the SM. > > Right, doesn't make much of a difference since all providers currently > set up their singleton file system on creation, but using theFileSystem > better captures intent. > >> >> A minor nit this adds a spurious import BuiltinClassLoader. Also it >> can import the sun.security.uti class to be consistent with the >> existing code. > > Cleaned up imports, too: > > http://cr.openjdk.java.net/~redestad/8229773/webrev.01/ > > /Claes From claes.redestad at oracle.com Thu Aug 15 15:15:19 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Aug 2019 17:15:19 +0200 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <4862da5f-6c53-98ad-df9a-9236ba8e2e24@oracle.com> References: <4862da5f-6c53-98ad-df9a-9236ba8e2e24@oracle.com> Message-ID: <18336d6e-2c0f-809a-aa55-ca0d12b77047@oracle.com> Hi Daniel, seems prudent, especially if we are to writeReplace the underlying collection on serialization. /Claes On 2019-08-15 17:10, Daniel Fuchs wrote: > Hi Claes, > > I wonder if initialize() should check the state of > the readOnly() flag - and if that's true, call > perms.setReadOnly() ? > > see SecureClassLoader::getProtectionDomain(..) > > best regards, > > -- daniel From claes.redestad at oracle.com Thu Aug 15 15:22:14 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 15 Aug 2019 17:22:14 +0200 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> Message-ID: (adding back core-libs-dev) Hi Roger, seems easy enough to add a writeReplace: http://cr.openjdk.java.net/~redestad/8229773/webrev.02 /Claes On 2019-08-15 16:54, Roger Riggs wrote: > Hi Claes, > > I would recommend using writeReplace to serialize the > PermissionCollection so the serialized form does not change. > Though these are unlikely to be serialized, it will be less likely to > trigger some interoperability issue between different version. It may > need to be documented that serializing/deserializing does not retain the > lazyness. > > Roger > > > On 8/15/19 10:30 AM, Claes Redestad wrote: >> Hi Sean, >> >> On 2019-08-15 15:07, Sean Mullan wrote: >>> Hi Claes, >>> >>> I already reviewed an earlier version of this and this is pretty >>> similar. I did have a question about whether the default >>> serialization was ok - did you look into that more? >> >> ah, yes.. all the constituents are serializable (whether we wrap the >> CodeSource or its URL) so the new Lazy..Collection should be too. I was >> entertaining the idea that we could writeReplace the lazy collection >> with a PermissionCollection to avoid polluting serialization use cases >> with new type, but couldn't think of any real upside to that. >> >> /Clae > From Roger.Riggs at oracle.com Thu Aug 15 15:27:29 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 15 Aug 2019 11:27:29 -0400 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> Message-ID: <54d1f24b-a860-5dc7-6743-5b53b4a54cf5@oracle.com> Looks good, Thanks, Roger On 8/15/19 11:22 AM, Claes Redestad wrote: > (adding back core-libs-dev) > > Hi Roger, > > seems easy enough to add a writeReplace: > > http://cr.openjdk.java.net/~redestad/8229773/webrev.02 > > /Claes > > On 2019-08-15 16:54, Roger Riggs wrote: >> Hi Claes, >> >> I would recommend using writeReplace to serialize the >> PermissionCollection so the serialized form does not change. >> Though these are unlikely to be serialized, it will be less likely to >> trigger some interoperability issue between different version. It may >> need to be documented that serializing/deserializing does not retain >> the lazyness. >> >> Roger >> >> >> On 8/15/19 10:30 AM, Claes Redestad wrote: >>> Hi Sean, >>> >>> On 2019-08-15 15:07, Sean Mullan wrote: >>>> Hi Claes, >>>> >>>> I already reviewed an earlier version of this and this is pretty >>>> similar. I did have a question about whether the default >>>> serialization was ok - did you look into that more? >>> >>> ah, yes.. all the constituents are serializable (whether we wrap the >>> CodeSource or its URL) so the new Lazy..Collection should be too. I was >>> entertaining the idea that we could writeReplace the lazy collection >>> with a PermissionCollection to avoid polluting serialization use cases >>> with new type, but couldn't think of any real upside to that. >>> >>> /Clae >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Thu Aug 15 15:44:28 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 15 Aug 2019 16:44:28 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <54d1f24b-a860-5dc7-6743-5b53b4a54cf5@oracle.com> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <54d1f24b-a860-5dc7-6743-5b53b4a54cf5@oracle.com> Message-ID: <63f52c62-2779-b3d1-bfd3-5b414ecf526b@oracle.com> Thanks Claes, Looks good to me too. best regards, -- daniel On 15/08/2019 16:27, Roger Riggs wrote: > Looks good, > > Thanks, Roger > > > On 8/15/19 11:22 AM, Claes Redestad wrote: >> (adding back core-libs-dev) >> >> Hi Roger, >> >> seems easy enough to add a writeReplace: >> >> http://cr.openjdk.java.net/~redestad/8229773/webrev.02 >> >> /Claes >> From sean.mullan at oracle.com Thu Aug 15 17:10:57 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 15 Aug 2019 13:10:57 -0400 Subject: [14] RFR 8229775: Incorrect warning when jar was signed with -sectionsonly In-Reply-To: <4C856C67-5D1C-4B6D-8A92-4EE2A474BCFB@oracle.com> References: <4C856C67-5D1C-4B6D-8A92-4EE2A474BCFB@oracle.com> Message-ID: Looks fine to me. --Sean On 8/15/19 9:34 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8229775/webrev.00/ > > The updated code checks both SHA-256-Digest-Manifest and SHA-256-Digest-Manifest-Main-Attributes. The latter should always appear in a SF file generated by our own jarsigner but theoretically it could be missing if MANIFEST.MF has no header. Anyway, checking both is more reliable. > > Thanks, > Max > From 1983-01-06 at gmx.net Thu Aug 15 18:49:41 2019 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Thu, 15 Aug 2019 20:49:41 +0200 Subject: Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> Message-ID: > > On Aug 14, 2019, at 3:23 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > > > > Am 2019-08-13 um 18:23 schrieb Weijun Wang: > >> Please take a preliminary review at > >> > >> https://cr.openjdk.java.net/~weijun/8162628/webrev.00 > >> > >> There is no test yet. I mainly want you to see if this is doable and whether there can be any unexpected compatibility impact. > >> > >> So, the major points are: > >> > >> 1. Invent a new KeyStore type named "PEM", which is a stack of PEM-format certificates. It only support X.509 certificates and is read-only (at the moment). > >> 2. Migrate lib/security/cacerts to this format. > >> > >> Some details: > >> > >> 1. JKS/PKCS12/PEM is now aliases to each other, which means you can load a PKCS12 keystore using KeyStore.getInstance("pem"). This is an expansion of the former JKS/PKCS12 dual type. > >> 2. PEM supports engineProbe(), and returns true as long as the first 5 bytes are readable ASCII. This is because people might put comment before "-----BEGIN CERT-----". > >> 3. @attr can be added into comment as attributes in the comment area. cacerts will contain "@alias: aliasname". I'm still using the "[jdk]" label in the alias for jdkCA recognition. > > > > My comments: > > GenerateCacerts: > > * Why not use Files#newBufferedWriter(Path)? > > I like println. OK for me ;-) > > KeyStoreDelegator: > > * Please avoid iterating a list like an array and using List#get(int). > > But I have 2 lists. It is a Pair but Java does not have it, and I don't like Map::Entry very much. Granted, by why not use two iterators then? > > PemKeyStore: > > * It pretty much looks like you don't support private keys. Do you intend > > to deliver that in a seperate issue? > > To be determined, but no requirement now. Also, I don't want to invent a competitor for pkcs12. > > > * engineStore(): Why is that not supported? Without password of course. > > No requirement. I also don't want to see people losing their comments. Granted. > > * engineLoad(): > > ** Why not use Reader r = new Buffered...? > > readLine() is only in BufferedReader. Granted. > > ** split(":\\s*", 2): expect the unexpected: "@", kv might be null. > > jshell> "@".substring(1).split(":\\s*", 2) > $1 ==> String[1] { "" } Great! > > > > I will also pass a pretty large cacerts with public CA and our CAs and > > see wether your parser doesn't choke on it. Did you get a change to parse the file I have sent you? > PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. Commons Codec has a Base64InputStream. Maybe the entire file should be read as a stream with specific substreams for the base64 parts? That is, of course, much more coding work. Looking forward for your improvements. Do you see a change to backport this code to 11 and 8, but not changing the default keystore type? With that this great change could be available way earlier than Java 17 for most LTS people. Regards, Michael From Alan.Bateman at oracle.com Thu Aug 15 19:21:48 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Aug 2019 20:21:48 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> Message-ID: <36a9e4db-2380-fa0c-6675-18bb66213f09@oracle.com> On 15/08/2019 16:22, Claes Redestad wrote: > (adding back core-libs-dev) > > Hi Roger, > > seems easy enough to add a writeReplace: > > http://cr.openjdk.java.net/~redestad/8229773/webrev.02 This mostly looks good. In LazyCodeSourcePermissionCollection it think "initialize" should be renamed to "ensureAdded" as that more accurately describes what it does. Also the class description could do with a bit of word smiting to make it clear that permissions for a CodeSource are lazily added to the underlying permission collection. -Alan From mbalao at redhat.com Thu Aug 15 22:31:40 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 15 Aug 2019 19:31:40 -0300 Subject: RFR 8005819: Support cross-realm MSSFU Message-ID: Hi, I'd like to propose Webrev.00 for JDK-8005819 [1]: * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.00/ Implementation is based in the MS-SFU document [2]. Testing * ReferralsTest extended to support S4U2Self and S4U2Proxy referrals * No regressions found in jdk/sun/security/krb5 category * Tested against a real Active Directory 2016 setup, with 2 referral hops * Note: I can provide a PCAP capture and my internal test code if there is interest Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8005819 [2] - https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94 From valerie.peng at oracle.com Thu Aug 15 23:49:32 2019 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 15 Aug 2019 16:49:32 -0700 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" Message-ID: <608300e7-cc6e-6f73-ba93-eae8c7904340@oracle.com> Anyone has time to help review this fix? PKCS#11 v2.40 has inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec (sec 2..12.3) has: typedef struct CK_GCM_PARAMS { ??? CK_BYTE_PTR?????? pIv; ??? CK_ULONG????????? ulIvLen; ??? CK_BYTE_PTR?????? pAAD; ??? CK_ULONG????????? ulAADLen; ??? CK_ULONG????????? ulTagBits; } CK_GCM_PARAMS; However, the header file pkcs11t.h has an extra "ulIvBits" field: typedef struct CK_GCM_PARAMS { ??? CK_BYTE_PTR?????? pIv; ??? CK_ULONG????????? ulIvLen; *??? CK_ULONG????????? ulIvBits;* ??? CK_BYTE_PTR?????? pAAD; ??? CK_ULONG????????? ulAADLen; ??? CK_ULONG????????? ulTagBits; } CK_GCM_PARAMS; Some vendors such OpenHSM2 and Solaris go with the header file while some vendor such as NSS go with the mech spec. Current SunPKCS11 provider impl works with NSS but not with other vendors whose CK_GCM_PARAMS struct contains ulIvBits field. Based on testing results, OpenHSM2 and Solaris error out at init time when the parameter length does not have their expected value. Thus, one way to workaround this inconsistency is to re-try with a different structure for AES GCM when the init failed. In addition, given the parameters contains Iv and AAD which some vendor may use during subsequent enc/dec operations, I changed to use the same model as RSASSA-PSS to defer the freeing after the enc/dec operation is finished. Verified the changes on Solaris 11.4 against existing GCM regression tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ Thanks, Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivek.r.deshpande at intel.com Wed Aug 14 17:44:14 2019 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Wed, 14 Aug 2019 17:44:14 +0000 Subject: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. In-Reply-To: <4af33597-6c91-4cda-0c44-29a9e83678b3@oracle.com> References: <6563F381B547594081EF9DE181D0791296149EE6@fmsmsx123.amr.corp.intel.com> <6563F381B547594081EF9DE181D079129615C797@fmsmsx123.amr.corp.intel.com> <7944585b-924c-ee2f-7880-ea8566c2b608@oracle.com> <8D6F463991A1574A8A803B8DA605414F411880D8@ORSMSX111.amr.corp.intel.com> <8D6F463991A1574A8A803B8DA605414F4118A53C@ORSMSX111.amr.corp.intel.com> <11bc5dad-0787-193b-fe69-9bf568f377f0@oracle.com> <8D6F463991A1574A8A803B8DA605414F4118E5B4@ORSMSX111.amr.corp.intel.com> <680c3821-de1e-5f17-0e8b-765837eca888@oracle.com> <4af33597-6c91-4cda-0c44-29a9e83678b3@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2AAB72087D@fmsmsx121.amr.corp.intel.com> Hi Vladimir Can I sponsor and push the patch since you and Valerie have reviewed the patch? Regards, Vivek From: Valerie Peng [mailto:valerie.peng at oracle.com] Sent: Friday, August 2, 2019 5:09 PM To: Vladimir Kozlov ; Rukmannagari, Shravya ; Kamath, Smita ; 'Anthony Scarpino' Cc: OpenJDK Security ; Viswanathan, Sandhya ; Deshpande, Vivek R ; Shemy, Regev Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. Changes to the ElectronicCodeBook.java looks fine to me. Thanks, Valerie On 7/31/2019 2:38 PM, Vladimir Kozlov wrote: Good. Lets wait review from security team. Thank you Vladimir On 7/31/19 2:20 PM, Rukmannagari, Shravya wrote: Hi Vladimir, Thanks a lot for the review. I have responded to the JBS bug with the use cases for ECB. Please find the updated webrev with no changes to the config file. http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.02/ Thanks, Shravya. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Sunday, July 28, 2019 3:31 PM To: Rukmannagari, Shravya ; Kamath, Smita ; 'Anthony Scarpino' Cc: Viswanathan, Sandhya ; Deshpande, Vivek R ; 'hotspot compiler' ; Shemy, Regev ; OpenJDK Security Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. CCing to security-dev since you touched their class. Please answer Sean's question in the bug report. I don't think .jcheck/conf change should be part of this. Thanks, Vladimir On 7/23/19 1:44 PM, Rukmannagari, Shravya wrote: Hi Vladimir, I have updated the patch as per your suggestions. The JMH test test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java has been modified to add support for different key lengths. Please take a look and let me know if you have any questions or comments. http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.01/ Thanks, Shravya. -----Original Message----- From: Rukmannagari, Shravya Sent: Monday, July 22, 2019 7:52 AM To: Vladimir Kozlov ; Kamath, Smita ; 'Anthony Scarpino' Cc: Viswanathan, Sandhya ; Deshpande, Vivek R ; 'hotspot compiler' ; Shemy, Regev Subject: RE: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. Hi Vladimir, For checking the correctness, we have run the hotspot/jtreg/compiler/codegen/aes/TestAESMain.java and the entire jtreg test suite. For the JMH benchmark tests, test/micro/org/openjdk/bench/javax/crypto/full/AESBench.java tests ECB for a key length of 128. I will extend the test for other key lengths and send out an updated patch. Thanks, Shravya. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, July 18, 2019 4:02 PM To: Kamath, Smita ; 'Anthony Scarpino' Cc: Viswanathan, Sandhya ; Rukmannagari, Shravya ; Deshpande, Vivek R ; 'hotspot compiler' ; Shemy, Regev Subject: Re: RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. Hi Smita I looked on changes and they seem fine in general (mostrly copy/past of cipherBlockChaining code). Few comments: Don't use _AVX3 in macroasm method names because you have only avx512 implementation. Indentions are bad in inline_electronicCodeBook_AESCrypt(). Add test to check results of optimization. Would be nice to have JMH test to see performance benefits. You also need to add checks to Graal's test [1] to prevent failure until this intrinsic is implemented in Graal. Thanks, Vladimir [1] src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspo t.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java On 6/26/19 4:27 PM, Kamath, Smita wrote: Hi All, Could you please review AES-ECB implemented using AVX512+VAES instructions. Thanks and Regards, Smita Kamath *From:* Kamath, Smita *Sent:* Tuesday, June 11, 2019 4:23 PM *To:* 'Vladimir Kozlov' ; Anthony Scarpino *Cc:* Viswanathan, Sandhya ; Shravya Rukmannagari (shravya.rukmannagari at intel.com) ; hotspot compiler ; Shemy, Regev *Subject:* RFR(S) JDK-8225625: AES Electronic Codebook (ECB) encryption and decryption optimizations using AVX512 + VAES instructions. Hi Vladimir, As per Intel Architecture Instruction Set Reference [1] Vector AES Encrypt and Decrypt Operations will be supported in future Intel ISA. We would like to contribute optimizations for AES-ECB algorithm to support encryption and decryption operations using AVX512+VAES instructions. These optimizations are for x86_64 architecture that have AVX512-VAES enabled. Shravya(cc'ed) and I are co-contributors. Shay Gueron(shay.gueron at intel.com ) and Regev Shemy (regev.shemy at intel.com ) are the authors of the algorithm. I have tested the algorithm with Intel SDE [2] to confirm encoding and semantics are correctly implemented. Please take a look and let me know if you have any questions or comments. http://cr.openjdk.java.net/~vdeshpande/AES-ECB/webrev.00/ Bug Id: https://bugs.openjdk.java.net/browse/JDK-8225625 [1] https://software.intel.com/sites/default/files/managed/ad/01/253666-s d m-vol-2a.pdf (Page 152 - 159) [2] https://software.intel.com/en-us/articles/intel-software-development- e mulator Regards, Smita Kamath -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Thu Aug 15 22:20:15 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 16 Aug 2019 08:20:15 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: <5D55DA9F.5050807@zeus.net.au> Hello Claes, The following code is included in the constructor of our SecurityManager implementation, I suspect we may need to add some classes to this list, perhaps this is something that needs documenting? Regards, Peter. /* The following ensures the classes we need are loaded early to avoid * class loading deadlock during permission checks */ try { checkPermission(new RuntimePermission("setIO"), SMPrivilegedContext); } catch (ExceptionInInitializerError er){ Error e = new ExceptionInInitializerError( "All domains on stack when starting a security manager must have AllPermission"); e.initCause(er); throw e; } constructed = Security.class != null; On 15/08/2019 8:03 PM, Claes Redestad wrote: > Hi, > > by resolving permissions for code source URLs lazily, we can reduce > early class loading during bootstrap, which improves footprint, startup > and reduces the typical bootstrap dependency graph. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 > Webrev: http://cr.openjdk.java.net/~redestad/8229773/webrev.00/ > > A note on the System.java changes: > > The laziness makes it so that FilePermission isn't initialized > eagerly, which has an implicit bootstrap dependency on that the default > file system provider has been initialized before a SecurityManager has > been installed (since initializing FilePermission will otherwise do > recursive calls into FilePermission). We already force load of the image > reader on SecurityManager due similar bootstrap issues, which > transitively loads the DefaultFileSystemProvider.instance(), but > explicitly adding the dependency on the file system provider to > System::setSecurityManager seems prudent: it's effectively a no-op on > jdk/jdk right now, but documents the dependency and safeguards against > future implementation changes to image reader subsystem. > > A note on the HelloClasslist changes: > > The patch drops a number of classes from being loaded on typical > bootstrap and small apps, including the HelloClasslist tool. Since the > HelloClasslist establishes what's to be included in the default CDS > archive this can lead to a small regression on apps which actually do > use the (nio) file system provider, so explicitly adding it in avoids > tiny regression on those while not diminishing the speed-up to other > apps. > > Testing: tier1-3 > > Thanks! > > /Claes From peter.firmstone at zeus.net.au Thu Aug 15 23:39:24 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 16 Aug 2019 09:39:24 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: <5D55ED2C.6000306@zeus.net.au> Hello Alan, This is related to URL and CodeSource and might be worth making a note of for future reference. Our software uses delayed dynamically assigned permissions via a policy provider, but for privileged domains that have AllPermission we make sure to assign this up front (We also utilise an RFC3986URIClassLoader and override CodeSource, so we're using our RFC3986 compliant URI instead of URL). The former because we dynamically download CodeSource's and there's no way of predicting up front which will be downloaded and the latter as a performance optimisation of ProtectionDomain. So we have a RFC3986 URI implementation, similar to Java's URI, it is not Serializable for security reasons. In addition to RFC3896 normalization, we have also recently added the ability to normalize IPv6 address conformant to "RFC 5952 A Recommendation for IPv6 Address Text Representation." The class also normalizes file system paths in a platform dependant manner, eg Upper Case for MS Windows, but not Unix. We have a URI::implies method that is similar to CodeSource::implies, with matching rules. We do this to avoid DNS calls or accessing the file system unnecessarily. Also, to avoid synchronization / locking overhead of PermissionCollection's and Permissions, we have a Policy provider that generates a thread confined Permissions and PermissionCollection instances on demand, allowing them to be garbage collected as soon as the implies call returns (Permission objects are initialized up front and effectively immutable and cached) a PermissionComparator also arranges the Permissions in an order that improves performance wen creating PermissionCollection instances. Our Security overhead is less than 1% as a result and the delays and blocking we had due to DNS calls have been eliminated. Regards, Peter. On 15/08/2019 8:56 PM, Alan Bateman wrote: > On 15/08/2019 11:03, Claes Redestad wrote: >> Hi, >> >> by resolving permissions for code source URLs lazily, we can reduce >> early class loading during bootstrap, which improves footprint, startup >> and reduces the typical bootstrap dependency graph. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 >> Webrev: http://cr.openjdk.java.net/~redestad/8229773/webrev.00/ >> >> : > I think the approach is okay as URL::openConnection doesn't actually > open the connection to the resource and the creation of the > URLStreamdHandler shouldn't depend on permissions granted to the > caller. If a handler needs permissions when creating the URLConnection > then it should do so in a privileged block. I think it would be a bit > cleaner if the supporting class would lazily add the permissions for a > CodeSource to the collection. That is, create it with a permissions > collection and code source rather than a URL to match > SecureClassLoader::getPermissions. You could potentially use it in > URLClassLoader getPermission(CodeSource) method too. > > In System.setSecurityManager then you might need > DefaultFileSystemProvider.theFileSystem() to ensure that the default > file system is fully initialized before setting the SM. > > A minor nit this adds a spurious import BuiltinClassLoader. Also it > can import the sun.security.uti class to be consistent with the > existing code. > > -Alan > > > From peter.firmstone at zeus.net.au Fri Aug 16 00:18:14 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 16 Aug 2019 10:18:14 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> Message-ID: <5D55F646.3090907@zeus.net.au> Hi Roger, +1 for writeReplace Personally I'd like to see some security classes break backward compatibility and remove support for serialization as it allows someone to get references to internal objects, especially since these classes are cached by the JVM. Which makes PermissionCollection.setReadOnly() very easy to bypass, by adding permissions to internal collections once you have a reference to them. Does anyone have any use cases for serializing these objects? These objects are easy to re-create by sending or recieving and parsing strings, because they are built from text based policy files, and when you do that, you are validating input, so I never did fully understand why they were made serializable. Regards, Peter. On 16/08/2019 12:54 AM, Roger Riggs wrote: > Hi Claes, > > I would recommend using writeReplace to serialize the > PermissionCollection so the serialized form does not change. > Though these are unlikely to be serialized, it will be less likely to > trigger some interoperability issue between different version. It may > need to be documented that serializing/deserializing does not retain > the lazyness. > > Roger > > > On 8/15/19 10:30 AM, Claes Redestad wrote: >> Hi Sean, >> >> On 2019-08-15 15:07, Sean Mullan wrote: >>> Hi Claes, >>> >>> I already reviewed an earlier version of this and this is pretty >>> similar. I did have a question about whether the default >>> serialization was ok - did you look into that more? >> >> ah, yes.. all the constituents are serializable (whether we wrap the >> CodeSource or its URL) so the new Lazy..Collection should be too. I was >> entertaining the idea that we could writeReplace the lazy collection >> with a PermissionCollection to avoid polluting serialization use cases >> with new type, but couldn't think of any real upside to that. >> >> /Clae > From weijun.wang at oracle.com Fri Aug 16 00:29:39 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 16 Aug 2019 08:29:39 +0800 Subject: RFR 8005819: Support cross-realm MSSFU In-Reply-To: References: Message-ID: > On Aug 16, 2019, at 6:31 AM, Martin Balao wrote: > > Hi, > > I'd like to propose Webrev.00 for JDK-8005819 [1]: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.00/ > > Implementation is based in the MS-SFU document [2]. > > Testing > > * ReferralsTest extended to support S4U2Self and S4U2Proxy referrals > > * No regressions found in jdk/sun/security/krb5 category > > * Tested against a real Active Directory 2016 setup, with 2 referral hops > * Note: I can provide a PCAP capture and my internal test code if > there is interest It will be nice if you can describe the test environment setup in detail so we can setup a similar one. Thanks, Max > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8005819 > [2] - > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94 From weijun.wang at oracle.com Fri Aug 16 01:36:38 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 16 Aug 2019 09:36:38 +0800 Subject: Re Re: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> Message-ID: > On Aug 16, 2019, at 2:49 AM, Michael Osipov <1983-01-06 at gmx.net> wrote: > >>>> https://cr.openjdk.java.net/~weijun/8162628/webrev.00 >>>> >>> KeyStoreDelegator: >>> * Please avoid iterating a list like an array and using List#get(int). >> >> But I have 2 lists. It is a Pair but Java does not have it, and I don't like Map::Entry very much. > > Granted, by why not use two iterators then? How? > >>> >>> I will also pass a pretty large cacerts with public CA and our CAs and >>> see wether your parser doesn't choke on it. > > Did you get a change to parse the file I have sent you? Yes I tried. keytool -list accepts it and is using SHA-256 fingerprint as aliases. > >> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. > > Commons Codec has a Base64InputStream. Maybe the entire file should be read as a stream with specific substreams > for the base64 parts? That is, of course, much more coding work. If the certs are to be parsed at loading, I'll see if I can inline a BASE64 decoder inside so it recognizes everything from BASE64 chars, -----'s, and @alias. If the cert parsing can be delayed I'll see if there is a quicker way to find the end of the cert (maybe read the first few bytes and get the length). > > Looking forward for your improvements. > > Do you see a change to backport this code to 11 and 8, but not changing the default keystore type? With that > this great change could be available way earlier than Java 17 for most LTS people. There is no need to change the default keystore type if keystore.type.compat=true and we allows a PEM keystore to be loadable as a JKS keystore. I cannot say if this can be backported. It depends on the policy. On the other hand, you also know there are other vendors of JDK that could have different policies. Thanks, Max > > Regards, > > Michael From Alan.Bateman at oracle.com Fri Aug 16 07:04:47 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Aug 2019 08:04:47 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D55DA9F.5050807@zeus.net.au> References: <5D55DA9F.5050807@zeus.net.au> Message-ID: <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> On 15/08/2019 23:20, Peter Firmstone wrote: > : > > The following code is included in the constructor of our > SecurityManager implementation, I suspect we may need to add some > classes to this list, perhaps this is something that needs documenting? The checkPermission method of custom security manager can run arbitrary code so recursive initialization, stack overflow, bootstrap method errors, ... are always hazards. I don't know what documentation you have in mind but I don't think there is a definite list of classes that need to be loaded/initialized before the custom security manager is set because it will come down to the code that it executes in its checkPermission method. -Alan. From claes.redestad at oracle.com Fri Aug 16 11:14:46 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 16 Aug 2019 13:14:46 +0200 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D568810.8060503@zeus.net.au> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> Message-ID: <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> Hi Peter, by explicitly ensuring the file system has been initialized before installing a SecurityManager using a hook in System.setSecurityManager, the patch at hand takes step to ensure things stay neutral w.r.t. Permission initialization order when using any SecurityManager. It's not perfectly identical, so while unlikely, there's a theoretical possibility some implementation scenario not covered by our regression tests might run into issues. Any help testing custom implementation on coming EA builds would be greatly appreciated! One thing we could do on the JDK end to reduce fragility somewhat in this area is to provoke initialization of sun.security.util.SecurityConstants before installing the first SM. /Claes On 2019-08-16 12:40, Peter Firmstone wrote: > Hello Alan, > > Yes, we are aware of those issues. > > I mean documenting that system Permission classes should be loaded > before setting a custom SecurityManager, accessing the file system is > important, so if you haven't loaded the necessary classes before setting > a custom SecurityManager, it won't be gracefull...? The simplest way of > ensuring classes are loaded is by creating object instances of them. > > Perhaps just a note to beware of ensuring necessary classes are loaded > and let developers figure out what they need. > > The recursive calls are easy enough to deal with to avoid any stack > overflows using ThreadLocal. > > inTrustedCodeRecursiveCall.set(Boolean.TRUE); > ??????????? try { > ??????????????? delegateContext = AccessController.doPrivileged( > ??????????????????? new PrivilegedAction(){ > ??????????????????????? public AccessControlContext run() { > ??????????????????????????? return new > AccessControlContext(finalExecutionContext, dc); > ??????????????????????? } > ??????????????????? } > ??????????????? ); > ??????????? }finally { > ??????????????? inTrustedCodeRecursiveCall.set(Boolean.FALSE); // Must > always happen, no matter what. > ??????????? } > > We've only really been caught out once with some jvm bootstrap changes, > otherwise it's been rock solid. > > The other thing we do is once we've got more than three > ProtectionDomains on the stack is execute the ProtectionDomain implies > checks in parallel.? Really helps when you're making a lot of network > calls. > > Cheers, > > Peter. > > On 16/08/2019 5:04 PM, Alan Bateman wrote: >> On 15/08/2019 23:20, Peter Firmstone wrote: >>> : >>> >>> The following code is included in the constructor of our >>> SecurityManager implementation, I suspect we may need to add some >>> classes to this list, perhaps this is something that needs documenting? >> The checkPermission method of custom security manager can run >> arbitrary code so recursive initialization, stack overflow, bootstrap >> method errors, ... are always hazards. I don't know what documentation >> you have in mind but I don't think there is a definite list of classes >> that need to be loaded/initialized before the custom security manager >> is set because it will come down to the code that it executes in its >> checkPermission method. >> >> -Alan. >> >> > From claes.redestad at oracle.com Fri Aug 16 12:30:02 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 16 Aug 2019 14:30:02 +0200 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <36a9e4db-2380-fa0c-6675-18bb66213f09@oracle.com> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <36a9e4db-2380-fa0c-6675-18bb66213f09@oracle.com> Message-ID: <29f787cf-a4ab-c294-69ee-2361fdfe0186@oracle.com> On 2019-08-15 21:21, Alan Bateman wrote: > On 15/08/2019 16:22, Claes Redestad wrote: >> (adding back core-libs-dev) >> >> Hi Roger, >> >> seems easy enough to add a writeReplace: >> >> http://cr.openjdk.java.net/~redestad/8229773/webrev.02 > This mostly looks good. In LazyCodeSourcePermissionCollection it think > "initialize" should be renamed to "ensureAdded" as that more accurately > describes what it does. Also the class description could do with a bit > of word smiting to make it clear that permissions for a CodeSource are > lazily added to the underlying permission collection. How about this: http://cr.openjdk.java.net/~redestad/8229773/webrev.03/ Also simplified BuiltinClassLoader#getPermissions since the jrt-specific optimization is now redundant. /Claes From sean.mullan at oracle.com Fri Aug 16 14:50:11 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Aug 2019 10:50:11 -0400 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D55F646.3090907@zeus.net.au> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <5D55F646.3090907@zeus.net.au> Message-ID: On 8/15/19 8:18 PM, Peter Firmstone wrote: > Hi Roger, > > +1 for writeReplace > > Personally I'd like to see some security classes break backward > compatibility and remove support for serialization as it allows someone > to get references to internal objects, especially since these classes > are cached by the JVM.? Which makes PermissionCollection.setReadOnly() > very easy to bypass, by adding permissions to internal collections once > you have a reference to them. > > Does anyone have any use cases for serializing these objects? > > These objects are easy to re-create by sending or recieving and parsing > strings, because they are built from text based policy files, and when > you do that, you are validating input, so I never did fully understand > why they were made serializable. This is briefly explained on page 61 in the "Inside Java 2 Platform Security" book [1]: "The Permission class implements two interfaces: java.security.Guard and java.io.Serializable. For the latter, the intention is that Permission objects may be transported to remote machines, such as via Remote Method Invocation (RMI), and thus a Serializable representation is useful." The Permission class was introduced in Java SE 1.2 so there were different motivations back then :) --Sean [1] https://www.oracle.com/technetwork/java/javaee/index-141918.html From xuelei.fan at oracle.com Fri Aug 16 16:36:32 2019 From: xuelei.fan at oracle.com (Xue-Lei Fan) Date: Fri, 16 Aug 2019 09:36:32 -0700 (PDT) Subject: [RFR] JDK-8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException Message-ID: <3051a05b-ed8e-4e01-99ca-6b23f77fb908@default> Good catch! For the engineGetOutputSize() implementation, as the inputLen parameter is an external input, we may want to ensure it is not too big to integer overflow. The Math.addExact() was used to check the overflow issues. What do you think we keep using the Math.addExact() method, at line 1243 and 1314? Otherwise, looks fine to me. Xuelei ----- Original Message ----- From: jamil.j.nimeh at oracle.com To: security-dev at openjdk.java.net Sent: Monday, August 12, 2019 12:59:32 PM GMT -08:00 US/Canada Pacific Subject: [RFR] JDK-8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException Hello all, This fix addresses a problem first found by Netty/Jetty when decrypting payloads in excess of ~4096 bytes using one of the ChaCha20-Poly1305 cipher suites.? The root cause of the issue is not in the TLS code, it is actually an issue with how ChaCha20-Poly1305 was implementing CipherSpi.engineGetOutputSize(). The bug was also partially worked around due to changes in CipherSpi from 8181386, but this properly addresses the output buffer sizing. Thanks to Adrian Todt and Bradley Wagner for the Catnip and Jetty support while trying to replicate the issue originally. Bug: https://bugs.openjdk.java.net/browse/JDK-8224997 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8224997/webrev.01/ --Jamil From Alan.Bateman at oracle.com Fri Aug 16 16:38:41 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Aug 2019 17:38:41 +0100 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <29f787cf-a4ab-c294-69ee-2361fdfe0186@oracle.com> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <36a9e4db-2380-fa0c-6675-18bb66213f09@oracle.com> <29f787cf-a4ab-c294-69ee-2361fdfe0186@oracle.com> Message-ID: On 16/08/2019 13:30, Claes Redestad wrote: > > How about this: > > http://cr.openjdk.java.net/~redestad/8229773/webrev.03/ > > Also simplified BuiltinClassLoader#getPermissions since the jrt-specific > optimization is now redundant. > Looks good. -Alan From sean.mullan at oracle.com Fri Aug 16 16:51:25 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Aug 2019 12:51:25 -0400 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <36a9e4db-2380-fa0c-6675-18bb66213f09@oracle.com> <29f787cf-a4ab-c294-69ee-2361fdfe0186@oracle.com> Message-ID: +1 from me as well. --Sean On 8/16/19 12:38 PM, Alan Bateman wrote: > On 16/08/2019 13:30, Claes Redestad wrote: >> >> How about this: >> >> http://cr.openjdk.java.net/~redestad/8229773/webrev.03/ >> >> Also simplified BuiltinClassLoader#getPermissions since the jrt-specific >> optimization is now redundant. >> > Looks good. > > -Alan > From Roger.Riggs at oracle.com Fri Aug 16 17:00:29 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 16 Aug 2019 13:00:29 -0400 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <36a9e4db-2380-fa0c-6675-18bb66213f09@oracle.com> <29f787cf-a4ab-c294-69ee-2361fdfe0186@oracle.com> Message-ID: +1 On 8/16/19 12:51 PM, Sean Mullan wrote: > +1 from me as well. > > --Sean > > On 8/16/19 12:38 PM, Alan Bateman wrote: >> On 16/08/2019 13:30, Claes Redestad wrote: >>> >>> How about this: >>> >>> http://cr.openjdk.java.net/~redestad/8229773/webrev.03/ >>> >>> Also simplified BuiltinClassLoader#getPermissions since the >>> jrt-specific >>> optimization is now redundant. >>> >> Looks good. >> >> -Alan >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Fri Aug 16 10:40:16 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 16 Aug 2019 20:40:16 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> Message-ID: <5D568810.8060503@zeus.net.au> Hello Alan, Yes, we are aware of those issues. I mean documenting that system Permission classes should be loaded before setting a custom SecurityManager, accessing the file system is important, so if you haven't loaded the necessary classes before setting a custom SecurityManager, it won't be gracefull... The simplest way of ensuring classes are loaded is by creating object instances of them. Perhaps just a note to beware of ensuring necessary classes are loaded and let developers figure out what they need. The recursive calls are easy enough to deal with to avoid any stack overflows using ThreadLocal. inTrustedCodeRecursiveCall.set(Boolean.TRUE); try { delegateContext = AccessController.doPrivileged( new PrivilegedAction(){ public AccessControlContext run() { return new AccessControlContext(finalExecutionContext, dc); } } ); }finally { inTrustedCodeRecursiveCall.set(Boolean.FALSE); // Must always happen, no matter what. } We've only really been caught out once with some jvm bootstrap changes, otherwise it's been rock solid. The other thing we do is once we've got more than three ProtectionDomains on the stack is execute the ProtectionDomain implies checks in parallel. Really helps when you're making a lot of network calls. Cheers, Peter. On 16/08/2019 5:04 PM, Alan Bateman wrote: > On 15/08/2019 23:20, Peter Firmstone wrote: >> : >> >> The following code is included in the constructor of our >> SecurityManager implementation, I suspect we may need to add some >> classes to this list, perhaps this is something that needs documenting? > The checkPermission method of custom security manager can run > arbitrary code so recursive initialization, stack overflow, bootstrap > method errors, ... are always hazards. I don't know what documentation > you have in mind but I don't think there is a definite list of classes > that need to be loaded/initialized before the custom security manager > is set because it will come down to the code that it executes in its > checkPermission method. > > -Alan. > > From jamil.j.nimeh at oracle.com Fri Aug 16 21:25:23 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 16 Aug 2019 14:25:23 -0700 Subject: [RFR] JDK-8225436 : Stapled OCSPResponses should be added to PKIXRevocationChecker irrespective of revocationEnabled flag Message-ID: <3ab31cad-2d03-2462-922b-9015e1e0c233@oracle.com> Hello all, This fixes a bug where stapled OCSP responses were being ignored by the internal Validator in all cases when revocation checking is disabled.? If the TrustManagerFactory is initialized with CertPathParameters that include a PKIXRevocationChecker, then that should override the setRevocationEnabled flag and any stapled responses should be taken into account during path validation. Bug: https://bugs.openjdk.java.net/browse/JDK-8225436 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8225436/webrev.01/ Thanks, --Jamil From jamil.j.nimeh at oracle.com Fri Aug 16 22:44:54 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 16 Aug 2019 15:44:54 -0700 Subject: [RFR] JDK-8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException In-Reply-To: <3051a05b-ed8e-4e01-99ca-6b23f77fb908@default> References: <3051a05b-ed8e-4e01-99ca-6b23f77fb908@default> Message-ID: I think that's a good idea.? I've made the change. http://cr.openjdk.java.net/~jnimeh/reviews/8224997/webrev.02/ Thanks for the review, --Jamil On 8/16/19 9:36 AM, Xue-Lei Fan wrote: > Good catch! > > For the engineGetOutputSize() implementation, as the inputLen parameter is an external input, we may want to ensure it is not too big to integer overflow. The Math.addExact() was used to check the overflow issues. What do you think we keep using the Math.addExact() method, at line 1243 and 1314? > > Otherwise, looks fine to me. > > Xuelei > > ----- Original Message ----- > From:jamil.j.nimeh at oracle.com > To:security-dev at openjdk.java.net > Sent: Monday, August 12, 2019 12:59:32 PM GMT -08:00 US/Canada Pacific > Subject: [RFR] JDK-8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException > > Hello all, > > This fix addresses a problem first found by Netty/Jetty when decrypting > payloads in excess of ~4096 bytes using one of the ChaCha20-Poly1305 > cipher suites.? The root cause of the issue is not in the TLS code, it > is actually an issue with how ChaCha20-Poly1305 was implementing > CipherSpi.engineGetOutputSize(). > > The bug was also partially worked around due to changes in CipherSpi > from 8181386, but this properly addresses the output buffer sizing. > > Thanks to Adrian Todt and Bradley Wagner for the Catnip and Jetty > support while trying to replicate the issue originally. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8224997 > > Webrev:http://cr.openjdk.java.net/~jnimeh/reviews/8224997/webrev.01/ > > --Jamil > From Xuelei.Fan at Oracle.Com Sat Aug 17 04:25:10 2019 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Fri, 16 Aug 2019 21:25:10 -0700 Subject: [RFR] JDK-8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException In-Reply-To: References: <3051a05b-ed8e-4e01-99ca-6b23f77fb908@default> Message-ID: <3BACD7A8-0CAD-4042-ABA7-B28631CF72AE@Oracle.Com> Looks good to me. Xuelei > On Aug 16, 2019, at 3:44 PM, Jamil Nimeh wrote: > > I think that's a good idea. I've made the change. > > http://cr.openjdk.java.net/~jnimeh/reviews/8224997/webrev.02/ > > Thanks for the review, > > --Jamil > >> On 8/16/19 9:36 AM, Xue-Lei Fan wrote: >> Good catch! >> >> For the engineGetOutputSize() implementation, as the inputLen parameter is an external input, we may want to ensure it is not too big to integer overflow. The Math.addExact() was used to check the overflow issues. What do you think we keep using the Math.addExact() method, at line 1243 and 1314? >> >> Otherwise, looks fine to me. >> >> Xuelei >> >> ----- Original Message ----- >> From:jamil.j.nimeh at oracle.com >> To:security-dev at openjdk.java.net >> Sent: Monday, August 12, 2019 12:59:32 PM GMT -08:00 US/Canada Pacific >> Subject: [RFR] JDK-8224997: ChaCha20-Poly1305 TLS cipher suite decryption throws ShortBufferException >> >> Hello all, >> >> This fix addresses a problem first found by Netty/Jetty when decrypting >> payloads in excess of ~4096 bytes using one of the ChaCha20-Poly1305 >> cipher suites. The root cause of the issue is not in the TLS code, it >> is actually an issue with how ChaCha20-Poly1305 was implementing >> CipherSpi.engineGetOutputSize(). >> >> The bug was also partially worked around due to changes in CipherSpi >> from 8181386, but this properly addresses the output buffer sizing. >> >> Thanks to Adrian Todt and Bradley Wagner for the Catnip and Jetty >> support while trying to replicate the issue originally. >> >> Bug:https://bugs.openjdk.java.net/browse/JDK-8224997 >> >> Webrev:http://cr.openjdk.java.net/~jnimeh/reviews/8224997/webrev.01/ >> >> --Jamil >> From claes.redestad at oracle.com Mon Aug 19 06:52:24 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 19 Aug 2019 08:52:24 +0200 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <36a9e4db-2380-fa0c-6675-18bb66213f09@oracle.com> <29f787cf-a4ab-c294-69ee-2361fdfe0186@oracle.com> Message-ID: Thanks everyone. Pushed. /Claes Roger Riggs skrev: (16 augusti 2019 19:00:29 CEST) >+1 > >On 8/16/19 12:51 PM, Sean Mullan wrote: >> +1 from me as well. >> >> --Sean >> >> On 8/16/19 12:38 PM, Alan Bateman wrote: >>> On 16/08/2019 13:30, Claes Redestad wrote: >>>> >>>> How about this: >>>> >>>> http://cr.openjdk.java.net/~redestad/8229773/webrev.03/ >>>> >>>> Also simplified BuiltinClassLoader#getPermissions since the >>>> jrt-specific >>>> optimization is now redundant. >>>> >>> Looks good. >>> >>> -Alan >>> -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Mon Aug 19 07:17:01 2019 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 19 Aug 2019 15:17:01 +0800 Subject: FRF[14] JDK-8228967: Trust/Key store and SSL context utilities for tests In-Reply-To: References: Message-ID: <9d52a94b-e3fd-8fad-8d8d-6de24a6f9a5c@oracle.com> Could this patch be reviewed? Best regards, John On 2019/8/4 07:32, sha.jiang at oracle.com wrote: > Hi Sean, > I moved test/jdk/java/security/testlibrary/CertUtils.java? to > test/lib/jdk/test/lib/security/CertUtils.java, and added the new > methods to this class. > The affected existing tests are also modified. > > http://cr.openjdk.java.net/~jjiang/8228967/webrev.01/ > > Best regards, > John Jiang > > On 2019/8/2 19:26, Sean Mullan wrote: >> Not a full review but there is already a utility class for creating >> certificates, etc in test/jdk/java/security/testlibrary/CertUtils.java >> Could you combine/merge that with your new CertUtils class? >> >> --Sean >> >> On 8/2/19 4:29 AM, sha.jiang at oracle.com wrote: >>> Hi, >>> This enhancement provides a set of utilities for creating >>> certificate, trust/key store and SSL context. >>> It provides the default trust and key stores with RSA, ECDSA, >>> RSASSA-PSS and DSA certificates, and also the default TLS and DTLS >>> contexts with the default trust and key stores. >>> Three tests are modified for demonstrating the usages. >>> >>> Webrev: http://cr.openjdk.java.net/~jjiang/8228967/webrev.00/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8228967 >>> >>> Best regards, >>> John Jiang >>> >> > From christian.schaefer at microfocus.com Mon Aug 19 11:33:12 2019 From: christian.schaefer at microfocus.com (Christian Schaefer) Date: Mon, 19 Aug 2019 11:33:12 +0000 Subject: Allow to define the list of enabled named curves for EC cipher suites as Security Property Message-ID: Hi all, Today, the list of enabled named curves for EC cipher suites can be specified as "System Property" (name of the system property is jdk.tls.namedGroups) in JDK 8 and later. It seems like it cannot be specified as "Security Property". So unlike jdk.tls.disabledAlgorithms and jdk.certpath.disabledAlgorithms the property jdk.tls.namedGroups cannot be specified in the security properties file (i.e. lib/security/java.security). Is there any chance to enhance this in a future version so that jdk.tls.namedGroups can also be specified in the security properties file or is there a reason which I don't see that explains why jdk.tls.namedGroups can only be specified as System Property? Regards, Christian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon Aug 19 12:23:23 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Aug 2019 08:23:23 -0400 Subject: Is Digicert's continued use of the "Distrusted" certificates for code signing still valid? In-Reply-To: References: Message-ID: Bert, Thanks for reaching out. A few of your questions should be addressed by DigiCert but I?ll try to address the one about the root CAs included in the JDK. > On Tue, 25 Jun 2019 at 19:08, Bert Eisen > wrote: > > Hello, > > I?m trying to understand why Digicert are still issuing signing > certificates from the distrusted Symantec root CAs and as a > consequence if the java code signing is still meaningful?? I know > for sure that they are still issing certificates from the distrusted > "thawte Primary Root CA - G3" root, because i'm trying to verify the > signing certificate that has just been issued to the company that I > work for. DigiCert should be able to answer your question about why they are still issuing certificates from the Symantec root CAs and whether they have any timelines to transition to other roots. > The root CA?s were distrusted by Google following the discovery of a > number of invalid certificates incorrectly issued by Symantec and > their partners[1].? And the subsequent investigation by Google > reviled that Symantec?s partners were allowed to issue certificates > without appropriate controls or adequate security processed.? It > would appear that only certificates used for protecting websites are > listed in the Sectigo search engine > [https://crt.sh/], thus it is unclear what other > types of certificates have been issued.? Ultimately this means that > you should not ?Trust? any certificate issued from those roots. > > According to the Thawte Certification practice statement v3.7.20[2], > (as refernced by the G3 root certificate,) it describes the CA as > being ?inactive?.? In addition the policy document also describes > the intermediate code signing certificate ?thawte SHA256 Code > Signing CA - G2? has having have a daily updates to its CRL, but the > URL seems to point to the wrong crl distribution list, which is only > being updated every 3 months. These are both issues that I would recommend reporting to DigiCert. > Which brings us onto the java code signing.? In response to the > Googles distrust statement, the JDK and the SunJSSE provider has > been updated[3] to explicitly reject TLS sessions rooted in the > affected CAs, however it stopped short of removing the CA?s > completely.? This means that jar files signed by the affected roots > are still considered valid and pass all verification checks without > warning. > > Given that the Trust has been eroded from the affected roots, a > third party can no-longer believe with certainty that the signed > code hasn?t been tampered with or has originated from the party > named in the certificate.? As such I believe that digicert should > not be continuing to issue certifcates from those CAs and that java > (and other platforms) should deprecate the use of the affected > CA?s.? At the very least the the JDK shoud warn of code and other > artefacts that have been signed since the distrust date. Code signing certificates have different verification processes, different lifetimes, and are used very differently. While updating TLS certificates in a server is usually a relatively simple process and under the control of the entity that hosts the server, updating signed code involves re-distributing the signed code and requires that all users of the signed code update their copies. This could be several orders of magnitude more disruptive. All incidents that we are aware of involving the affected root certificates have been related to the issuance of TLS certificates. That is why the remediation policies that we have implemented are about restricting trust to TLS certificates. We have not heard of any issues related to the issuance of code signing certificates. If you are aware of any irregularity that could affect code signing certificates rather than only TLS certificates, please see http://openjdk.java.net/groups/vulnerability/report for information on how to report these issues. As an end user, you can choose to remove trust in any root CA by removing it from your cacerts keystore. --Sean > Regards > Bert > > [1] > https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html > [2] > https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.20.pdf > [3] > https://bugs.openjdk.java.net/browse/JDK-8207258?subTaskView=all > From sean.mullan at oracle.com Mon Aug 19 13:45:37 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Aug 2019 09:45:37 -0400 Subject: Allow to define the list of enabled named curves for EC cipher suites as Security Property In-Reply-To: References: Message-ID: On 8/19/19 7:33 AM, Christian Schaefer wrote: > Hi all, > > Today, the list of enabled named curves for EC cipher suites can be > specified as ?System Property? (name of the system property is > jdk.tls.namedGroups) in JDK 8 and later. It seems like it cannot be > specified as ?Security Property?. So unlike jdk.tls.disabledAlgorithms > and jdk.certpath.disabledAlgorithms the property jdk.tls.namedGroups > cannot be specified in the security properties file (i.e. > lib/security/java.security). In JDK 14, we have added the ability to restrict named groups (and signature schemes) in the jdk.tls.disabledAlgorithms security property: https://bugs.openjdk.java.net/browse/JDK-8227445 Does this address your concern? > Is there any chance to enhance this in a future version so that > jdk.tls.namedGroups can also be specified in the security properties > file or is there a reason which I don?t see that explains why > jdk.tls.namedGroups can only be specified as System Property? There's no precise reason that I know of, but the default is typically sufficient and secure for most applications and the system property allows you to adjust it on a per-application basis. This is similar to the system properties for the enabled cipher suites: jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites. Thanks, Sean From christian.schaefer at microfocus.com Mon Aug 19 14:10:24 2019 From: christian.schaefer at microfocus.com (Christian Schaefer) Date: Mon, 19 Aug 2019 14:10:24 +0000 Subject: Allow to define the list of enabled named curves for EC cipher suites as Security Property In-Reply-To: References: Message-ID: Hi Sean, > -----Original Message----- > Subject: Re: Allow to define the list of enabled named curves for EC cipher > suites as Security Property > > On 8/19/19 7:33 AM, Christian Schaefer wrote: > > Hi all, > > > > Today, the list of enabled named curves for EC cipher suites can be > > specified as "System Property" (name of the system property is > > jdk.tls.namedGroups) in JDK 8 and later. It seems like it cannot be > > specified as "Security Property". So unlike jdk.tls.disabledAlgorithms > > and jdk.certpath.disabledAlgorithms the property jdk.tls.namedGroups > > cannot be specified in the security properties file (i.e. > > lib/security/java.security). > > In JDK 14, we have added the ability to restrict named groups (and signature > schemes) in the jdk.tls.disabledAlgorithms security property: > > https://bugs.openjdk.java.net/browse/JDK-8227445 > > Does this address your concern? Absolutely. Thanks a lot! Are there any plans to backport this to JDK 8? > > > Is there any chance to enhance this in a future version so that > > jdk.tls.namedGroups can also be specified in the security properties > > file or is there a reason which I don't see that explains why > > jdk.tls.namedGroups can only be specified as System Property? > > There's no precise reason that I know of, but the default is typically sufficient > and secure for most applications and the system property allows you to > adjust it on a per-application basis. This is similar to the system properties for > the enabled cipher suites: > jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites. > Ok, perfect. Thanks, Christian. > Thanks, > Sean > From weijun.wang at oracle.com Mon Aug 19 14:35:31 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 19 Aug 2019 22:35:31 +0800 Subject: [14] RFR 8228659: Record which Java methods are called by native codes in JGSS and JAAS In-Reply-To: <624CB9FE-FD3C-42D0-A9C0-BB05BE5F44B3@oracle.com> References: <624CB9FE-FD3C-42D0-A9C0-BB05BE5F44B3@oracle.com> Message-ID: <67DCF08E-2AC6-4D08-BEAB-9E7EA79BC54F@oracle.com> Ping again. > On Jul 26, 2019, at 11:24 PM, Weijun Wang wrote: > > Please review the change at > > http://cr.openjdk.java.net/~weijun/8228659/webrev.00/ > > Most of the change is new comments on internal Java methods called by native code. I also take this chance to simply Ticket creation in nativeccache.c and NativeCreds.c. There is no need to call `new Ticket(new DerValue(byteArray))` which is identical to `new Ticket(byteArray)`. > > I added the label noreg-doc but does not feel really comfortable. There is no public document here. noreg-comment or noreg-clarification would be better, if they exists. Please advise. > > Thanks, > Max > From sean.mullan at oracle.com Mon Aug 19 15:02:08 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Aug 2019 11:02:08 -0400 Subject: Allow to define the list of enabled named curves for EC cipher suites as Security Property In-Reply-To: References: Message-ID: <1495a0f1-8751-ef32-c50a-341c119b2107@oracle.com> On 8/19/19 10:10 AM, Christian Schaefer wrote: > Hi Sean, > >> -----Original Message----- >> Subject: Re: Allow to define the list of enabled named curves for EC cipher >> suites as Security Property >> >> On 8/19/19 7:33 AM, Christian Schaefer wrote: >>> Hi all, >>> >>> Today, the list of enabled named curves for EC cipher suites can be >>> specified as "System Property" (name of the system property is >>> jdk.tls.namedGroups) in JDK 8 and later. It seems like it cannot be >>> specified as "Security Property". So unlike jdk.tls.disabledAlgorithms >>> and jdk.certpath.disabledAlgorithms the property jdk.tls.namedGroups >>> cannot be specified in the security properties file (i.e. >>> lib/security/java.security). >> >> In JDK 14, we have added the ability to restrict named groups (and signature >> schemes) in the jdk.tls.disabledAlgorithms security property: >> >> https://bugs.openjdk.java.net/browse/JDK-8227445 >> >> Does this address your concern? > > Absolutely. Thanks a lot! > Are there any plans to backport this to JDK 8? Yes, I think that this is definitely something we should consider backporting to previous releases. I'll look further into that. >>> Is there any chance to enhance this in a future version so that >>> jdk.tls.namedGroups can also be specified in the security properties >>> file or is there a reason which I don't see that explains why >>> jdk.tls.namedGroups can only be specified as System Property? >> >> There's no precise reason that I know of, but the default is typically sufficient >> and secure for most applications and the system property allows you to >> adjust it on a per-application basis. This is similar to the system properties for >> the enabled cipher suites: >> jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites. >> > > Ok, perfect. Thanks, You're welcome. Thanks for the feedback. --Sean From xuelei.fan at oracle.com Mon Aug 19 16:02:22 2019 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 19 Aug 2019 09:02:22 -0700 Subject: Code Review Request, JDK-8228757 : Fail fast if the handshake type is unknown Message-ID: Hi, Could I have the following code cleanup reviewed? http://cr.openjdk.java.net/~xuelei/8228757/webrev.00/ It is trying to fail fast if unknown handshake type get requested. Simple fix and hard to capture the fail point, no new regression test. Thanks, Xuelei From jamil.j.nimeh at oracle.com Mon Aug 19 16:30:59 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 19 Aug 2019 09:30:59 -0700 Subject: Code Review Request, JDK-8228757 : Fail fast if the handshake type is unknown In-Reply-To: References: Message-ID: <67cbece2-4a2c-752b-bd84-ce1be2c2f665@oracle.com> Looks good to me. --Jamil On 8/19/19 9:02 AM, Xuelei Fan wrote: > Hi, > > Could I have the following code cleanup reviewed? > > ?? http://cr.openjdk.java.net/~xuelei/8228757/webrev.00/ > > It is trying to fail fast if unknown handshake type get requested. > Simple fix and hard to capture the fail point, no new regression test. > > Thanks, > Xuelei From peter.firmstone at zeus.net.au Fri Aug 16 21:24:26 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 17 Aug 2019 07:24:26 +1000 Subject: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> References: <5D55DA9F.5050807@zeus.net.au> <8ce427f1-5473-9e2f-af85-ceb7b08ed419@oracle.com> <5D568810.8060503@zeus.net.au> <1d1ea235-77bc-9517-9f00-4053c71be759@oracle.com> Message-ID: <5D571F0A.8020709@zeus.net.au> Thanks Claes, I'll run some tests :) Cheers, Peter. On 16/08/2019 9:14 PM, Claes Redestad wrote: > Hi Peter, > > by explicitly ensuring the file system has been initialized before > installing a SecurityManager using a hook in System.setSecurityManager, > the patch at hand takes step to ensure things stay neutral w.r.t. > Permission initialization order when using any SecurityManager. It's not > perfectly identical, so while unlikely, there's a theoretical > possibility some implementation scenario not covered by our regression > tests might run into issues. Any help testing custom implementation on > coming EA builds would be greatly appreciated! > > One thing we could do on the JDK end to reduce fragility somewhat in > this area is to provoke initialization of > sun.security.util.SecurityConstants before installing the first SM. > > /Claes > > On 2019-08-16 12:40, Peter Firmstone wrote: >> Hello Alan, >> >> Yes, we are aware of those issues. >> >> I mean documenting that system Permission classes should be loaded >> before setting a custom SecurityManager, accessing the file system is >> important, so if you haven't loaded the necessary classes before >> setting a custom SecurityManager, it won't be gracefull... The >> simplest way of ensuring classes are loaded is by creating object >> instances of them. >> >> Perhaps just a note to beware of ensuring necessary classes are >> loaded and let developers figure out what they need. >> >> The recursive calls are easy enough to deal with to avoid any stack >> overflows using ThreadLocal. >> >> inTrustedCodeRecursiveCall.set(Boolean.TRUE); >> try { >> delegateContext = AccessController.doPrivileged( >> new PrivilegedAction(){ >> public AccessControlContext run() { >> return new >> AccessControlContext(finalExecutionContext, dc); >> } >> } >> ); >> }finally { >> inTrustedCodeRecursiveCall.set(Boolean.FALSE); // >> Must always happen, no matter what. >> } >> >> We've only really been caught out once with some jvm bootstrap >> changes, otherwise it's been rock solid. >> >> The other thing we do is once we've got more than three >> ProtectionDomains on the stack is execute the ProtectionDomain >> implies checks in parallel. Really helps when you're making a lot of >> network calls. >> >> Cheers, >> >> Peter. >> >> On 16/08/2019 5:04 PM, Alan Bateman wrote: >>> On 15/08/2019 23:20, Peter Firmstone wrote: >>>> : >>>> >>>> The following code is included in the constructor of our >>>> SecurityManager implementation, I suspect we may need to add some >>>> classes to this list, perhaps this is something that needs >>>> documenting? >>> The checkPermission method of custom security manager can run >>> arbitrary code so recursive initialization, stack overflow, >>> bootstrap method errors, ... are always hazards. I don't know what >>> documentation you have in mind but I don't think there is a definite >>> list of classes that need to be loaded/initialized before the custom >>> security manager is set because it will come down to the code that >>> it executes in its checkPermission method. >>> >>> -Alan. >>> >>> >> From peter.firmstone at zeus.net.au Sun Aug 18 02:22:20 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 18 Aug 2019 12:22:20 +1000 Subject: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <5D55F646.3090907@zeus.net.au> Message-ID: <5D58B65C.4020701@zeus.net.au> Thanks Sean, You've gone to some trouble to answer my question, which demonstrates you have considered it. I donate some time to help maintain Apache River, derived from Sun's Jini. Once Jini depended on RMI, today, not so much, it still has some dependencies on some RMI interfaces, but doesn't utilise JRMP although it provides some backward compatibilty enable it. But my point is, we heavily utilise java Serialization, and have an independant implementation of a subset of Java Serialization (originating from Apache Harmony). We do this for security as we use an annotated serialization constructor. Serial form is unchanged, we have Serializers for commonly used java library objects, for example, we have a "PermissionSerializer", but we don't have a "PermissionCollectionSerializer" or "PermissionsSerializer" (for java.security.Permissions). Incidentally, we have found we do not need the ability to serialize circular object graphs. Throwable is an object that has a circular object graph, but that circular object graph can be linked up after deserialization. Permission implementing Serializable is probably not too much of a threat, as these objects are effectively immutable after lazy initialization. ProtectionDomain calls java.security.Permissions::setReadOnly during it's construction. ProtectionDomain::getPermissions returns internal java.security.Permissions. If this is serialized, then the readOnly internal state can be written to as the internal object references are accessible from within the stream. Admitedly, the attacker would already need to have some privilege, to have access to a ProtectionDomain, so it's a path of privilege escallation. I'm not talking about gadget attacks and deserialization of untrusted data, I'm talking about breaking encapsulation. Even though we are heavily dependant on Java Serialization, we are very careful when we implement it, and avoid implementing it when possible. Hindsight is 20:20, but given we are now seeing some Java SE backward compatibility breakages, perhaps it might be worth considering breaking serialization. I don't mean we need to necessarily break object serial form, but making the Java serialization API explicit with subset of existing api features, that makes long term maintenace and security less of a burden and removing support for Serialization of some objects, where it is seldom used, perhaps using a JEP that requests developers to consider which library objects actually need to be serializable. Something we do in our Java Serialization API is require that mutable deserialized objects are defensively copied during object construction (serial fields are deserialized before an object is constructed, the deserialized fields are accessible via a parameter passed in during construction. We have tools that assist developers to check deserialized Java Collections contain the expected object types for example, so during object construction the developer has to replace the Collection with a new instance and copy the contents to the new Collection after checking the type of each object contained therein. Also we don't actually serialize Java Collections, we have standard serial forms for List, Set and Map, so these serial forms are equal, similar to the List, Set and Map contracts. By doing this, Collections don't actually need to implement Serializable at all, as a Serializer becomes responsible for their serialization. This also means that all Collections must be accessed by interfaces, rather than implementation classes, so the deserialization constructor, must defensively copy them into their preferred Collection instance. It's a bit like dependency injection. I know it would take time, and there would be some pain, but long term it would save a lot of maintenance developer time. Regards, Peter. On 17/08/2019 12:50 AM, Sean Mullan wrote: > On 8/15/19 8:18 PM, Peter Firmstone wrote: >> Hi Roger, >> >> +1 for writeReplace >> >> Personally I'd like to see some security classes break backward >> compatibility and remove support for serialization as it allows >> someone to get references to internal objects, especially since these >> classes are cached by the JVM. Which makes >> PermissionCollection.setReadOnly() very easy to bypass, by adding >> permissions to internal collections once you have a reference to them. >> >> Does anyone have any use cases for serializing these objects? >> >> These objects are easy to re-create by sending or recieving and >> parsing strings, because they are built from text based policy files, >> and when you do that, you are validating input, so I never did fully >> understand why they were made serializable. > > This is briefly explained on page 61 in the "Inside Java 2 Platform > Security" book [1]: > > "The Permission class implements two interfaces: java.security.Guard > and java.io.Serializable. For the latter, the intention is that > Permission objects may be transported to remote machines, such as via > Remote Method Invocation (RMI), and thus a Serializable representation > is useful." > > The Permission class was introduced in Java SE 1.2 so there were > different motivations back then :) > > --Sean > > [1] https://www.oracle.com/technetwork/java/javaee/index-141918.html From sean.mullan at oracle.com Mon Aug 19 19:55:47 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Aug 2019 15:55:47 -0400 Subject: [RFR] JDK-8225436 : Stapled OCSPResponses should be added to PKIXRevocationChecker irrespective of revocationEnabled flag In-Reply-To: <3ab31cad-2d03-2462-922b-9015e1e0c233@oracle.com> References: <3ab31cad-2d03-2462-922b-9015e1e0c233@oracle.com> Message-ID: <56dca921-4df8-0439-8d78-c1a22a484b66@oracle.com> Looks good. There is one case where an unnecessary ArrayList is created (on line 406-7) if revocation is disabled AND we don't find a RevocationChecker -- it would be useful if you could avoid that by iterating over the checkers before creating the array list, since it is probably the more common case. In fact, there is probably some unnecessary copying even before that since the PKIXParameters has already been cloned in engineValidate. We avoid some of that cloning/copying in the certpath provider (see the ValidatorParams class in sun.security.provider.certpath.PKIX) - you could look into that to see if you could use that here - I'll also think about it again when I have a little more time ... --Sean On 8/16/19 5:25 PM, Jamil Nimeh wrote: > Hello all, > > This fixes a bug where stapled OCSP responses were being ignored by the > internal Validator in all cases when revocation checking is disabled. If > the TrustManagerFactory is initialized with CertPathParameters that > include a PKIXRevocationChecker, then that should override the > setRevocationEnabled flag and any stapled responses should be taken into > account during path validation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8225436 > > Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8225436/webrev.01/ > > Thanks, > > --Jamil > From sean.mullan at oracle.com Mon Aug 19 21:55:28 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 19 Aug 2019 17:55:28 -0400 Subject: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D58B65C.4020701@zeus.net.au> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <5D55F646.3090907@zeus.net.au> <5D58B65C.4020701@zeus.net.au> Message-ID: <80b7767a-3f65-2db9-6d54-b9c2abcf2989@oracle.com> Brian Goetz (copied) has done a lot of thinking in the serialization area, so I have copied him. Not sure if you have seen it but he recently posted a document about some of his ideas and possible future directions for serialization: http://cr.openjdk.java.net/~briangoetz/amber/serialization.html --Sean On 8/17/19 10:22 PM, Peter Firmstone wrote: > Thanks Sean, > > You've gone to some trouble to answer my question, which demonstrates > you have considered it. > > I donate some time to help maintain Apache River, derived from Sun's > Jini.? Once Jini depended on RMI, today, not so much, it still has some > dependencies on some RMI interfaces, but doesn't utilise JRMP although > it provides some backward compatibilty enable it. > > But my point is, we heavily utilise java Serialization, and have an > independant implementation of a subset of Java Serialization > (originating from Apache Harmony).? We do this for security as we use an > annotated serialization constructor.?? Serial form is unchanged, we have > Serializers for commonly used java library objects, for example, we have > a "PermissionSerializer", but we don't have a > "PermissionCollectionSerializer" or "PermissionsSerializer" (for > java.security.Permissions).?? Incidentally, we have found we do not need > the ability to serialize circular object graphs.?? Throwable is an > object that has a circular object graph, but that circular object graph > can be linked up after deserialization. > > Permission implementing Serializable is probably not too much of a > threat, as these objects are effectively immutable after lazy > initialization. > > ProtectionDomain calls java.security.Permissions::setReadOnly during > it's construction. > > ProtectionDomain::getPermissions returns internal > java.security.Permissions.?? If this is serialized, then the readOnly > internal state can be written to as the internal object references are > accessible from within the stream. > > Admitedly, the attacker would already need to have some privilege, to > have access to a ProtectionDomain, so it's a path of privilege > escallation.? I'm not talking about gadget attacks and deserialization > of untrusted data, I'm talking about breaking encapsulation. > > Even though we are heavily dependant on Java Serialization, we are very > careful when we implement it, and avoid implementing it when possible. > Hindsight is 20:20, but given we are now seeing some Java SE backward > compatibility breakages, perhaps it might be worth considering breaking > serialization.? I don't mean we need to necessarily break object serial > form, but making the Java serialization API explicit with subset of > existing api features, that makes long term maintenace and security less > of a burden and removing support for Serialization of some objects, > where it is seldom used, perhaps using a JEP that requests developers to > consider which library objects actually need to be serializable. > > Something we do in our Java Serialization API is require that mutable > deserialized objects are defensively copied during object construction > (serial fields are deserialized before an object is constructed, the > deserialized fields are accessible via a parameter passed in during > construction.?? We have tools that assist developers to check > deserialized Java Collections contain the expected object types for > example, so during object construction the developer has to replace the > Collection with a new instance and copy the contents to the new > Collection after checking the type of each object contained therein. > Also we don't actually serialize Java Collections, we have standard > serial forms for List, Set and Map, so these serial forms are equal, > similar to the List, Set and Map contracts.? By doing this, Collections > don't actually need to implement Serializable at all, as a Serializer > becomes responsible for their serialization.?? This also means that all > Collections must be accessed by interfaces, rather than implementation > classes, so the deserialization constructor, must defensively copy them > into their preferred Collection instance.?? It's a bit like dependency > injection. > > I know it would take time, and there would be some pain, but long term > it would save a lot of maintenance developer time. > > Regards, > > Peter. > > On 17/08/2019 12:50 AM, Sean Mullan wrote: >> On 8/15/19 8:18 PM, Peter Firmstone wrote: >>> Hi Roger, >>> >>> +1 for writeReplace >>> >>> Personally I'd like to see some security classes break backward >>> compatibility and remove support for serialization as it allows >>> someone to get references to internal objects, especially since these >>> classes are cached by the JVM.? Which makes >>> PermissionCollection.setReadOnly() very easy to bypass, by adding >>> permissions to internal collections once you have a reference to them. >>> >>> Does anyone have any use cases for serializing these objects? >>> >>> These objects are easy to re-create by sending or recieving and >>> parsing strings, because they are built from text based policy files, >>> and when you do that, you are validating input, so I never did fully >>> understand why they were made serializable. >> >> This is briefly explained on page 61 in the "Inside Java 2 Platform >> Security" book [1]: >> >> "The Permission class implements two interfaces: java.security.Guard >> and java.io.Serializable. For the latter, the intention is that >> Permission objects may be transported to remote machines, such as via >> Remote Method Invocation (RMI), and thus a Serializable representation >> is useful." >> >> The Permission class was introduced in Java SE 1.2 so there were >> different motivations back then :) >> >> --Sean >> >> [1] https://www.oracle.com/technetwork/java/javaee/index-141918.html > From peter.firmstone at zeus.net.au Tue Aug 20 04:51:23 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 20 Aug 2019 14:51:23 +1000 Subject: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <80b7767a-3f65-2db9-6d54-b9c2abcf2989@oracle.com> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <5D55F646.3090907@zeus.net.au> <5D58B65C.4020701@zeus.net.au> <80b7767a-3f65-2db9-6d54-b9c2abcf2989@oracle.com> Message-ID: <5D5B7C4B.7080507@zeus.net.au> Thanks Sean, No I hadn't seen it, I've just read it, will probably need to read it again to appreciate it fully... It certainly identifies all the issues I'm aware of, as well as being respectful of the original implementors (many of whom participated in Apache River when Jini was donated to Apache), I came to the same conclusion with circular object graphs; the benefits don't outweigh the cost. We also use annotations instead of interfaces,to annotate the class and constructor, so that overriding classes don't automagically inherit the functionality. At this time, we haven't reimplemented deconstruction, we are using ObjectOutputStream with serializers, which are basically serialization proxy's for existing classes, we have fully reimplemented deserialization using constructors. Agree with serial from being independant of the wire protocol, so any serialization scheme can be used, this is an excellent idea of course. The constructors / deconstructors have identified that serial form is really just a parameter list. Developers will want to make defensive copies of mutable state, just like public api methods. We did consider constructors with multiple parameters, but decided against it for the following reasons: 1. We didn't care about parameter order (tuples), or the order in which they were serialized / deserialized, we only cared about parameter names and types. 2. For encapsulation we didn't want subclasses having to manage the serial form of superclasses, we wanted them to remain as independant as possible, so they don't inadvertantly break. * For example, a library superclass adds a serial form parameter, or changes a type, in its serial form. The child class would have to be aware of the changes in order to pass the correct parameters to the correct superclass constructor. * Different serial version constructors would result in the loss of later version superclass state when child classes call an earlier version. 3. We settled on a caller sensitive parameter that is passed to the deserialization constructor. * Encapsulation: Each class in an inheritance heirarch only has access to it's own serial form. * The serial form of each class is independant and may evolve independantly. * Each class in the inheritance heirarchy is responsible for checking it's own invariants, including the ability to create superclass instances, even if a superclass is abstract for checking inter class invariants. 4. It was less work for the framework to populate a standard parameter object, with serial form, the framework didn't need to worry about inspecting the constructor signature and determining the parameter order. 5. One constructor could be used for different versions. 6. We currently use |serialPersistentFields to declare serial form, but there is probably a better way of doing this, perhaps a way that also documents different serial form versions.| Regards, Peter. On 20/08/2019 7:55 AM, Sean Mullan wrote: > Brian Goetz (copied) has done a lot of thinking in the serialization > area, so I have copied him. Not sure if you have seen it but he > recently posted a document about some of his ideas and possible future > directions for serialization: > http://cr.openjdk.java.net/~briangoetz/amber/serialization.html > > --Sean > > On 8/17/19 10:22 PM, Peter Firmstone wrote: >> Thanks Sean, >> >> You've gone to some trouble to answer my question, which demonstrates >> you have considered it. >> >> I donate some time to help maintain Apache River, derived from Sun's >> Jini. Once Jini depended on RMI, today, not so much, it still has >> some dependencies on some RMI interfaces, but doesn't utilise JRMP >> although it provides some backward compatibilty enable it. >> >> But my point is, we heavily utilise java Serialization, and have an >> independant implementation of a subset of Java Serialization >> (originating from Apache Harmony). We do this for security as we use >> an annotated serialization constructor. Serial form is unchanged, >> we have Serializers for commonly used java library objects, for >> example, we have a "PermissionSerializer", but we don't have a >> "PermissionCollectionSerializer" or "PermissionsSerializer" (for >> java.security.Permissions). Incidentally, we have found we do not >> need the ability to serialize circular object graphs. Throwable is >> an object that has a circular object graph, but that circular object >> graph can be linked up after deserialization. >> >> Permission implementing Serializable is probably not too much of a >> threat, as these objects are effectively immutable after lazy >> initialization. >> >> ProtectionDomain calls java.security.Permissions::setReadOnly during >> it's construction. >> >> ProtectionDomain::getPermissions returns internal >> java.security.Permissions. If this is serialized, then the readOnly >> internal state can be written to as the internal object references >> are accessible from within the stream. >> >> Admitedly, the attacker would already need to have some privilege, to >> have access to a ProtectionDomain, so it's a path of privilege >> escallation. I'm not talking about gadget attacks and >> deserialization of untrusted data, I'm talking about breaking >> encapsulation. >> >> Even though we are heavily dependant on Java Serialization, we are >> very careful when we implement it, and avoid implementing it when >> possible. Hindsight is 20:20, but given we are now seeing some Java >> SE backward compatibility breakages, perhaps it might be worth >> considering breaking serialization. I don't mean we need to >> necessarily break object serial form, but making the Java >> serialization API explicit with subset of existing api features, that >> makes long term maintenace and security less of a burden and removing >> support for Serialization of some objects, where it is seldom used, >> perhaps using a JEP that requests developers to consider which >> library objects actually need to be serializable. >> >> Something we do in our Java Serialization API is require that mutable >> deserialized objects are defensively copied during object >> construction (serial fields are deserialized before an object is >> constructed, the deserialized fields are accessible via a parameter >> passed in during construction. We have tools that assist developers >> to check deserialized Java Collections contain the expected object >> types for example, so during object construction the developer has to >> replace the Collection with a new instance and copy the contents to >> the new Collection after checking the type of each object contained >> therein. Also we don't actually serialize Java Collections, we have >> standard serial forms for List, Set and Map, so these serial forms >> are equal, similar to the List, Set and Map contracts. By doing >> this, Collections don't actually need to implement Serializable at >> all, as a Serializer becomes responsible for their serialization. >> This also means that all Collections must be accessed by interfaces, >> rather than implementation classes, so the deserialization >> constructor, must defensively copy them into their preferred >> Collection instance. It's a bit like dependency injection. >> >> I know it would take time, and there would be some pain, but long >> term it would save a lot of maintenance developer time. >> >> Regards, >> >> Peter. >> >> On 17/08/2019 12:50 AM, Sean Mullan wrote: >>> On 8/15/19 8:18 PM, Peter Firmstone wrote: >>>> Hi Roger, >>>> >>>> +1 for writeReplace >>>> >>>> Personally I'd like to see some security classes break backward >>>> compatibility and remove support for serialization as it allows >>>> someone to get references to internal objects, especially since >>>> these classes are cached by the JVM. Which makes >>>> PermissionCollection.setReadOnly() very easy to bypass, by adding >>>> permissions to internal collections once you have a reference to them. >>>> >>>> Does anyone have any use cases for serializing these objects? >>>> >>>> These objects are easy to re-create by sending or recieving and >>>> parsing strings, because they are built from text based policy >>>> files, and when you do that, you are validating input, so I never >>>> did fully understand why they were made serializable. >>> >>> This is briefly explained on page 61 in the "Inside Java 2 Platform >>> Security" book [1]: >>> >>> "The Permission class implements two interfaces: java.security.Guard >>> and java.io.Serializable. For the latter, the intention is that >>> Permission objects may be transported to remote machines, such as >>> via Remote Method Invocation (RMI), and thus a Serializable >>> representation is useful." >>> >>> The Permission class was introduced in Java SE 1.2 so there were >>> different motivations back then :) >>> >>> --Sean >>> >>> [1] https://www.oracle.com/technetwork/java/javaee/index-141918.html >> From jamil.j.nimeh at oracle.com Tue Aug 20 16:14:46 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 20 Aug 2019 09:14:46 -0700 Subject: [RFR] JDK-8225436 : Stapled OCSPResponses should be added to PKIXRevocationChecker irrespective of revocationEnabled flag In-Reply-To: <56dca921-4df8-0439-8d78-c1a22a484b66@oracle.com> References: <3ab31cad-2d03-2462-922b-9015e1e0c233@oracle.com> <56dca921-4df8-0439-8d78-c1a22a484b66@oracle.com> Message-ID: <0e1ec40e-ef33-2c6d-0204-03875e6127f7@oracle.com> Thanks for the review, Sean.? I've made a couple changes based on your recommendations.? I don't create a mutable ArrayList any longer in the case where we're making a new PKIXRevocationChecker.? In that one case I just directly add it to the PKIXBuilderParameters and if one already exists from the immutable CPC list I can just add the responses to it and push the whole list back. http://cr.openjdk.java.net/~jnimeh/reviews/8225436/webrev.02/ --Jamil On 8/19/19 12:55 PM, Sean Mullan wrote: > Looks good. There is one case where an unnecessary ArrayList is > created (on line 406-7) if revocation is disabled AND we don't find a > RevocationChecker -- it would be useful if you could avoid that by > iterating over the checkers before creating the array list, since it > is probably the more common case. In fact, there is probably some > unnecessary copying even before that since the PKIXParameters has > already been cloned in engineValidate. We avoid some of that > cloning/copying in the certpath provider (see the ValidatorParams > class in sun.security.provider.certpath.PKIX) - you could look into > that to see if you could use that here - I'll also think about it > again when I have a little more time ... > > --Sean > > On 8/16/19 5:25 PM, Jamil Nimeh wrote: >> Hello all, >> >> This fixes a bug where stapled OCSP responses were being ignored by >> the internal Validator in all cases when revocation checking is >> disabled. If the TrustManagerFactory is initialized with >> CertPathParameters that include a PKIXRevocationChecker, then that >> should override the setRevocationEnabled flag and any stapled >> responses should be taken into account during path validation. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225436 >> >> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8225436/webrev.01/ >> >> Thanks, >> >> --Jamil >> From ivan.gerasimov at oracle.com Tue Aug 20 17:38:49 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 20 Aug 2019 10:38:49 -0700 Subject: RFR 8211360 : Change #if DEF to #if defined(DEF) Message-ID: <0d38c07a-e697-49c6-dfc0-938a8ffa7820@oracle.com> Hello! It's a followup for JDK-8211146. With that fix several C-preprocessor statements of form #elif __linux__ were changed to more accurate #elif defined(__linux__). grep found a few more occurrences of the same pattern, which also would better be cleaned up. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8211360 WEBREV: http://cr.openjdk.java.net/~igerasim/8211360/00/webrev/ Mach5 control build/testing went fine on all platforms. Would you please help review? -- With kind regards, Ivan Gerasimov From brian.burkhalter at oracle.com Tue Aug 20 17:56:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 20 Aug 2019 10:56:30 -0700 Subject: RFR 8211360 : Change #if DEF to #if defined(DEF) In-Reply-To: <0d38c07a-e697-49c6-dfc0-938a8ffa7820@oracle.com> References: <0d38c07a-e697-49c6-dfc0-938a8ffa7820@oracle.com> Message-ID: <899FC93B-95C8-4E53-B1EA-E4C19EE3F58E@oracle.com> Hello Ivan, Looks fine. Brian > On Aug 20, 2019, at 10:38 AM, Ivan Gerasimov wrote: > > It's a followup for JDK-8211146. > > With that fix several C-preprocessor statements of form #elif __linux__ were changed to more accurate #elif defined(__linux__). > > grep found a few more occurrences of the same pattern, which also would better be cleaned up. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8211360 > WEBREV: http://cr.openjdk.java.net/~igerasim/8211360/00/webrev/ > > Mach5 control build/testing went fine on all platforms. > Would you please help review? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Wed Aug 21 14:32:09 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 21 Aug 2019 15:32:09 +0100 Subject: [14] RFR JDK-8229243 "SunPKCS11-Solaris provider tests failing on Solaris 11.4" In-Reply-To: <608300e7-cc6e-6f73-ba93-eae8c7904340@oracle.com> References: <608300e7-cc6e-6f73-ba93-eae8c7904340@oracle.com> Message-ID: <86cc237c-39cb-ec6b-dc70-2fc34ce690be@oracle.com> Thanks for taking this on Valerie. It's a shame to see such confusion arise from the new PKCS11 spec. The changes look fine to me. It'll certainly benefit from widespread interoperability testing. Regards, Sean. On 16/08/19 00:49, Valerie Peng wrote: > > Anyone has time to help review this fix? PKCS#11 v2.40 has > inconsistent definition for CK_GCM_PARAMS struct. The mechanism spec > (sec 2..12.3) has: > > typedef struct CK_GCM_PARAMS { > CK_BYTE_PTR pIv; > CK_ULONG ulIvLen; > CK_BYTE_PTR pAAD; > CK_ULONG ulAADLen; > CK_ULONG ulTagBits; > } CK_GCM_PARAMS; > > However, the header file pkcs11t.h has an extra "ulIvBits" field: > > typedef struct CK_GCM_PARAMS { > CK_BYTE_PTR pIv; > CK_ULONG ulIvLen; > * CK_ULONG ulIvBits;* > CK_BYTE_PTR pAAD; > CK_ULONG ulAADLen; > CK_ULONG ulTagBits; > } CK_GCM_PARAMS; > > Some vendors such OpenHSM2 and Solaris go with the header file while > some vendor such as NSS go with the mech spec. Current SunPKCS11 > provider impl works with NSS but not with other vendors whose > CK_GCM_PARAMS struct contains ulIvBits field. Based on testing > results, OpenHSM2 and Solaris error out at init time when the > parameter length does not have their expected value. Thus, one way to > workaround this inconsistency is to re-try with a different structure > for AES GCM when the init failed. In addition, given the parameters > contains Iv and AAD which some vendor may use during subsequent > enc/dec operations, I changed to use the same model as RSASSA-PSS to > defer the freeing after the enc/dec operation is finished. Verified > the changes on Solaris 11.4 against existing GCM regression tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229243 > > Webrev: http://cr.openjdk.java.net/~valeriep/8229243/webrev.00/ > > Thanks, > Valerie -------------- next part -------------- An HTML attachment was scrubbed... URL: From letuyang at amazon.com Thu Aug 22 00:01:55 2019 From: letuyang at amazon.com (Yang, Letu) Date: Thu, 22 Aug 2019 00:01:55 +0000 Subject: RFR 8229958: Provider.getService() scalability issue for legacy algorithms and message digests Message-ID: <4BDF747E-9088-42FC-9D20-E2F998DDFAD9@amazon.com> Hi, Please review the fix of?https://bugs.openjdk.java.net/browse/JDK-8229958?where I made the change to allow majority of calls don't have to acquire the locks when checking the availability of the Provider object. Similar effort had been made in fixing?https://bugs.openjdk.java.net/browse/JDK-7092821?, but it only helped the calls for new encryption algorithms. Xin had helped me to upload the CR:? https://cr.openjdk.java.net/~xliu/8229958/01/webrev/?. I had run tier-1 tests, and also a JMH test to confirm its performance improvement. We have also had it running in a load test environment of an application for a couple of days, and the improvement was confirmed as well. I have submitted it in core-libs yesterday, but Alan Bateman thought it would be more appropriate to talk about it here. Best regards, Letu From sean.mullan at oracle.com Thu Aug 22 14:40:47 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 22 Aug 2019 10:40:47 -0400 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: <9367A39F-2863-48D5-BE4A-7995187A8973@oracle.com> References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> <9367A39F-2863-48D5-BE4A-7995187A8973@oracle.com> Message-ID: On 8/14/19 10:07 AM, Weijun Wang wrote: > The difference will be big. I've simplified the logic into > > 1. read bytes between first ": " and \r\n as alias > 2. read bytes between first \r\n after first "-" and next "-" as a cert > 3. goto 1 > > And I only store the cert bytes and do not create a Certificate until getCertificate() is read. I even haven't de-BASE64 them. > > Time spent is still ~2.5x of JKS (when reading from a ByteArrayInputStream). > > I guess the major reason is that there is no length field for the cert, so we must read-and-check all the time. Could you store the length as an attribute, perhaps? --Sean > > --Max > >> On Aug 14, 2019, at 9:31 PM, Sean Mullan wrote: >> >> On 8/13/19 10:19 PM, Weijun Wang wrote: >>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>> see wether your parser doesn't choke on it. >>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. >> >> This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 >> >> I would not want to see a regression in performance. >> >> --Sean > From weijun.wang at oracle.com Thu Aug 22 15:47:22 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 22 Aug 2019 23:47:22 +0800 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> <9367A39F-2863-48D5-BE4A-7995187A8973@oracle.com> Message-ID: > On Aug 22, 2019, at 10:40 PM, Sean Mullan wrote: > > On 8/14/19 10:07 AM, Weijun Wang wrote: >> The difference will be big. I've simplified the logic into >> 1. read bytes between first ": " and \r\n as alias >> 2. read bytes between first \r\n after first "-" and next "-" as a cert >> 3. goto 1 >> And I only store the cert bytes and do not create a Certificate until getCertificate() is read. I even haven't de-BASE64 them. >> Time spent is still ~2.5x of JKS (when reading from a ByteArrayInputStream). >> I guess the major reason is that there is no length field for the cert, so we must read-and-check all the time. > > Could you store the length as an attribute, perhaps? I'm reluctant to do that. This means people cannot edit the file with a text editor and have to use keytool to manage it. Of course, this file is still PEM and can be used by other tools, just that they should not try to modify it. I'll see if there are other ways to improve the performance. One way I'm thinking about is to read the first few bytes of a cert to find out the length (It's always also 30 82 AB CD...). Thanks, Max > > --Sean > >> --Max >>> On Aug 14, 2019, at 9:31 PM, Sean Mullan wrote: >>> >>> On 8/13/19 10:19 PM, Weijun Wang wrote: >>>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>>> see wether your parser doesn't choke on it. >>>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. >>> >>> This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 >>> >>> I would not want to see a regression in performance. >>> >>> --Sean From sean.mullan at oracle.com Thu Aug 22 20:14:57 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 22 Aug 2019 16:14:57 -0400 Subject: [RFR] JDK-8225436 : Stapled OCSPResponses should be added to PKIXRevocationChecker irrespective of revocationEnabled flag In-Reply-To: <0e1ec40e-ef33-2c6d-0204-03875e6127f7@oracle.com> References: <3ab31cad-2d03-2462-922b-9015e1e0c233@oracle.com> <56dca921-4df8-0439-8d78-c1a22a484b66@oracle.com> <0e1ec40e-ef33-2c6d-0204-03875e6127f7@oracle.com> Message-ID: On 8/20/19 12:14 PM, Jamil Nimeh wrote: > Thanks for the review, Sean.? I've made a couple changes based on your > recommendations.? I don't create a mutable ArrayList any longer in the > case where we're making a new PKIXRevocationChecker.? In that one case I > just directly add it to the PKIXBuilderParameters and if one already > exists from the immutable CPC list I can just add the responses to it > and push the whole list back. > > http://cr.openjdk.java.net/~jnimeh/reviews/8225436/webrev.02/ 406 // Make a modifiable copy of the CertPathChecker list This comment is not true anymore, so I would delete it. Looks good otherwise. --Sean > > --Jamil > > On 8/19/19 12:55 PM, Sean Mullan wrote: >> Looks good. There is one case where an unnecessary ArrayList is >> created (on line 406-7) if revocation is disabled AND we don't find a >> RevocationChecker -- it would be useful if you could avoid that by >> iterating over the checkers before creating the array list, since it >> is probably the more common case. In fact, there is probably some >> unnecessary copying even before that since the PKIXParameters has >> already been cloned in engineValidate. We avoid some of that >> cloning/copying in the certpath provider (see the ValidatorParams >> class in sun.security.provider.certpath.PKIX) - you could look into >> that to see if you could use that here - I'll also think about it >> again when I have a little more time ... >> >> --Sean >> >> On 8/16/19 5:25 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This fixes a bug where stapled OCSP responses were being ignored by >>> the internal Validator in all cases when revocation checking is >>> disabled. If the TrustManagerFactory is initialized with >>> CertPathParameters that include a PKIXRevocationChecker, then that >>> should override the setRevocationEnabled flag and any stapled >>> responses should be taken into account during path validation. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225436 >>> >>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8225436/webrev.01/ >>> >>> Thanks, >>> >>> --Jamil >>> From jamil.j.nimeh at oracle.com Thu Aug 22 20:22:19 2019 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 22 Aug 2019 13:22:19 -0700 Subject: [RFR] JDK-8225436 : Stapled OCSPResponses should be added to PKIXRevocationChecker irrespective of revocationEnabled flag In-Reply-To: References: <3ab31cad-2d03-2462-922b-9015e1e0c233@oracle.com> <56dca921-4df8-0439-8d78-c1a22a484b66@oracle.com> <0e1ec40e-ef33-2c6d-0204-03875e6127f7@oracle.com> Message-ID: Oops, missed that one.? Good catch. --Jamil On 8/22/19 1:14 PM, Sean Mullan wrote: > On 8/20/19 12:14 PM, Jamil Nimeh wrote: >> Thanks for the review, Sean.? I've made a couple changes based on >> your recommendations.? I don't create a mutable ArrayList any longer >> in the case where we're making a new PKIXRevocationChecker.? In that >> one case I just directly add it to the PKIXBuilderParameters and if >> one already exists from the immutable CPC list I can just add the >> responses to it and push the whole list back. >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8225436/webrev.02/ > > 406???????????? // Make a modifiable copy of the CertPathChecker list > > This comment is not true anymore, so I would delete it. > > Looks good otherwise. > > --Sean > >> >> --Jamil >> >> On 8/19/19 12:55 PM, Sean Mullan wrote: >>> Looks good. There is one case where an unnecessary ArrayList is >>> created (on line 406-7) if revocation is disabled AND we don't find >>> a RevocationChecker -- it would be useful if you could avoid that by >>> iterating over the checkers before creating the array list, since it >>> is probably the more common case. In fact, there is probably some >>> unnecessary copying even before that since the PKIXParameters has >>> already been cloned in engineValidate. We avoid some of that >>> cloning/copying in the certpath provider (see the ValidatorParams >>> class in sun.security.provider.certpath.PKIX) - you could look into >>> that to see if you could use that here - I'll also think about it >>> again when I have a little more time ... >>> >>> --Sean >>> >>> On 8/16/19 5:25 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This fixes a bug where stapled OCSP responses were being ignored by >>>> the internal Validator in all cases when revocation checking is >>>> disabled. If the TrustManagerFactory is initialized with >>>> CertPathParameters that include a PKIXRevocationChecker, then that >>>> should override the setRevocationEnabled flag and any stapled >>>> responses should be taken into account during path validation. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225436 >>>> >>>> Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8225436/webrev.01/ >>>> >>>> Thanks, >>>> >>>> --Jamil >>>> From peter.firmstone at zeus.net.au Thu Aug 22 21:36:00 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 23 Aug 2019 07:36:00 +1000 Subject: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <80b7767a-3f65-2db9-6d54-b9c2abcf2989@oracle.com> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <5D55F646.3090907@zeus.net.au> <5D58B65C.4020701@zeus.net.au> <80b7767a-3f65-2db9-6d54-b9c2abcf2989@oracle.com> Message-ID: <5D5F0AC0.5090008@zeus.net.au> Hi Sean, Regarding the section entitled "Why not write a new serialization library?", unlike the serialization libraries listed, our purpose was to be able to securely deserialize untrusted data, while maintaining backward serial form compatibility with Java Serialization, provided it didn't compromise security. We don't use blacklists or whitelists, we use permissions to grant DeserializationPermission, it doesn't have the granularity of white lists, but then, classes that implement @AtomicSerial are supposed to be hardened implementations in any case. If it can be of use, feel free to experiment with it, hopefully it might help with some of your design decisions: https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io Much of the code on this site provides implementation examples as well. Regards, Peter. On 20/08/2019 7:55 AM, Sean Mullan wrote: > Brian Goetz (copied) has done a lot of thinking in the serialization > area, so I have copied him. Not sure if you have seen it but he > recently posted a document about some of his ideas and possible future > directions for serialization: > http://cr.openjdk.java.net/~briangoetz/amber/serialization.html > > --Sean > > On 8/17/19 10:22 PM, Peter Firmstone wrote: >> Thanks Sean, >> >> You've gone to some trouble to answer my question, which demonstrates >> you have considered it. >> >> I donate some time to help maintain Apache River, derived from Sun's >> Jini. Once Jini depended on RMI, today, not so much, it still has >> some dependencies on some RMI interfaces, but doesn't utilise JRMP >> although it provides some backward compatibilty enable it. >> >> But my point is, we heavily utilise java Serialization, and have an >> independant implementation of a subset of Java Serialization >> (originating from Apache Harmony). We do this for security as we use >> an annotated serialization constructor. Serial form is unchanged, >> we have Serializers for commonly used java library objects, for >> example, we have a "PermissionSerializer", but we don't have a >> "PermissionCollectionSerializer" or "PermissionsSerializer" (for >> java.security.Permissions). Incidentally, we have found we do not >> need the ability to serialize circular object graphs. Throwable is >> an object that has a circular object graph, but that circular object >> graph can be linked up after deserialization. >> >> Permission implementing Serializable is probably not too much of a >> threat, as these objects are effectively immutable after lazy >> initialization. >> >> ProtectionDomain calls java.security.Permissions::setReadOnly during >> it's construction. >> >> ProtectionDomain::getPermissions returns internal >> java.security.Permissions. If this is serialized, then the readOnly >> internal state can be written to as the internal object references >> are accessible from within the stream. >> >> Admitedly, the attacker would already need to have some privilege, to >> have access to a ProtectionDomain, so it's a path of privilege >> escallation. I'm not talking about gadget attacks and >> deserialization of untrusted data, I'm talking about breaking >> encapsulation. >> >> Even though we are heavily dependant on Java Serialization, we are >> very careful when we implement it, and avoid implementing it when >> possible. Hindsight is 20:20, but given we are now seeing some Java >> SE backward compatibility breakages, perhaps it might be worth >> considering breaking serialization. I don't mean we need to >> necessarily break object serial form, but making the Java >> serialization API explicit with subset of existing api features, that >> makes long term maintenace and security less of a burden and removing >> support for Serialization of some objects, where it is seldom used, >> perhaps using a JEP that requests developers to consider which >> library objects actually need to be serializable. >> >> Something we do in our Java Serialization API is require that mutable >> deserialized objects are defensively copied during object >> construction (serial fields are deserialized before an object is >> constructed, the deserialized fields are accessible via a parameter >> passed in during construction. We have tools that assist developers >> to check deserialized Java Collections contain the expected object >> types for example, so during object construction the developer has to >> replace the Collection with a new instance and copy the contents to >> the new Collection after checking the type of each object contained >> therein. Also we don't actually serialize Java Collections, we have >> standard serial forms for List, Set and Map, so these serial forms >> are equal, similar to the List, Set and Map contracts. By doing >> this, Collections don't actually need to implement Serializable at >> all, as a Serializer becomes responsible for their serialization. >> This also means that all Collections must be accessed by interfaces, >> rather than implementation classes, so the deserialization >> constructor, must defensively copy them into their preferred >> Collection instance. It's a bit like dependency injection. >> >> I know it would take time, and there would be some pain, but long >> term it would save a lot of maintenance developer time. >> >> Regards, >> >> Peter. >> >> On 17/08/2019 12:50 AM, Sean Mullan wrote: >>> On 8/15/19 8:18 PM, Peter Firmstone wrote: >>>> Hi Roger, >>>> >>>> +1 for writeReplace >>>> >>>> Personally I'd like to see some security classes break backward >>>> compatibility and remove support for serialization as it allows >>>> someone to get references to internal objects, especially since >>>> these classes are cached by the JVM. Which makes >>>> PermissionCollection.setReadOnly() very easy to bypass, by adding >>>> permissions to internal collections once you have a reference to them. >>>> >>>> Does anyone have any use cases for serializing these objects? >>>> >>>> These objects are easy to re-create by sending or recieving and >>>> parsing strings, because they are built from text based policy >>>> files, and when you do that, you are validating input, so I never >>>> did fully understand why they were made serializable. >>> >>> This is briefly explained on page 61 in the "Inside Java 2 Platform >>> Security" book [1]: >>> >>> "The Permission class implements two interfaces: java.security.Guard >>> and java.io.Serializable. For the latter, the intention is that >>> Permission objects may be transported to remote machines, such as >>> via Remote Method Invocation (RMI), and thus a Serializable >>> representation is useful." >>> >>> The Permission class was introduced in Java SE 1.2 so there were >>> different motivations back then :) >>> >>> --Sean >>> >>> [1] https://www.oracle.com/technetwork/java/javaee/index-141918.html >> From peter.firmstone at zeus.net.au Fri Aug 23 02:59:21 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 23 Aug 2019 12:59:21 +1000 Subject: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D5F0AC0.5090008@zeus.net.au> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <5D55F646.3090907@zeus.net.au> <5D58B65C.4020701@zeus.net.au> <80b7767a-3f65-2db9-6d54-b9c2abcf2989@oracle.com> <5D5F0AC0.5090008@zeus.net.au> Message-ID: <5D5F5689.3050901@zeus.net.au> "...since at the time the industry believed that distributed objects were going to save us from complexity.) Many of the sins of serialization were committed in the desire to get that last .1%, but the cost and benefit of that last .1% are woefully out of balance." The following are probably a non goals, but something to consider or keep in mind, relating to distributed objects: The are three types of distributed objects: 1. Immutable value / data Object types. 2. Shared Mutable Objects. 3. Unshared Mutable Objects. 4. Remote Objects / Services (best for managing shared mutable state). The second type of distributed object causes much pain and should be discouraged. The first three types of distributed objects can have class resolution issues, but these are solveable. A lot of folks also have problems with deserialization Objects when class visibility is different at both ends, I'm guessing this would be the same for value types. For example OSGi folk recommend using primitive parameter types for remote OSGi services. RMI annotates streams with codebase annotations. Jini Extensible Remote Invocation used to do that too. The problem with RMI codebase and Jini codebase annotations is if you resolve your classes locally, you lose the codebase annotations, when re-serializing data and because class visibility can be different at different endpoints, end up with all sorts of class resolution issues. "Class Loading Issues in Java? RMIand Jini? Network Technology" by Michael Warres https://pdfs.semanticscholar.org/143f/468fcbdafd20f2b8c27fe5e0a869913b641a.pdf The solution of course is simple, ensure that you deserialize into the same module that you serialized from, especially when deserializing in another jvm, so class resolution is identical. We serialize a lot of complex object graphs, none are circular. The module used for serialization should have visiblity of the entire graph of object classes. So if we're using OSGi modules, and provide a network / remote service (not to be confused with an OSGi remote service) we ensure the proxy's for these services have the same module installed at the client and server endpoints. The service is represented by a Java interface and the client makes calls on the interfaces methods. This interface may be implemented by what is called a smart proxy, which is encapsulated by a module which is dynamically downloaded at runtime, or a reflection Proxy using an InvocationHandler that is generated dynamically. We still provide an option for codebase annotations for client parameter objects, where a client subclasses parameter types and pass them to the service, but this is discouraged, it is provided for backward compatibility only. Where the parameters are also interfaces, the client can implement a remote object and pass it as a parameter instead, in our system, this will cause a module to be loaded in the server identical to that at the client to resolve the remote object classes, without using stream codebase annotations. Incidentally, if you're curious how this happens, a proxy is sent {I guess you can call it a serialization proxy :) } and authenticated by the remote end, security constraints applied, then the remote end asks the proxy for a codebase URL,which is loaded into a ClassLoader with controlled visibility, this is extensible using a ServiceProvider or OSGi service, then the proxy is deserialized into this by calling a method on the serialization proxy. By limiting scope, we can still have 99% of the benefits of distributed objects, without the pain. Incidentally apart from the complexity of class resolution, what really limited distributed computing was IPv4. IPv6 removes the network addressing limitations placed on distributed computing. So I'd make the following qualifications: 1. Use only primitive types when serializing between different languages. 2. Serialize Java language Object types and primitives only between jvm's when class visibility is uncontrolled. 3. When serializing other object types, ensure they are immutable if shared and that class visibility is identical and managed at both endpoints. 4. Do not serialize objects whose classes may not be resolveable (when you need to depend on annotated streams and uncontrolled class resolution for example), find another way to solve the problem. We've had a 20 years to iron out the wrinkles. :) Regards, Peter. On 23/08/2019 7:36 AM, Peter Firmstone wrote: > Hi Sean, > > Regarding the section entitled "Why not write a new serialization > library?", unlike the serialization libraries listed, our purpose was > to be able to securely deserialize untrusted data, while maintaining > backward serial form compatibility with Java Serialization, provided > it didn't compromise security. > > We don't use blacklists or whitelists, we use permissions to grant > DeserializationPermission, it doesn't have the granularity of white > lists, but then, classes that implement @AtomicSerial are supposed to > be hardened implementations in any case. > > If it can be of use, feel free to experiment with it, hopefully it > might help with some of your design decisions: > > https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io > > > Much of the code on this site provides implementation examples as well. > > Regards, > > Peter. > > On 20/08/2019 7:55 AM, Sean Mullan wrote: >> Brian Goetz (copied) has done a lot of thinking in the serialization >> area, so I have copied him. Not sure if you have seen it but he >> recently posted a document about some of his ideas and possible >> future directions for serialization: >> http://cr.openjdk.java.net/~briangoetz/amber/serialization.html >> >> --Sean >> >> On 8/17/19 10:22 PM, Peter Firmstone wrote: >>> Thanks Sean, >>> >>> You've gone to some trouble to answer my question, which >>> demonstrates you have considered it. >>> >>> I donate some time to help maintain Apache River, derived from Sun's >>> Jini. Once Jini depended on RMI, today, not so much, it still has >>> some dependencies on some RMI interfaces, but doesn't utilise JRMP >>> although it provides some backward compatibilty enable it. >>> >>> But my point is, we heavily utilise java Serialization, and have an >>> independant implementation of a subset of Java Serialization >>> (originating from Apache Harmony). We do this for security as we >>> use an annotated serialization constructor. Serial form is >>> unchanged, we have Serializers for commonly used java library >>> objects, for example, we have a "PermissionSerializer", but we don't >>> have a "PermissionCollectionSerializer" or "PermissionsSerializer" >>> (for java.security.Permissions). Incidentally, we have found we do >>> not need the ability to serialize circular object graphs. >>> Throwable is an object that has a circular object graph, but that >>> circular object graph can be linked up after deserialization. >>> >>> Permission implementing Serializable is probably not too much of a >>> threat, as these objects are effectively immutable after lazy >>> initialization. >>> >>> ProtectionDomain calls java.security.Permissions::setReadOnly during >>> it's construction. >>> >>> ProtectionDomain::getPermissions returns internal >>> java.security.Permissions. If this is serialized, then the >>> readOnly internal state can be written to as the internal object >>> references are accessible from within the stream. >>> >>> Admitedly, the attacker would already need to have some privilege, >>> to have access to a ProtectionDomain, so it's a path of privilege >>> escallation. I'm not talking about gadget attacks and >>> deserialization of untrusted data, I'm talking about breaking >>> encapsulation. >>> >>> Even though we are heavily dependant on Java Serialization, we are >>> very careful when we implement it, and avoid implementing it when >>> possible. Hindsight is 20:20, but given we are now seeing some Java >>> SE backward compatibility breakages, perhaps it might be worth >>> considering breaking serialization. I don't mean we need to >>> necessarily break object serial form, but making the Java >>> serialization API explicit with subset of existing api features, >>> that makes long term maintenace and security less of a burden and >>> removing support for Serialization of some objects, where it is >>> seldom used, perhaps using a JEP that requests developers to >>> consider which library objects actually need to be serializable. >>> >>> Something we do in our Java Serialization API is require that >>> mutable deserialized objects are defensively copied during object >>> construction (serial fields are deserialized before an object is >>> constructed, the deserialized fields are accessible via a parameter >>> passed in during construction. We have tools that assist >>> developers to check deserialized Java Collections contain the >>> expected object types for example, so during object construction the >>> developer has to replace the Collection with a new instance and copy >>> the contents to the new Collection after checking the type of each >>> object contained therein. Also we don't actually serialize Java >>> Collections, we have standard serial forms for List, Set and Map, so >>> these serial forms are equal, similar to the List, Set and Map >>> contracts. By doing this, Collections don't actually need to >>> implement Serializable at all, as a Serializer becomes responsible >>> for their serialization. This also means that all Collections must >>> be accessed by interfaces, rather than implementation classes, so >>> the deserialization constructor, must defensively copy them into >>> their preferred Collection instance. It's a bit like dependency >>> injection. >>> >>> I know it would take time, and there would be some pain, but long >>> term it would save a lot of maintenance developer time. >>> >>> Regards, >>> >>> Peter. >>> >>> On 17/08/2019 12:50 AM, Sean Mullan wrote: >>>> On 8/15/19 8:18 PM, Peter Firmstone wrote: >>>>> Hi Roger, >>>>> >>>>> +1 for writeReplace >>>>> >>>>> Personally I'd like to see some security classes break backward >>>>> compatibility and remove support for serialization as it allows >>>>> someone to get references to internal objects, especially since >>>>> these classes are cached by the JVM. Which makes >>>>> PermissionCollection.setReadOnly() very easy to bypass, by adding >>>>> permissions to internal collections once you have a reference to >>>>> them. >>>>> >>>>> Does anyone have any use cases for serializing these objects? >>>>> >>>>> These objects are easy to re-create by sending or recieving and >>>>> parsing strings, because they are built from text based policy >>>>> files, and when you do that, you are validating input, so I never >>>>> did fully understand why they were made serializable. >>>> >>>> This is briefly explained on page 61 in the "Inside Java 2 Platform >>>> Security" book [1]: >>>> >>>> "The Permission class implements two interfaces: >>>> java.security.Guard and java.io.Serializable. For the latter, the >>>> intention is that Permission objects may be transported to remote >>>> machines, such as via Remote Method Invocation (RMI), and thus a >>>> Serializable representation is useful." >>>> >>>> The Permission class was introduced in Java SE 1.2 so there were >>>> different motivations back then :) >>>> >>>> --Sean >>>> >>>> [1] https://www.oracle.com/technetwork/java/javaee/index-141918.html >>> > From peter.firmstone at zeus.net.au Fri Aug 23 05:21:23 2019 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 23 Aug 2019 15:21:23 +1000 Subject: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily In-Reply-To: <5D5F5689.3050901@zeus.net.au> References: <079ccff9-e5dd-c0ab-0684-10380132386d@oracle.com> <5D55F646.3090907@zeus.net.au> <5D58B65C.4020701@zeus.net.au> <80b7767a-3f65-2db9-6d54-b9c2abcf2989@oracle.com> <5D5F0AC0.5090008@zeus.net.au> <5D5F5689.3050901@zeus.net.au> Message-ID: <5D5F77D3.3040703@zeus.net.au> I probably should have vetted this before hitting send... let me know if you need any clarifications. Cheers, Peter. On 23/08/2019 12:59 PM, Peter Firmstone wrote: > "...since at the time the industry believed that distributed objects > were going to save us from complexity.) Many of the sins of > serialization were committed in the desire to get that last .1%, but > the cost and benefit of that last .1% are woefully out of balance." > > The following are probably a non goals, but something to consider or > keep in mind, relating to distributed objects: > > The are three types of distributed objects: > > 1. Immutable value / data Object types. > 2. Shared Mutable Objects. > 3. Unshared Mutable Objects. > 4. Remote Objects / Services (best for managing shared mutable state). > > The second type of distributed object causes much pain and should be > discouraged. The first three types of distributed objects can have > class resolution issues, but these are solveable. > > A lot of folks also have problems with deserialization Objects when > class visibility is different at both ends, I'm guessing this would be > the same for value types. > > For example OSGi folk recommend using primitive parameter types for > remote OSGi services. > > RMI annotates streams with codebase annotations. Jini Extensible > Remote Invocation used to do that too. > > The problem with RMI codebase and Jini codebase annotations is if you > resolve your classes locally, you lose the codebase annotations, when > re-serializing data and because class visibility can be different at > different endpoints, end up with all sorts of class resolution > issues. "Class Loading Issues in Java? RMIand Jini? Network > Technology" by Michael Warres > https://pdfs.semanticscholar.org/143f/468fcbdafd20f2b8c27fe5e0a869913b641a.pdf > > > The solution of course is simple, ensure that you deserialize into the > same module that you serialized from, especially when deserializing in > another jvm, so class resolution is identical. > > We serialize a lot of complex object graphs, none are circular. The > module used for serialization should have visiblity of the entire > graph of object classes. > > So if we're using OSGi modules, and provide a network / remote service > (not to be confused with an OSGi remote service) we ensure the proxy's > for these services have the same module installed at the client and > server endpoints. The service is represented by a Java interface and > the client makes calls on the interfaces methods. This interface may > be implemented by what is called a smart proxy, which is encapsulated > by a module which is dynamically downloaded at runtime, or a > reflection Proxy using an InvocationHandler that is generated > dynamically. > > We still provide an option for codebase annotations for client > parameter objects, where a client subclasses parameter types and pass > them to the service, but this is discouraged, it is provided for > backward compatibility only. Where the parameters are also > interfaces, the client can implement a remote object and pass it as a > parameter instead, in our system, this will cause a module to be > loaded in the server identical to that at the client to resolve the > remote object classes, without using stream codebase annotations. > > Incidentally, if you're curious how this happens, a proxy is sent {I > guess you can call it a serialization proxy :) } and authenticated by > the remote end, security constraints applied, then the remote end asks > the proxy for a codebase URL,which is loaded into a ClassLoader with > controlled visibility, this is extensible using a ServiceProvider or > OSGi service, then the proxy is deserialized into this by calling a > method on the serialization proxy. > > By limiting scope, we can still have 99% of the benefits of > distributed objects, without the pain. > > Incidentally apart from the complexity of class resolution, what > really limited distributed computing was IPv4. IPv6 removes the > network addressing limitations placed on distributed computing. > > So I'd make the following qualifications: > > 1. Use only primitive types when serializing between different > languages. > 2. Serialize Java language Object types and primitives only between > jvm's when class visibility is uncontrolled. > 3. When serializing other object types, ensure they are immutable if > shared and that class visibility is identical and managed at both > endpoints. > 4. Do not serialize objects whose classes may not be resolveable > (when you need to depend on annotated streams and uncontrolled > class resolution for example), find another way to solve the > problem. > > We've had a 20 years to iron out the wrinkles. :) > > Regards, > > Peter. > > On 23/08/2019 7:36 AM, Peter Firmstone wrote: >> Hi Sean, >> >> Regarding the section entitled "Why not write a new serialization >> library?", unlike the serialization libraries listed, our purpose was >> to be able to securely deserialize untrusted data, while maintaining >> backward serial form compatibility with Java Serialization, provided >> it didn't compromise security. >> >> We don't use blacklists or whitelists, we use permissions to grant >> DeserializationPermission, it doesn't have the granularity of white >> lists, but then, classes that implement @AtomicSerial are supposed to >> be hardened implementations in any case. >> >> If it can be of use, feel free to experiment with it, hopefully it >> might help with some of your design decisions: >> >> https://github.com/pfirmstone/JGDMS/tree/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io >> >> >> Much of the code on this site provides implementation examples as well. >> >> Regards, >> >> Peter. >> >> On 20/08/2019 7:55 AM, Sean Mullan wrote: >>> Brian Goetz (copied) has done a lot of thinking in the serialization >>> area, so I have copied him. Not sure if you have seen it but he >>> recently posted a document about some of his ideas and possible >>> future directions for serialization: >>> http://cr.openjdk.java.net/~briangoetz/amber/serialization.html >>> >>> --Sean >>> >>> On 8/17/19 10:22 PM, Peter Firmstone wrote: >>>> Thanks Sean, >>>> >>>> You've gone to some trouble to answer my question, which >>>> demonstrates you have considered it. >>>> >>>> I donate some time to help maintain Apache River, derived from >>>> Sun's Jini. Once Jini depended on RMI, today, not so much, it >>>> still has some dependencies on some RMI interfaces, but doesn't >>>> utilise JRMP although it provides some backward compatibilty enable >>>> it. >>>> >>>> But my point is, we heavily utilise java Serialization, and have an >>>> independant implementation of a subset of Java Serialization >>>> (originating from Apache Harmony). We do this for security as we >>>> use an annotated serialization constructor. Serial form is >>>> unchanged, we have Serializers for commonly used java library >>>> objects, for example, we have a "PermissionSerializer", but we >>>> don't have a "PermissionCollectionSerializer" or >>>> "PermissionsSerializer" (for java.security.Permissions). >>>> Incidentally, we have found we do not need the ability to serialize >>>> circular object graphs. Throwable is an object that has a >>>> circular object graph, but that circular object graph can be linked >>>> up after deserialization. >>>> >>>> Permission implementing Serializable is probably not too much of a >>>> threat, as these objects are effectively immutable after lazy >>>> initialization. >>>> >>>> ProtectionDomain calls java.security.Permissions::setReadOnly >>>> during it's construction. >>>> >>>> ProtectionDomain::getPermissions returns internal >>>> java.security.Permissions. If this is serialized, then the >>>> readOnly internal state can be written to as the internal object >>>> references are accessible from within the stream. >>>> >>>> Admitedly, the attacker would already need to have some privilege, >>>> to have access to a ProtectionDomain, so it's a path of privilege >>>> escallation. I'm not talking about gadget attacks and >>>> deserialization of untrusted data, I'm talking about breaking >>>> encapsulation. >>>> >>>> Even though we are heavily dependant on Java Serialization, we are >>>> very careful when we implement it, and avoid implementing it when >>>> possible. Hindsight is 20:20, but given we are now seeing some Java >>>> SE backward compatibility breakages, perhaps it might be worth >>>> considering breaking serialization. I don't mean we need to >>>> necessarily break object serial form, but making the Java >>>> serialization API explicit with subset of existing api features, >>>> that makes long term maintenace and security less of a burden and >>>> removing support for Serialization of some objects, where it is >>>> seldom used, perhaps using a JEP that requests developers to >>>> consider which library objects actually need to be serializable. >>>> >>>> Something we do in our Java Serialization API is require that >>>> mutable deserialized objects are defensively copied during object >>>> construction (serial fields are deserialized before an object is >>>> constructed, the deserialized fields are accessible via a parameter >>>> passed in during construction. We have tools that assist >>>> developers to check deserialized Java Collections contain the >>>> expected object types for example, so during object construction >>>> the developer has to replace the Collection with a new instance and >>>> copy the contents to the new Collection after checking the type of >>>> each object contained therein. Also we don't actually serialize >>>> Java Collections, we have standard serial forms for List, Set and >>>> Map, so these serial forms are equal, similar to the List, Set and >>>> Map contracts. By doing this, Collections don't actually need to >>>> implement Serializable at all, as a Serializer becomes responsible >>>> for their serialization. This also means that all Collections >>>> must be accessed by interfaces, rather than implementation classes, >>>> so the deserialization constructor, must defensively copy them into >>>> their preferred Collection instance. It's a bit like dependency >>>> injection. >>>> >>>> I know it would take time, and there would be some pain, but long >>>> term it would save a lot of maintenance developer time. >>>> >>>> Regards, >>>> >>>> Peter. >>>> >>>> On 17/08/2019 12:50 AM, Sean Mullan wrote: >>>>> On 8/15/19 8:18 PM, Peter Firmstone wrote: >>>>>> Hi Roger, >>>>>> >>>>>> +1 for writeReplace >>>>>> >>>>>> Personally I'd like to see some security classes break backward >>>>>> compatibility and remove support for serialization as it allows >>>>>> someone to get references to internal objects, especially since >>>>>> these classes are cached by the JVM. Which makes >>>>>> PermissionCollection.setReadOnly() very easy to bypass, by adding >>>>>> permissions to internal collections once you have a reference to >>>>>> them. >>>>>> >>>>>> Does anyone have any use cases for serializing these objects? >>>>>> >>>>>> These objects are easy to re-create by sending or recieving and >>>>>> parsing strings, because they are built from text based policy >>>>>> files, and when you do that, you are validating input, so I never >>>>>> did fully understand why they were made serializable. >>>>> >>>>> This is briefly explained on page 61 in the "Inside Java 2 >>>>> Platform Security" book [1]: >>>>> >>>>> "The Permission class implements two interfaces: >>>>> java.security.Guard and java.io.Serializable. For the latter, the >>>>> intention is that Permission objects may be transported to remote >>>>> machines, such as via Remote Method Invocation (RMI), and thus a >>>>> Serializable representation is useful." >>>>> >>>>> The Permission class was introduced in Java SE 1.2 so there were >>>>> different motivations back then :) >>>>> >>>>> --Sean >>>>> >>>>> [1] https://www.oracle.com/technetwork/java/javaee/index-141918.html >>>> >> > From Alan.Bateman at oracle.com Fri Aug 23 09:08:51 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Aug 2019 10:08:51 +0100 Subject: RFR 8229958: Provider.getService() scalability issue for legacy algorithms and message digests In-Reply-To: <4BDF747E-9088-42FC-9D20-E2F998DDFAD9@amazon.com> References: <4BDF747E-9088-42FC-9D20-E2F998DDFAD9@amazon.com> Message-ID: <9160be31-5721-80ea-a692-99fdf59a8b10@oracle.com> On 22/08/2019 01:01, Yang, Letu wrote: > Hi, > > Please review the fix of?https://bugs.openjdk.java.net/browse/JDK-8229958?where I made the change to allow majority of calls don't have to acquire the locks when checking the availability of the Provider object. Similar effort had been made in fixing?https://bugs.openjdk.java.net/browse/JDK-7092821?, but it only helped the calls for new encryption algorithms. Xin had helped me to upload the CR:? https://cr.openjdk.java.net/~xliu/8229958/01/webrev/?. I skimmed through java/security/Provider.java and I think it will needs further work. I suspect ensureLegacyParser (and parseLegacyPut) need to replace legacyMap after the new map has been populated, otherwise you risk a caller to getService accessing the new map before it has been populated. The change to ProviderConfig.getProvider looks okay but would be good for someone more familiar with this code to also check it. -Alan From sgehwolf at redhat.com Mon Aug 26 13:23:40 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Aug 2019 15:23:40 +0200 Subject: [8u] RFR: 8218780: Update MUSCLE PCSC-Lite header files Message-ID: Hi, Could I please get a review of this MUSCLE header files update in OpenJDK 8u? I'd like to backport this bug as it's also going to be in Oracle JDK 8u231 (equiv to OpenJDK 8u232) as well. The OpenJDK 11 patch applies almost cleanly post path-unshuffelling. Changes which didn't apply were a copyright header update in pcsc.c. I've omitted these. Bug: https://bugs.openjdk.java.net/browse/JDK-8218780 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/01/webrev/ JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/0bcc59a50c88 There is going to be a follow-up fix adding back COPYING via JDK-8226607 which I propose for backport to OpenJDK 8u as well. Testing: smartcardio sanity and build on Linux x86_64 (Fedora 30 and RHEL 6) Thanks to Aleksey Shipilev who helped test this patch. Thoughts? Thanks, Severin From sgehwolf at redhat.com Mon Aug 26 13:24:11 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Aug 2019 15:24:11 +0200 Subject: [8u] RFR: 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Message-ID: Hi, Could I get a review of this follow-up fix for an 8u backport (JDK- 8218780)? This follow-up re-adds a COPYING file to the MUSCLE pcsc library header files removed by the JDK-8218780 backport. The patch differs from the version in JDK 11 since there is no pcsclite.md file in OpenJDK 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8226607 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226607/jdk8/01/webrev/ JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9e304e99cbb2 I intend to push this fix together with JDK-8218780 once it passed review and got approved. Thoughts? Thanks, Severin From weijun.wang at oracle.com Tue Aug 27 13:18:12 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 27 Aug 2019 21:18:12 +0800 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> <9367A39F-2863-48D5-BE4A-7995187A8973@oracle.com> Message-ID: Oops, sorry. I was calling "new X509CertImp" in PEM keystore and this has not made use of the cache in X509Factory, and since my benchmark test loads keystores hundreds of times it's certainly much slower than JKS. I've disabled the cache and now PEM is only around 20% slower than JKS. I'm sure some optimization will make it even smaller. --Max > On Aug 22, 2019, at 11:47 PM, Weijun Wang wrote: > > > >> On Aug 22, 2019, at 10:40 PM, Sean Mullan wrote: >> >> On 8/14/19 10:07 AM, Weijun Wang wrote: >>> The difference will be big. I've simplified the logic into >>> 1. read bytes between first ": " and \r\n as alias >>> 2. read bytes between first \r\n after first "-" and next "-" as a cert >>> 3. goto 1 >>> And I only store the cert bytes and do not create a Certificate until getCertificate() is read. I even haven't de-BASE64 them. >>> Time spent is still ~2.5x of JKS (when reading from a ByteArrayInputStream). >>> I guess the major reason is that there is no length field for the cert, so we must read-and-check all the time. >> >> Could you store the length as an attribute, perhaps? > > I'm reluctant to do that. This means people cannot edit the file with a text editor and have to use keytool to manage it. > > Of course, this file is still PEM and can be used by other tools, just that they should not try to modify it. > > I'll see if there are other ways to improve the performance. One way I'm thinking about is to read the first few bytes of a cert to find out the length (It's always also 30 82 AB CD...). > > Thanks, > Max > >> >> --Sean >> >>> --Max >>>> On Aug 14, 2019, at 9:31 PM, Sean Mullan wrote: >>>> >>>> On 8/13/19 10:19 PM, Weijun Wang wrote: >>>>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>>>> see wether your parser doesn't choke on it. >>>>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. >>>> >>>> This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 >>>> >>>> I would not want to see a regression in performance. >>>> >>>> --Sean > From fguillaume at nuxeo.com Tue Aug 27 15:16:58 2019 From: fguillaume at nuxeo.com (Florent Guillaume) Date: Tue, 27 Aug 2019 17:16:58 +0200 Subject: Slow LoginContext.login() due to repeated ServiceLoader lookups Message-ID: Hi, When switching from Java 8 to Java 11, we're experiencing an important slowdown when executing LoginContext.login(), especially under concurrency. We tracked this down to JDK-8047789 which changed the way the lookup of LoginModules is done in LoginContext.invoke. Previously, it was a simple Class.forName that is of course extremely optimized. After JDK-8047789, there is first a ServiceLoader-based lookup for the class. This lookup doesn't seem to be cached. In our case, it has to open the 400+ JARs in our classpath (we're not using modules yet) to check the content of META-INF/services/javax.security.auth.spi.LoginModule, and in addition this hits a synchronized block in ZipFile.getEntry which prevents any performance under concurrency. Is there anything we can do to improve LoginContext.login() in this context? For reference, the code path to the synchronized block: at java.util.zip.ZipFile.getEntry(java.base at 11.0.4/ZipFile.java:346) - locked <0x000000068b18bdd0> (a java.util.jar.JarFile) at java.util.zip.ZipFile$1.getEntry(java.base at 11.0.4/ZipFile.java:1121) at java.util.jar.JarFile.getEntry0(java.base at 11.0.4/JarFile.java:576) at java.util.jar.JarFile.getEntry(java.base at 11.0.4/JarFile.java:506) at java.util.jar.JarFile.getJarEntry(java.base at 11.0.4/JarFile.java:468) at jdk.internal.loader.URLClassPath$JarLoader.getResource(java.base at 11.0.4 /URLClassPath.java:929) at jdk.internal.loader.URLClassPath$JarLoader.findResource(java.base at 11.0.4 /URLClassPath.java:912) at jdk.internal.loader.URLClassPath$1.next(java.base at 11.0.4 /URLClassPath.java:341) at jdk.internal.loader.URLClassPath$1.hasMoreElements(java.base at 11.0.4 /URLClassPath.java:351) at java.net.URLClassLoader$3$1.run(java.base at 11.0.4/URLClassLoader.java:687) at java.net.URLClassLoader$3$1.run(java.base at 11.0.4/URLClassLoader.java:685) at java.security.AccessController.doPrivileged(java.base at 11.0.4/Native Method) at java.net.URLClassLoader$3.next(java.base at 11.0.4/URLClassLoader.java:684) at java.net.URLClassLoader$3.hasMoreElements(java.base at 11.0.4 /URLClassLoader.java:709) at java.lang.CompoundEnumeration.next(java.base at 11.0.4 /ClassLoader.java:3022) at java.lang.CompoundEnumeration.hasMoreElements(java.base at 11.0.4 /ClassLoader.java:3031) at org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc(WebappClassLoaderBase.java:2670) at org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements(WebappClassLoaderBase.java:2655) at java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(java.base at 11.0.4 /ServiceLoader.java:1202) at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(java.base at 11.0.4 /ServiceLoader.java:1220) at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(java.base at 11.0.4 /ServiceLoader.java:1264) at java.util.ServiceLoader$2.hasNext(java.base at 11.0.4 /ServiceLoader.java:1299) at java.util.ServiceLoader$3.hasNext(java.base at 11.0.4 /ServiceLoader.java:1384) at javax.security.auth.login.LoginContext.invoke(java.base at 11.0.4 /LoginContext.java:691) at javax.security.auth.login.LoginContext$4.run(java.base at 11.0.4 /LoginContext.java:665) at javax.security.auth.login.LoginContext$4.run(java.base at 11.0.4 /LoginContext.java:663) at java.security.AccessController.doPrivileged(java.base at 11.0.4/Native Method) at javax.security.auth.login.LoginContext.invokePriv(java.base at 11.0.4 /LoginContext.java:663) at javax.security.auth.login.LoginContext.login(java.base at 11.0.4 /LoginContext.java:574) Thanks, Florent -- [image: Nuxeo Logo] Florent Guillaume Head of R&D [image: LinkedIn] [image: Twitter] [image: Github] Nuxeo Content Services Platform. Stay ahead. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Tue Aug 27 15:58:17 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 27 Aug 2019 16:58:17 +0100 Subject: Slow LoginContext.login() due to repeated ServiceLoader lookups In-Reply-To: References: Message-ID: <11e5940b-005e-d484-f8c1-d05cbf5b371d@oracle.com> Probably best to log a bug to capture this issue. It reminds me of another issue I've been meaning to wrap up: https://bugs.openjdk.java.net/browse/JDK-8223260 Similar scenario in how the ContextFactory is searched for. My proposed patch is to cache a factory per classloader (for the NamingManager issue at least) regards, Sean. On 27/08/2019 16:16, Florent Guillaume wrote: > Hi, > > When switching from Java 8 to Java 11, we're experiencing an important > slowdown when executing LoginContext.login(), especially under > concurrency. > > We tracked this down to JDK-8047789 which changed the way the lookup > of LoginModules is done in LoginContext.invoke. Previously, it was a > simple?Class.forName that is of course extremely optimized. > After?JDK-8047789, there is first a ServiceLoader-based lookup for the > class. This lookup doesn't seem to be cached. In our case, it has to > open the 400+ JARs in our classpath (we're not using modules yet) to > check the content > of?META-INF/services/javax.security.auth.spi.LoginModule, and in > addition this hits a synchronized block in ZipFile.getEntry which > prevents any performance under concurrency. > > Is there anything we can do to improve LoginContext.login() in this > context? > > For reference, the code path to the synchronized block: > at java.util.zip.ZipFile.getEntry(java.base at 11.0.4/ZipFile.java:346) > - locked <0x000000068b18bdd0> (a java.util.jar.JarFile) > at java.util.zip.ZipFile$1.getEntry(java.base at 11.0.4/ZipFile.java:1121) > at java.util.jar.JarFile.getEntry0(java.base at 11.0.4/JarFile.java:576) > at java.util.jar.JarFile.getEntry(java.base at 11.0.4/JarFile.java:506) > at java.util.jar.JarFile.getJarEntry(java.base at 11.0.4/JarFile.java:468) > at > jdk.internal.loader.URLClassPath$JarLoader.getResource(java.base at 11.0.4/URLClassPath.java:929) > at > jdk.internal.loader.URLClassPath$JarLoader.findResource(java.base at 11.0.4/URLClassPath.java:912) > at > jdk.internal.loader.URLClassPath$1.next(java.base at 11.0.4/URLClassPath.java:341) > at > jdk.internal.loader.URLClassPath$1.hasMoreElements(java.base at 11.0.4/URLClassPath.java:351) > at > java.net.URLClassLoader$3$1.run(java.base at 11.0.4/URLClassLoader.java:687) > at > java.net.URLClassLoader$3$1.run(java.base at 11.0.4/URLClassLoader.java:685) > at java.security.AccessController.doPrivileged(java.base at 11.0.4/Native > Method) > at > java.net.URLClassLoader$3.next(java.base at 11.0.4/URLClassLoader.java:684) > at > java.net.URLClassLoader$3.hasMoreElements(java.base at 11.0.4/URLClassLoader.java:709) > at > java.lang.CompoundEnumeration.next(java.base at 11.0.4/ClassLoader.java:3022) > at > java.lang.CompoundEnumeration.hasMoreElements(java.base at 11.0.4/ClassLoader.java:3031) > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc(WebappClassLoaderBase.java:2670) > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements(WebappClassLoaderBase.java:2655) > at > java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(java.base at 11.0.4/ServiceLoader.java:1202) > at > java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(java.base at 11.0.4/ServiceLoader.java:1220) > at > java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(java.base at 11.0.4/ServiceLoader.java:1264) > at > java.util.ServiceLoader$2.hasNext(java.base at 11.0.4/ServiceLoader.java:1299) > at > java.util.ServiceLoader$3.hasNext(java.base at 11.0.4/ServiceLoader.java:1384) > at > javax.security.auth.login.LoginContext.invoke(java.base at 11.0.4/LoginContext.java:691) > at > javax.security.auth.login.LoginContext$4.run(java.base at 11.0.4/LoginContext.java:665) > at > javax.security.auth.login.LoginContext$4.run(java.base at 11.0.4/LoginContext.java:663) > at java.security.AccessController.doPrivileged(java.base at 11.0.4/Native > Method) > at > javax.security.auth.login.LoginContext.invokePriv(java.base at 11.0.4/LoginContext.java:663) > at > javax.security.auth.login.LoginContext.login(java.base at 11.0.4/LoginContext.java:574) > > Thanks, > > Florent > > -- > Nuxeo Logo > > Florent Guillaume? Head of R&D LinkedIn > Twitter > Github > > Nuxeo Content Services Platform. Stay ahead. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fguillaume at nuxeo.com Tue Aug 27 19:04:10 2019 From: fguillaume at nuxeo.com (Florent Guillaume) Date: Tue, 27 Aug 2019 21:04:10 +0200 Subject: Slow LoginContext.login() due to repeated ServiceLoader lookups In-Reply-To: <11e5940b-005e-d484-f8c1-d05cbf5b371d@oracle.com> References: <11e5940b-005e-d484-f8c1-d05cbf5b371d@oracle.com> Message-ID: I'm not an Author so I created the ticket on bugreport.java.com, it has the internal review ID 9062061 Thanks, Florent On Tue, Aug 27, 2019 at 6:04 PM Se?n Coffey wrote: > Probably best to log a bug to capture this issue. > > It reminds me of another issue I've been meaning to wrap up: > https://bugs.openjdk.java.net/browse/JDK-8223260 > > Similar scenario in how the ContextFactory is searched for. My proposed > patch is to cache a factory per classloader (for the NamingManager issue > at least) > > regards, > Sean. > On 27/08/2019 16:16, Florent Guillaume wrote: > > Hi, > > When switching from Java 8 to Java 11, we're experiencing an important > slowdown when executing LoginContext.login(), especially under concurrency. > > We tracked this down to JDK-8047789 which changed the way the lookup of > LoginModules is done in LoginContext.invoke. Previously, it was a > simple Class.forName that is of course extremely optimized. > After JDK-8047789, there is first a ServiceLoader-based lookup for the > class. This lookup doesn't seem to be cached. In our case, it has to open > the 400+ JARs in our classpath (we're not using modules yet) to check the > content of META-INF/services/javax.security.auth.spi.LoginModule, and in > addition this hits a synchronized block in ZipFile.getEntry which prevents > any performance under concurrency. > > Is there anything we can do to improve LoginContext.login() in this > context? > > For reference, the code path to the synchronized block: > at java.util.zip.ZipFile.getEntry(java.base at 11.0.4/ZipFile.java:346) > - locked <0x000000068b18bdd0> (a java.util.jar.JarFile) > at java.util.zip.ZipFile$1.getEntry(java.base at 11.0.4/ZipFile.java:1121) > at java.util.jar.JarFile.getEntry0(java.base at 11.0.4/JarFile.java:576) > at java.util.jar.JarFile.getEntry(java.base at 11.0.4/JarFile.java:506) > at java.util.jar.JarFile.getJarEntry(java.base at 11.0.4/JarFile.java:468) > at jdk.internal.loader.URLClassPath$JarLoader.getResource( > java.base at 11.0.4/URLClassPath.java:929) > at jdk.internal.loader.URLClassPath$JarLoader.findResource( > java.base at 11.0.4/URLClassPath.java:912) > at jdk.internal.loader.URLClassPath$1.next( > java.base at 11.0.4/URLClassPath.java:341) > at jdk.internal.loader.URLClassPath$1.hasMoreElements( > java.base at 11.0.4/URLClassPath.java:351) > at java.net.URLClassLoader$3$1.run( > java.base at 11.0.4/URLClassLoader.java:687) > at java.net.URLClassLoader$3$1.run( > java.base at 11.0.4/URLClassLoader.java:685) > at java.security.AccessController.doPrivileged(java.base at 11.0.4/Native > Method) > at java.net.URLClassLoader$3.next(java.base at 11.0.4/URLClassLoader.java:684 > ) > at java.net.URLClassLoader$3.hasMoreElements( > java.base at 11.0.4/URLClassLoader.java:709) > at java.lang.CompoundEnumeration.next( > java.base at 11.0.4/ClassLoader.java:3022) > at java.lang.CompoundEnumeration.hasMoreElements( > java.base at 11.0.4/ClassLoader.java:3031) > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc(WebappClassLoaderBase.java:2670) > at > org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements(WebappClassLoaderBase.java:2655) > at java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass( > java.base at 11.0.4/ServiceLoader.java:1202) > at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService( > java.base at 11.0.4/ServiceLoader.java:1220) > at java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext( > java.base at 11.0.4/ServiceLoader.java:1264) > at java.util.ServiceLoader$2.hasNext( > java.base at 11.0.4/ServiceLoader.java:1299) > at java.util.ServiceLoader$3.hasNext( > java.base at 11.0.4/ServiceLoader.java:1384) > at javax.security.auth.login.LoginContext.invoke( > java.base at 11.0.4/LoginContext.java:691) > at javax.security.auth.login.LoginContext$4.run( > java.base at 11.0.4/LoginContext.java:665) > at javax.security.auth.login.LoginContext$4.run( > java.base at 11.0.4/LoginContext.java:663) > at java.security.AccessController.doPrivileged(java.base at 11.0.4/Native > Method) > at javax.security.auth.login.LoginContext.invokePriv( > java.base at 11.0.4/LoginContext.java:663) > at javax.security.auth.login.LoginContext.login( > java.base at 11.0.4/LoginContext.java:574) > > Thanks, > > Florent > > -- > [image: Nuxeo Logo] > > Florent Guillaume Head of R&D [image: LinkedIn] > [image: Twitter] > [image: Github] > > Nuxeo Content Services Platform. Stay ahead. > > -- [image: Nuxeo Logo] Florent Guillaume Head of R&D [image: LinkedIn] [image: Twitter] [image: Github] Nuxeo Content Services Platform. Stay ahead. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Wed Aug 28 00:16:00 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 27 Aug 2019 17:16:00 -0700 Subject: JDK 14 RFR of JDK-8229999 : Apply java.io.Serial annotations to security types in java.base Message-ID: Hello, Recent work for JDK-8202385: "Annotation to mark serial-related fields and methods" added the java.io.Serial annotation type to the platform. The intention of this new annotation type is to allow serialization-related fields and methods to be marked as documentation and to allow stricter compile-time checking, analogous to the checking done for @Override. Implementing those stricter serialization-related checks will be done under JDK-8202056. Please review the application of java.io.Serial to the security-related types in the base module: ??? JDK-8229999 : Apply java.io.Serial annotations to security types in java.base ??? http://cr.openjdk.java.net/~darcy/8229999.0/ As a reminder, the 5 serialization-related methods and 2 fields are: ??? * private void writeObject(java.io.ObjectOutputStream stream) throws IOException ??? * private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException ??? * private void readObjectNoData() throws ObjectStreamException ??? * ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException ??? * ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException ??? * private static final ObjectStreamField[] serialPersistentFields ??? * private static final long serialVersionUID Thanks, -Joe From sean.coffey at oracle.com Wed Aug 28 07:55:24 2019 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 28 Aug 2019 08:55:24 +0100 Subject: (JDK-8230297) Slow LoginContext.login() due to repeated ServiceLoader lookups In-Reply-To: References: <11e5940b-005e-d484-f8c1-d05cbf5b371d@oracle.com> Message-ID: Thanks Florent. Now visible at https://bugs.openjdk.java.net/browse/JDK-8230297 regards, Sean. On 27/08/2019 20:04, Florent Guillaume wrote: > I'm not an Author so I created the ticket on bugreport.java.com > , it has the?internal review ID 9062061 > > Thanks, > Florent > > On Tue, Aug 27, 2019 at 6:04 PM Se?n Coffey > wrote: > > Probably best to log a bug to capture this issue. > > It reminds me of another issue I've been meaning to wrap up: > https://bugs.openjdk.java.net/browse/JDK-8223260 > > Similar scenario in how the ContextFactory is searched for. My > proposed > patch is to cache a factory per classloader (for the NamingManager > issue at least) > > regards, > Sean. > > On 27/08/2019 16:16, Florent Guillaume wrote: >> Hi, >> >> When switching from Java 8 to Java 11, we're experiencing an >> important slowdown when executing LoginContext.login(), >> especially under concurrency. >> >> We tracked this down to JDK-8047789 which changed the way the >> lookup of LoginModules is done in LoginContext.invoke. >> Previously, it was a simple?Class.forName that is of course >> extremely optimized. After?JDK-8047789, there is first a >> ServiceLoader-based lookup for the class. This lookup doesn't >> seem to be cached. In our case, it has to open the 400+ JARs in >> our classpath (we're not using modules yet) to check the content >> of?META-INF/services/javax.security.auth.spi.LoginModule, and in >> addition this hits a synchronized block in ZipFile.getEntry which >> prevents any performance under concurrency. >> >> Is there anything we can do to improve LoginContext.login() in >> this context? >> >> For reference, the code path to the synchronized block: >> at >> java.util.zip.ZipFile.getEntry(java.base at 11.0.4/ZipFile.java:346 >> ) >> - locked <0x000000068b18bdd0> (a java.util.jar.JarFile) >> at >> java.util.zip.ZipFile$1.getEntry(java.base at 11.0.4/ZipFile.java:1121 >> ) >> at >> java.util.jar.JarFile.getEntry0(java.base at 11.0.4/JarFile.java:576 >> ) >> at >> java.util.jar.JarFile.getEntry(java.base at 11.0.4/JarFile.java:506 >> ) >> at >> java.util.jar.JarFile.getJarEntry(java.base at 11.0.4/JarFile.java:468 >> ) >> at >> jdk.internal.loader.URLClassPath$JarLoader.getResource(java.base at 11.0.4/URLClassPath.java:929 >> ) >> at >> jdk.internal.loader.URLClassPath$JarLoader.findResource(java.base at 11.0.4/URLClassPath.java:912 >> ) >> at >> jdk.internal.loader.URLClassPath$1.next(java.base at 11.0.4/URLClassPath.java:341 >> ) >> at >> jdk.internal.loader.URLClassPath$1.hasMoreElements(java.base at 11.0.4/URLClassPath.java:351 >> ) >> at >> java.net.URLClassLoader$3$1.run(java.base at 11.0.4/URLClassLoader.java:687 >> ) >> at >> java.net.URLClassLoader$3$1.run(java.base at 11.0.4/URLClassLoader.java:685 >> ) >> at >> java.security.AccessController.doPrivileged(java.base at 11.0.4/Native >> Method) >> at >> java.net.URLClassLoader$3.next(java.base at 11.0.4/URLClassLoader.java:684 >> ) >> at >> java.net.URLClassLoader$3.hasMoreElements(java.base at 11.0.4/URLClassLoader.java:709 >> ) >> at >> java.lang.CompoundEnumeration.next(java.base at 11.0.4/ClassLoader.java:3022 >> ) >> at >> java.lang.CompoundEnumeration.hasMoreElements(java.base at 11.0.4/ClassLoader.java:3031 >> ) >> at >> org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.inc(WebappClassLoaderBase.java:2670) >> at >> org.apache.catalina.loader.WebappClassLoaderBase$CombinedEnumeration.hasMoreElements(WebappClassLoaderBase.java:2655) >> at >> java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(java.base at 11.0.4/ServiceLoader.java:1202 >> ) >> at >> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(java.base at 11.0.4/ServiceLoader.java:1220 >> ) >> at >> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(java.base at 11.0.4/ServiceLoader.java:1264 >> ) >> at >> java.util.ServiceLoader$2.hasNext(java.base at 11.0.4/ServiceLoader.java:1299 >> ) >> at >> java.util.ServiceLoader$3.hasNext(java.base at 11.0.4/ServiceLoader.java:1384 >> ) >> at >> javax.security.auth.login.LoginContext.invoke(java.base at 11.0.4/LoginContext.java:691 >> ) >> at >> javax.security.auth.login.LoginContext$4.run(java.base at 11.0.4/LoginContext.java:665 >> ) >> at >> javax.security.auth.login.LoginContext$4.run(java.base at 11.0.4/LoginContext.java:663 >> ) >> at >> java.security.AccessController.doPrivileged(java.base at 11.0.4/Native >> Method) >> at >> javax.security.auth.login.LoginContext.invokePriv(java.base at 11.0.4/LoginContext.java:663 >> ) >> at >> javax.security.auth.login.LoginContext.login(java.base at 11.0.4/LoginContext.java:574 >> ) >> >> Thanks, >> >> Florent >> >> -- >> Nuxeo Logo >> >> Florent Guillaume? Head of R&D LinkedIn >> Twitter >> Github >> >> Nuxeo Content Services Platform. Stay ahead. >> > > > -- > Nuxeo Logo > > Florent Guillaume Head of R&D LinkedIn > Twitter > Github > > Nuxeo Content Services Platform. Stay ahead. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed Aug 28 15:00:37 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 28 Aug 2019 11:00:37 -0400 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> <9367A39F-2863-48D5-BE4A-7995187A8973@oracle.com> Message-ID: On 8/27/19 9:18 AM, Weijun Wang wrote: > Oops, sorry. I was calling "new X509CertImp" in PEM keystore and this has not made use of the cache in X509Factory, and since my benchmark test loads keystores hundreds of times it's certainly much slower than JKS. > > I've disabled the cache and now PEM is only around 20% slower than JKS. I'm sure some optimization will make it even smaller. Do you have an updated webrev? --Sean > > --Max > >> On Aug 22, 2019, at 11:47 PM, Weijun Wang wrote: >> >> >> >>> On Aug 22, 2019, at 10:40 PM, Sean Mullan wrote: >>> >>> On 8/14/19 10:07 AM, Weijun Wang wrote: >>>> The difference will be big. I've simplified the logic into >>>> 1. read bytes between first ": " and \r\n as alias >>>> 2. read bytes between first \r\n after first "-" and next "-" as a cert >>>> 3. goto 1 >>>> And I only store the cert bytes and do not create a Certificate until getCertificate() is read. I even haven't de-BASE64 them. >>>> Time spent is still ~2.5x of JKS (when reading from a ByteArrayInputStream). >>>> I guess the major reason is that there is no length field for the cert, so we must read-and-check all the time. >>> >>> Could you store the length as an attribute, perhaps? >> >> I'm reluctant to do that. This means people cannot edit the file with a text editor and have to use keytool to manage it. >> >> Of course, this file is still PEM and can be used by other tools, just that they should not try to modify it. >> >> I'll see if there are other ways to improve the performance. One way I'm thinking about is to read the first few bytes of a cert to find out the length (It's always also 30 82 AB CD...). >> >> Thanks, >> Max >> >>> >>> --Sean >>> >>>> --Max >>>>> On Aug 14, 2019, at 9:31 PM, Sean Mullan wrote: >>>>> >>>>> On 8/13/19 10:19 PM, Weijun Wang wrote: >>>>>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>>>>> see wether your parser doesn't choke on it. >>>>>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. >>>>> >>>>> This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 >>>>> >>>>> I would not want to see a regression in performance. >>>>> >>>>> --Sean >> > From Roger.Riggs at oracle.com Wed Aug 28 16:33:57 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 28 Aug 2019 12:33:57 -0400 Subject: JDK 14 RFR of JDK-8229999 : Apply java.io.Serial annotations to security types in java.base In-Reply-To: References: Message-ID: Hi Joe, Looks fine to me. Roger On 8/27/19 8:16 PM, Joe Darcy wrote: > Hello, > > Recent work for JDK-8202385: "Annotation to mark serial-related fields > and methods" added the java.io.Serial annotation type to the platform. > The intention of this new annotation type is to allow > serialization-related fields and methods to be marked as documentation > and to allow stricter compile-time checking, analogous to the checking > done for @Override. Implementing those stricter serialization-related > checks will be done under JDK-8202056. > > Please review the application of java.io.Serial to the > security-related types in the base module: > > ??? JDK-8229999 : Apply java.io.Serial annotations to security types > in java.base > ??? http://cr.openjdk.java.net/~darcy/8229999.0/ > > As a reminder, the 5 serialization-related methods and 2 fields are: > > ??? * private void writeObject(java.io.ObjectOutputStream stream) > throws IOException > ??? * private void readObject(java.io.ObjectInputStream stream) throws > IOException, ClassNotFoundException > ??? * private void readObjectNoData() throws ObjectStreamException > ??? * ANY-ACCESS-MODIFIER Object writeReplace() throws > ObjectStreamException > ??? * ANY-ACCESS-MODIFIER Object readResolve() throws > ObjectStreamException > ??? * private static final ObjectStreamField[] serialPersistentFields > ??? * private static final long serialVersionUID > > Thanks, > > -Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Wed Aug 28 17:15:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 28 Aug 2019 18:15:30 +0100 Subject: [8u] RFR: 8218780: Update MUSCLE PCSC-Lite header files In-Reply-To: References: Message-ID: On 26/08/2019 14:23, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this MUSCLE header files update in > OpenJDK 8u? I'd like to backport this bug as it's also going to be in > Oracle JDK 8u231 (equiv to OpenJDK 8u232) as well. The OpenJDK 11 patch > applies almost cleanly post path-unshuffelling. Changes which didn't > apply were a copyright header update in pcsc.c. I've omitted these. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218780 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8218780/jdk8/01/webrev/ > JDK 11u changeset: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/0bcc59a50c88 > > There is going to be a follow-up fix adding back COPYING via > JDK-8226607 which I propose for backport to OpenJDK 8u as well. > > Testing: smartcardio sanity and build on Linux x86_64 (Fedora 30 and RHEL 6) > > Thanks to Aleksey Shipilev who helped test this patch. > > Thoughts? > > Thanks, > Severin > Most of this looks good. I was a little confused at first because the patch in your webrev looks quite different to the 11u changeset. However, once applied locally to the 8u repo, the diff between the two was as suggested and the PCSC library files (those in MUSCLE) were identical. I don't know what webrev did in creating that patch. The bit I don't understand is why you've decided to drop the copyright header change on the floor. Just because the original in 8u has 2014, while the original in 11u had 2015, does not make the change inapplicable. A better alternative may actually be to backport JDK-8207233 [0] first which is a nice little cleanup patch. I suspect this patch would then apply cleanly as these PCSC files are rarely touched. [0] https://bugs.openjdk.java.net/browse/JDK-8207233 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 https://keybase.io/gnu_andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From weijun.wang at oracle.com Thu Aug 29 00:21:56 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 29 Aug 2019 08:21:56 +0800 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> <9367A39F-2863-48D5-BE4A-7995187A8973@oracle.com> Message-ID: > On Aug 28, 2019, at 11:00 PM, Sean Mullan wrote: > > On 8/27/19 9:18 AM, Weijun Wang wrote: >> Oops, sorry. I was calling "new X509CertImp" in PEM keystore and this has not made use of the cache in X509Factory, and since my benchmark test loads keystores hundreds of times it's certainly much slower than JKS. >> I've disabled the cache and now PEM is only around 20% slower than JKS. I'm sure some optimization will make it even smaller. > > Do you have an updated webrev? No. I tried some code changes but there is no performance enhancement. --Max > > --Sean > >> --Max >>> On Aug 22, 2019, at 11:47 PM, Weijun Wang wrote: >>> >>> >>> >>>> On Aug 22, 2019, at 10:40 PM, Sean Mullan wrote: >>>> >>>> On 8/14/19 10:07 AM, Weijun Wang wrote: >>>>> The difference will be big. I've simplified the logic into >>>>> 1. read bytes between first ": " and \r\n as alias >>>>> 2. read bytes between first \r\n after first "-" and next "-" as a cert >>>>> 3. goto 1 >>>>> And I only store the cert bytes and do not create a Certificate until getCertificate() is read. I even haven't de-BASE64 them. >>>>> Time spent is still ~2.5x of JKS (when reading from a ByteArrayInputStream). >>>>> I guess the major reason is that there is no length field for the cert, so we must read-and-check all the time. >>>> >>>> Could you store the length as an attribute, perhaps? >>> >>> I'm reluctant to do that. This means people cannot edit the file with a text editor and have to use keytool to manage it. >>> >>> Of course, this file is still PEM and can be used by other tools, just that they should not try to modify it. >>> >>> I'll see if there are other ways to improve the performance. One way I'm thinking about is to read the first few bytes of a cert to find out the length (It's always also 30 82 AB CD...). >>> >>> Thanks, >>> Max >>> >>>> >>>> --Sean >>>> >>>>> --Max >>>>>> On Aug 14, 2019, at 9:31 PM, Sean Mullan wrote: >>>>>> >>>>>> On 8/13/19 10:19 PM, Weijun Wang wrote: >>>>>>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>>>>>> see wether your parser doesn't choke on it. >>>>>>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. >>>>>> >>>>>> This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 >>>>>> >>>>>> I would not want to see a regression in performance. >>>>>> >>>>>> --Sean >>> From weijun.wang at oracle.com Thu Aug 29 08:04:20 2019 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 29 Aug 2019 16:04:20 +0800 Subject: [14] RFR 8162628: Migrate cacerts keystore from JKS In-Reply-To: References: <3DA11EB1-FC4D-45B6-855B-68973AB47176@oracle.com> <70e44439-3b2a-a457-af76-62bcb4f98467@gmx.net> <4FAB734A-6E45-45E5-95C0-62B14F731983@oracle.com> <7a312042-1e56-ed0c-5204-891f07992e62@oracle.com> <9367A39F-2863-48D5-BE4A-7995187A8973@oracle.com> Message-ID: Updated webrev at https://cr.openjdk.java.net/~weijun/8162628/webrev.01/. The only change is using CertificateFactory. I tried piped streams and it's even slower. --Max > On Aug 29, 2019, at 8:21 AM, Weijun Wang wrote: > > > >> On Aug 28, 2019, at 11:00 PM, Sean Mullan wrote: >> >> On 8/27/19 9:18 AM, Weijun Wang wrote: >>> Oops, sorry. I was calling "new X509CertImp" in PEM keystore and this has not made use of the cache in X509Factory, and since my benchmark test loads keystores hundreds of times it's certainly much slower than JKS. >>> I've disabled the cache and now PEM is only around 20% slower than JKS. I'm sure some optimization will make it even smaller. >> >> Do you have an updated webrev? > > No. I tried some code changes but there is no performance enhancement. > > --Max > >> >> --Sean >> >>> --Max >>>> On Aug 22, 2019, at 11:47 PM, Weijun Wang wrote: >>>> >>>> >>>> >>>>> On Aug 22, 2019, at 10:40 PM, Sean Mullan wrote: >>>>> >>>>> On 8/14/19 10:07 AM, Weijun Wang wrote: >>>>>> The difference will be big. I've simplified the logic into >>>>>> 1. read bytes between first ": " and \r\n as alias >>>>>> 2. read bytes between first \r\n after first "-" and next "-" as a cert >>>>>> 3. goto 1 >>>>>> And I only store the cert bytes and do not create a Certificate until getCertificate() is read. I even haven't de-BASE64 them. >>>>>> Time spent is still ~2.5x of JKS (when reading from a ByteArrayInputStream). >>>>>> I guess the major reason is that there is no length field for the cert, so we must read-and-check all the time. >>>>> >>>>> Could you store the length as an attribute, perhaps? >>>> >>>> I'm reluctant to do that. This means people cannot edit the file with a text editor and have to use keytool to manage it. >>>> >>>> Of course, this file is still PEM and can be used by other tools, just that they should not try to modify it. >>>> >>>> I'll see if there are other ways to improve the performance. One way I'm thinking about is to read the first few bytes of a cert to find out the length (It's always also 30 82 AB CD...). >>>> >>>> Thanks, >>>> Max >>>> >>>>> >>>>> --Sean >>>>> >>>>>> --Max >>>>>>> On Aug 14, 2019, at 9:31 PM, Sean Mullan wrote: >>>>>>> >>>>>>> On 8/13/19 10:19 PM, Weijun Wang wrote: >>>>>>>>> I will also pass a pretty large cacerts with public CA and our CAs and >>>>>>>>> see wether your parser doesn't choke on it. >>>>>>>> PEM is certainly slower than JKS because of text reading and de-Base64. I'll see if I can make any enhancement. >>>>>>> >>>>>>> This is a bit of a concern for me. In the past, reading cacerts has been a bit of a bottleneck and we have made some improvements over the years such as: https://bugs.openjdk.java.net/browse/JDK-8129988 >>>>>>> >>>>>>> I would not want to see a regression in performance. >>>>>>> >>>>>>> --Sean >>>> > From sean.mullan at oracle.com Thu Aug 29 13:18:29 2019 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 29 Aug 2019 09:18:29 -0400 Subject: JDK 14 RFR of JDK-8229999 : Apply java.io.Serial annotations to security types in java.base In-Reply-To: References: Message-ID: Looks fine to me although I didn't check if you missed anything. What kind of documentation changes can we expect by using this annotation? --Sean On 8/27/19 8:16 PM, Joe Darcy wrote: > Hello, > > Recent work for JDK-8202385: "Annotation to mark serial-related fields > and methods" added the java.io.Serial annotation type to the platform. > The intention of this new annotation type is to allow > serialization-related fields and methods to be marked as documentation > and to allow stricter compile-time checking, analogous to the checking > done for @Override. Implementing those stricter serialization-related > checks will be done under JDK-8202056. > > Please review the application of java.io.Serial to the security-related > types in the base module: > > ??? JDK-8229999 : Apply java.io.Serial annotations to security types in > java.base > ??? http://cr.openjdk.java.net/~darcy/8229999.0/ > > As a reminder, the 5 serialization-related methods and 2 fields are: > > ??? * private void writeObject(java.io.ObjectOutputStream stream) > throws IOException > ??? * private void readObject(java.io.ObjectInputStream stream) throws > IOException, ClassNotFoundException > ??? * private void readObjectNoData() throws ObjectStreamException > ??? * ANY-ACCESS-MODIFIER Object writeReplace() throws > ObjectStreamException > ??? * ANY-ACCESS-MODIFIER Object readResolve() throws > ObjectStreamException > ??? * private static final ObjectStreamField[] serialPersistentFields > ??? * private static final long serialVersionUID > > Thanks, > > -Joe > From joe.darcy at oracle.com Thu Aug 29 16:28:30 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 29 Aug 2019 09:28:30 -0700 Subject: JDK 14 RFR of JDK-8229999 : Apply java.io.Serial annotations to security types in java.base In-Reply-To: References: Message-ID: <44fb8ecf-902d-7d89-4e2c-2a0132823fa7@oracle.com> Hi Sean, On 8/29/2019 6:18 AM, Sean Mullan wrote: > Looks fine to me although I didn't check if you missed anything. > > What kind of documentation changes can we expect by using this > annotation? The documentation changes are just when reading the sources, the annotation type itself is not @Documented so it doesn't appear in the generated javadoc. Thanks, -Joe > > --Sean > > On 8/27/19 8:16 PM, Joe Darcy wrote: >> Hello, >> >> Recent work for JDK-8202385: "Annotation to mark serial-related >> fields and methods" added the java.io.Serial annotation type to the >> platform. The intention of this new annotation type is to allow >> serialization-related fields and methods to be marked as >> documentation and to allow stricter compile-time checking, analogous >> to the checking done for @Override. Implementing those stricter >> serialization-related checks will be done under JDK-8202056. >> >> Please review the application of java.io.Serial to the >> security-related types in the base module: >> >> ???? JDK-8229999 : Apply java.io.Serial annotations to security types >> in java.base >> ???? http://cr.openjdk.java.net/~darcy/8229999.0/ >> >> As a reminder, the 5 serialization-related methods and 2 fields are: >> >> ???? * private void writeObject(java.io.ObjectOutputStream stream) >> throws IOException >> ???? * private void readObject(java.io.ObjectInputStream stream) >> throws IOException, ClassNotFoundException >> ???? * private void readObjectNoData() throws ObjectStreamException >> ???? * ANY-ACCESS-MODIFIER Object writeReplace() throws >> ObjectStreamException >> ???? * ANY-ACCESS-MODIFIER Object readResolve() throws >> ObjectStreamException >> ???? * private static final ObjectStreamField[] serialPersistentFields >> ???? * private static final long serialVersionUID >> >> Thanks, >> >> -Joe >> From ivan.gerasimov at oracle.com Fri Aug 30 23:32:51 2019 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 30 Aug 2019 16:32:51 -0700 Subject: RFR (XS) 8230415 : Avoid redundant permission checking in FilePermissionCollection and SocketPermissionCollection Message-ID: <7bf465d9-c5c0-c886-5aec-32ce79017b04@oracle.com> Hello! In the two implementations of PermissionCollection.implies(Permission), all the permissions are traversed, and their corresponding bit mask are checked. For example, here's a snippet from FilePermission.java: ??????? int desired = fperm.getMask(); ??????? int effective = 0; ??????? int needed = desired; ??????? for (Permission perm : perms.values()) { ??????????? FilePermission fp = (FilePermission)perm; ??????????? if (((needed & fp.getMask()) != 0) && fp.impliesIgnoreMask(fperm)) { ??????????????? effective |= fp.getMask(); ??????????????? if ((effective & desired) == desired) { ??????????????????? return true; ??????????????? } ??????????????? needed = (desired ^ effective);// <<< should be (desired & ~effective) ??????????? } ??????? } Here, if a permission's mask `fp.getMask()` intersects with `needed`, but does not fully cover all the needed bits, the variable `needed` is updated as XOR of desired and effective. This can raise a not-really-needed bits in the `needed` mask, so that for all subsequent permissions from the collection with that unneeded bits in the mask, an expensive fp.impliesIgnoreMask(fperm) will be executed. The fix does not change the behavior, but helps avoid unnecessary calls to impliesIgnoreMask(). Would you please help review a trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8230415 WEBREV: http://cr.openjdk.java.net/~igerasim/8230415/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From vtewar26 at in.ibm.com Wed Aug 21 06:01:47 2019 From: vtewar26 at in.ibm.com (Vyom Tewari26) Date: Wed, 21 Aug 2019 06:01:47 -0000 Subject: RFR 8211360 : Change #if DEF to #if defined(DEF) In-Reply-To: <0d38c07a-e697-49c6-dfc0-938a8ffa7820@oracle.com> References: <0d38c07a-e697-49c6-dfc0-938a8ffa7820@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: