From anders.rundgren.net at gmail.com Tue Sep 1 02:00:12 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Tue, 1 Sep 2020 04:00:12 +0200 Subject: Missing documentation for EdDSA key serialization In-Reply-To: References: Message-ID: Hi Anthony and Mike, It is not reversing that is the problem but assumption that you know that: - Reversing is required. - XOdd should always(?) be set to false. EdECPoint is presumably targeting other applications which are closer to the EdDSA core than PKIX and JOSE. The serialization of EdDSA public keys to RFC 8032 compatible representation is currently is performed by this "experimentally derived" code: byte[] rawKey = edEcPoint.getY().toByteArray(); while (rawKey.length < ANTICIPATED_LENGTH) { prepend rawKey with a zero byte } if (edEcPoint.isXOdd()) { rewKey[0] |= 0x80; } rawKey = reverse(rawKey); This is obviously not something you want to have in a professional solution so unfortunately the SubjectPublicKeyInfo route seems to be the only credible way ahead: https://github.com/cyberphone/openkeystore/blob/427f65df6eb26e9150a1aefd6f0abf3abe761e91/library/src/org/webpki/crypto/CryptoUtil.java#L59 Thanx, Anders On 2020-08-31 20:38, Michael StJohns wrote: > On 8/31/2020 2:00 PM, Anthony Scarpino wrote: >> On 8/31/20 8:16 AM, Anders Rundgren wrote: >>> On >>> https://tools.ietf.org/html/rfc8032#page-24 >>> you can find test vectors that are also used by rfc8037 (JOSE). >>> >>> However, there seems to be no information on how to create an EdDSA >>> public key from such a vector. >>> Apparently you must be an expert on the inner workings of EdDSA in >>> order to use this API. >>> >>> I have though managed(...) but 1) it looks strange 2) it may be >>> incorrect. >>> >>> Steps >>> 1. Convert the hex-code to a byte[] array. >>> 2. Reverse (!) all the bytes in the byte[] array. >>> 3. publicKey = kf.generatePublic( >>> ???????????????????? new EdECPublicKeySpec(new NamedParameterSpec(alg), >>> ?????????????????????????????????????????? new EdECPoint(false, new >>> BigInteger(1, theByteArray)))); >>> >>> Ideally, EdECPoint should have an constructor that does whatever it >>> takes based on a byte[] array. >>> >>> It is equally fuzzy in the other direction.? A "getByteArray()" on >>> EdECPoint had been great. >>> >>> Thanx, >>> Anders >> >> Hi, >> >> It does seem like a constructor and/or helper methods would be a good >> addition.? I filed a bug to track this: >> >> https://bugs.openjdk.java.net/browse/JDK-8252595 >> >> thanks >> >> Tony > > > Generically, maybe this should be added not to the ED based stuff, but > to BigInteger: > > public static BigInteger fromLittleEndianEncoding(int signum, byte[] > magnitude); > > public? byte[] getMagnitude(boolean bigEndian, int sizeInBytes); // if > size in bytes < actual magnitude size, returns the magnitude bytes, > otherwise returns the magnitude bytes left or right padded to > sizeInBytes depending on endianness. > > Almost all of the crypto stuff related to converting between the various > encodings of signatures and keys would benefit from a standard version > of the left/right padding stuff. > > Mike > > ps - there's a long thread maybe a year or two ago about internal vs > external representations of the EDDSA and EDDH keys.? I'm actually kind > of surprised that the internal representation turned out to be > BigInteger.?? I'm glad it did, but its now kind of strange that we have > 6 extra interface classes when we could probably have gotten away with > folding them in under the EC* classes. > > > pps - the alternate way of doing this (and probably the most correct > way) would be to encode the bytes from the test vector into a > SubjectPublicKeyInfo public key (see RFC8401)? and run that through the > key factory.? That should do all the reversing and generating.? You can > confirm that by doing a getEncoded() on your built public key and > running it back through the key factory. > > > From eric.c.liu at arm.com Tue Sep 1 08:01:22 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Tue, 1 Sep 2020 08:01:22 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: Hi all, Please review this simple change to fix some compile warnings. The newer gcc (gcc-8 or higher) would warn for calls to bounded string manipulation functions such as 'strncpy' that may either truncate the copied string or leave the destination unchanged. This patch fixed stringop-truncation warnings reported by gcc, some of them only appear when compiled with "--enable-asan". [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8252407 Thanks, Eric From daniel.fuchs at oracle.com Tue Sep 1 09:18:26 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Sep 2020 10:18:26 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: <3cab30a7-0b1e-15ef-9237-4083fe271a4c@oracle.com> Hi Eric, The changes to NetworkInterface.c look good to me. best regards, -- daniel On 01/09/2020 09:01, Eric Liu wrote: > Hi all, > > Please review this simple change to fix some compile warnings. > > The newer gcc (gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destination unchanged. > > This patch fixed stringop-truncation warnings reported by gcc, some of > them only appear when compiled with "--enable-asan". > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8252407 > > Thanks, > Eric > From daniel.fuchs at oracle.com Tue Sep 1 11:59:17 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Sep 2020 12:59:17 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: Hi Eric, Kim, On 01/09/2020 10:46, Kim Barrett wrote: > he changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. Thanks for reminding me of these changes. Indeed, the changes proposed to NetworkInteface.c - though not incorrect - may well re-trigger this gcc10 warning [1]. So now I don't think this should go through unless it's verified that it doesn't cause further issues down the road. [1] https://bugs.openjdk.java.net/browse/JDK-8250863 best regards, -- daniel From eric.c.liu at arm.com Tue Sep 1 13:59:32 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Tue, 1 Sep 2020 13:59:32 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com>, Message-ID: Hi Daniel, Kim, Thanks for your review. > Kim Barrett on Tue Sep 1 09:46:26 UTC 2020 > > Changes look good, subject to that caveat. I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. I just tested this patch by GCC (10.1.0) and it would really re-trigger those warnings :( I have not noticed the history before, but it's really hard to imagine that GCC would have different behaviors. >Daniel Fuchs on Tue Sep 1 11:59:17 UTC 2020 > > Thanks for reminding me of these changes. > Indeed, the changes proposed to NetworkInteface.c - though > not incorrect - may well re-trigger this gcc10 warning [1]. > So now I don't think this should go through unless it's verified > that it doesn't cause further issues down the road. Do you think it's a good idea to suppress those warnings by pragma? As we already know the code are actually correct, and that would make GCC happy both for 9 and 10. Thanks, Eric From kim.barrett at oracle.com Tue Sep 1 09:46:26 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 05:46:26 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> > On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: > > Hi all, > > Please review this simple change to fix some compile warnings. > > The newer gcc (gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destination unchanged. > > This patch fixed stringop-truncation warnings reported by gcc, some of > them only appear when compiled with "--enable-asan". > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8252407 > > Thanks, > Eric I really hate -Wstringop-truncation. It's been a constant source of churn for us ever since it appeared. The changes being made to getIndex and getFlags (NetworkInterface.c) are modifying lines that were changed very recently to deal with such warnings from gcc10. I'm worried that these new changes will re-trigger warnings from gcc10 (though this change isn't a revert; the gcc10 warning was justifiable). I think it should be okay, but there?s some risk here. Changes look good, subject to that caveat. I think these changes conform better to the documented description of the warning than did the recent NetworkInterface.c change mentioned above, so I?m hopeful that we?re not in a warning cycle here. But it would be good to have someone test these changes against gcc10.x. From kim.barrett at oracle.com Tue Sep 1 09:53:28 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 05:53:28 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <444A171B-076F-402C-A601-2C66203A1DE0@oracle.com> > On Sep 1, 2020, at 5:46 AM, Kim Barrett wrote: > >> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: >> >> Hi all, >> >> Please review this simple change to fix some compile warnings. >> >> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >> manipulation functions such as 'strncpy' that may either truncate the >> copied string or leave the destination unchanged. >> >> This patch fixed stringop-truncation warnings reported by gcc, some of >> them only appear when compiled with "--enable-asan". >> >> [TESTS] >> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >> No new failure found. >> >> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8252407 >> >> Thanks, >> Eric > > I really hate -Wstringop-truncation. It's been a constant source of churn > for us ever since it appeared. The changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. > > Changes look good, subject to that caveat. Apparently I forgot about the discussion of the casted enum, so belay that. > I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. From magnus.ihse.bursie at oracle.com Wed Sep 2 06:39:47 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Sep 2020 08:39:47 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> On 2020-09-01 11:46, Kim Barrett wrote: >> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: >> >> Hi all, >> >> Please review this simple change to fix some compile warnings. >> >> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >> manipulation functions such as 'strncpy' that may either truncate the >> copied string or leave the destination unchanged. >> >> This patch fixed stringop-truncation warnings reported by gcc, some of >> them only appear when compiled with "--enable-asan". >> >> [TESTS] >> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >> No new failure found. >> >> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8252407 >> >> Thanks, >> Eric > I really hate -Wstringop-truncation. It's been a constant source of churn > for us ever since it appeared. The changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the? case with the original C library functions; hence all this warning churning). There have been other problem areas before, where a common library (static or dynamic) would have helped. Perhaps it's time to go ahead and create one... /Magnus > > Changes look good, subject to that caveat. I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. > > From fweimer at redhat.com Wed Sep 2 07:19:52 2020 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 02 Sep 2020 09:19:52 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> (Magnus Ihse Bursie's message of "Wed, 2 Sep 2020 08:39:47 +0200") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> * Magnus Ihse Bursie: > Maybe we should have a common library for all native code where we > supply our own string operation functions? It will then be much easier > to make sure the implementation passes different compiler versions, > and that we provide sane semantics (which isn't really the? case with > the original C library functions; hence all this warning churning). When I looked at this (sorry that I never sent a patch), pretty much all uses of strncpy were actually bugs: The code should check the actual string length using strlen, report an error if it would be truncated, and then use memcpy with the length already computed, plus one. In other words, the strncpy warnings are correct, and there is only churn in the sense that GCC gets smarter at discovering bugs. At least one of the bugs was in theory user-visible: the network interface code would return data for an interface that does not actually exist on the system. Thanks, Florian From daniel.fuchs at oracle.com Wed Sep 2 09:26:29 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Sep 2020 10:26:29 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: Hi, On 02/09/2020 08:19, Florian Weimer wrote: > At least one of the bugs was in theory user-visible: the network > interface code would return data for an interface that does not actually > exist on the system. WRT NetworkInterface.c, I might support using `strnlen` to check the length before hand, if that solves both cases (gcc8 and gcc10). I'm always a bit nervous of changing the behavior in this library as it's hard to verify that no regression is introduced. best regards, -- daniel From magnus.ihse.bursie at oracle.com Wed Sep 2 10:31:53 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Sep 2020 12:31:53 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: On 2020-09-02 09:50, Kim Barrett wrote: >> On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie wrote: >> >> On 2020-09-01 11:46, Kim Barrett wrote: >>> I really hate -Wstringop-truncation. It's been a constant source of churn >>> for us ever since it appeared. The changes being made to getIndex and >>> getFlags (NetworkInterface.c) are modifying lines that were changed very >>> recently to deal with such warnings from gcc10. I'm worried that these new >>> changes will re-trigger warnings from gcc10 (though this change isn't a >>> revert; the gcc10 warning was justifiable). I think it should be okay, but >>> there?s some risk here. >> Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the case with the original C library functions; hence all this warning churning). > For the recurring problems with strncpy, there?s already this: > https://bugs.openjdk.java.net/browse/JDK-8232187 > Nobody?s picked it up yet. Yes, but that's hotspot only. The other JDK libraries would not be able to use it. (And as I said, there are other, already existing functions, that ideally should be shared between hotspot and the rest of the libraries). /Magnus > From kim.barrett at oracle.com Wed Sep 2 07:50:38 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Sep 2020 03:50:38 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: > On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie wrote: > > On 2020-09-01 11:46, Kim Barrett wrote: >> I really hate -Wstringop-truncation. It's been a constant source of churn >> for us ever since it appeared. The changes being made to getIndex and >> getFlags (NetworkInterface.c) are modifying lines that were changed very >> recently to deal with such warnings from gcc10. I'm worried that these new >> changes will re-trigger warnings from gcc10 (though this change isn't a >> revert; the gcc10 warning was justifiable). I think it should be okay, but >> there?s some risk here. > Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the case with the original C library functions; hence all this warning churning). For the recurring problems with strncpy, there?s already this: https://bugs.openjdk.java.net/browse/JDK-8232187 Nobody?s picked it up yet. From kim.barrett at oracle.com Wed Sep 2 07:56:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Sep 2020 03:56:06 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: <89A572A7-E2EE-4A26-A907-C5D59FDBDFCA@oracle.com> > On Sep 2, 2020, at 3:19 AM, Florian Weimer wrote: > > * Magnus Ihse Bursie: > >> Maybe we should have a common library for all native code where we >> supply our own string operation functions? It will then be much easier >> to make sure the implementation passes different compiler versions, >> and that we provide sane semantics (which isn't really the case with >> the original C library functions; hence all this warning churning). > > When I looked at this (sorry that I never sent a patch), pretty much all > uses of strncpy were actually bugs: The code should check the actual > string length using strlen, report an error if it would be truncated, > and then use memcpy with the length already computed, plus one. > > In other words, the strncpy warnings are correct, and there is only > churn in the sense that GCC gets smarter at discovering bugs. Having been involved in reviews of a lot of these warnings, I think that?s seriously overstating the cases where there have been actual bugs. There have been some actual bugs found, but there have been a lot of definite false positives. Particularly from -Wstringop-truncation. From anders.rundgren.net at gmail.com Thu Sep 3 08:49:37 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Thu, 3 Sep 2020 10:49:37 +0200 Subject: JDK's XECPublicKey.getEncoded() deviates from RFC8410 Message-ID: Being an early adopter has its challenges... https://github.com/cyberphone/openkeystore/blob/master/library/test/org/webpki/crypto/Jdk15XdhSerializationBug.java ? This test program verifies that JDK 11 - JDK 15 according to section 3 of ? RFC 8410 incorrectly add an ASN.1 "NULL" to the AlgorithmIdentifier of ? XDH public keys.? See line 9: below. ?? 0: SEQUENCE ??????? { ?? 2:???? SEQUENCE ??????????? { ?? 4:???????? OBJECT IDENTIFIER X25519 (1.3.101.110) ?? 9:???????? NULL ??????????? } ? 11:???? BIT STRING, 32 bytes ????? 0000: 2f 97 25 02 da af 6b dc 0e e6 67 39 25 f2 f0 fe '/.%...k...g9%...' ????? 0010: 03 b0 24 09 3c f0 fc ef 3c 23 12 46 3d 5c 8e 15 '..$.<...<#.F=\..' ??????? } This is not a showstopper since BC remains a compliant alternative. However, for EcDSA and EXH, BC and JDK are incompatible at the java source level. If this is accepted as a bug, I hope you will also revisit the (compared to EdDSA keys), unnecessarily quirky use of AlgorithmParameterSpec. Thanx, Anders From WEIJUN.WANG at ORACLE.COM Thu Sep 3 11:56:52 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Thu, 3 Sep 2020 07:56:52 -0400 Subject: JDK's XECPublicKey.getEncoded() deviates from RFC8410 In-Reply-To: References: Message-ID: Because of some very old incompatibility issue, we put a NULL there for most algorithms: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/AlgorithmId.java#L176 We are revisiting this decision now at https://bugs.openjdk.java.net/browse/JDK-8252377. Thanks for pointing this out. ?Max > On Sep 3, 2020, at 4:49 AM, Anders Rundgren wrote: > > Being an early adopter has its challenges... > https://github.com/cyberphone/openkeystore/blob/master/library/test/org/webpki/crypto/Jdk15XdhSerializationBug.java > > This test program verifies that JDK 11 - JDK 15 according to section 3 of > RFC 8410 incorrectly add an ASN.1 "NULL" to the AlgorithmIdentifier of > XDH public keys. See line 9: below. > 0: SEQUENCE > { > 2: SEQUENCE > { > 4: OBJECT IDENTIFIER X25519 (1.3.101.110) > 9: NULL > } > 11: BIT STRING, 32 bytes > 0000: 2f 97 25 02 da af 6b dc 0e e6 67 39 25 f2 f0 fe '/.%...k...g9%...' > 0010: 03 b0 24 09 3c f0 fc ef 3c 23 12 46 3d 5c 8e 15 '..$.<...<#.F=\..' > } > > > This is not a showstopper since BC remains a compliant alternative. However, for EcDSA and EXH, BC and JDK are incompatible at the java source level. > If this is accepted as a bug, I hope you will also revisit the (compared to EdDSA keys), unnecessarily quirky use of AlgorithmParameterSpec. > > Thanx, > Anders From fweimer at redhat.com Fri Sep 4 11:50:55 2020 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 04 Sep 2020 13:50:55 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: (Daniel Fuchs's message of "Wed, 2 Sep 2020 10:26:29 +0100") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: <87sgbxhiao.fsf@oldenburg2.str.redhat.com> * Daniel Fuchs: > Hi, > > On 02/09/2020 08:19, Florian Weimer wrote: >> At least one of the bugs was in theory user-visible: the network >> interface code would return data for an interface that does not actually >> exist on the system. > > WRT NetworkInterface.c, I might support using `strnlen` to check > the length before hand, if that solves both cases (gcc8 and gcc10). > I'm always a bit nervous of changing the behavior in this library > as it's hard to verify that no regression is introduced. I think you should use strlen. If the string is longer than the buffer sent to the kernel, it cannot match an existing interface because all the names are shorter. So some sort of ?not found? error needs to reported. (I assume that it's actually a bug that you can look up a network interface by a name that merely shares the same prefix with an actual interface on the system.) Thanks, Florian From fweimer at redhat.com Sun Sep 6 17:03:55 2020 From: fweimer at redhat.com (Florian Weimer) Date: Sun, 06 Sep 2020 19:03:55 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> (Kim Barrett's message of "Sun, 6 Sep 2020 07:30:09 -0400") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> Message-ID: <87sgbuet1g.fsf@oldenburg2.str.redhat.com> * Kim Barrett: >> On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote: >> >> * Daniel Fuchs: >> >>> Hi, >>> >>> On 02/09/2020 08:19, Florian Weimer wrote: >>>> At least one of the bugs was in theory user-visible: the network >>>> interface code would return data for an interface that does not actually >>>> exist on the system. >>> >>> WRT NetworkInterface.c, I might support using `strnlen` to check >>> the length before hand, if that solves both cases (gcc8 and gcc10). >>> I'm always a bit nervous of changing the behavior in this library >>> as it's hard to verify that no regression is introduced. >> >> I think you should use strlen. If the string is longer than the buffer >> sent to the kernel, it cannot match an existing interface because all >> the names are shorter. So some sort of ?not found? error needs to >> reported. > > That may be, but I think doing so probably won't do anything to > address the -Wstringop-truncation warnings. There is no reason to use strncpy. At least on Linux, the struct field needs to be null-terminated, and you need to compute the length for the length check. So you might as well use memcpy with the length plus one (to copy the null terminator). You can keep using strncpy, and the warning should be gone (because GCC will recognize a dominating strlen check), but it's not necessary. On current GNU/Linux, the most common structs now have the appropriate annotations, so you get the strncpy warnings only in cases where there is an actual truncation bug. Thanks, Florian From sean.coffey at oracle.com Sun Sep 6 19:43:33 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Sun, 6 Sep 2020 20:43:33 +0100 Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <8946D5E0-8438-43EC-A987-4FEBF5779343@oracle.com> References: <957b3bd1-254a-647d-358b-e2dbfba6c6cf@oracle.com> <68CBFB5B-0CAD-44DE-B0E8-92221BACE7C9@ORACLE.COM> <99b55d3f-533e-ac91-89bd-1ce8f3cbd6db@oracle.com> <940A8A93-BB70-48CD-B1DE-0E9EC17E2791@ORACLE.COM> <3b9c3aa9-df9b-5ae3-2301-2e08c8e9f769@oracle.com> <1582051D-5EDD-4F16-88D3-A064683023D3@ORACLE.COM> <8946D5E0-8438-43EC-A987-4FEBF5779343@oracle.com> Message-ID: <1b02d2f3-3491-03cb-b4ac-b90e1b3d1bb9@oracle.com> Thanks for the review Hai-May. I've implemented all your suggestions. The CSR was approved late on Friday so I'll now submit this via PR on github infra. regards, Sean. On 28/08/2020 21:08, Hai-May Chao wrote: > JarSigner.java #953: The output debug message can be removed from the > code. > JavaUtilZipFileAccess.java #44: Change posixPerms to extraAttrs. > ZipFile.java #661: Suggest to keep the comment and update it with the > additional 4 bits for symlink. > > The rest of code changes and CSR look good. > > Thanks, > Hai-May > > >> On Aug 28, 2020, at 7:17 AM, Se?n Coffey > > wrote: >> >> I've been poking around the zip internals and am now able to locate >> the 16 bits of interest. The position of these actual bits does >> appear to move around from one test run to another. For now, I guess >> it's sufficient to look for the pattern of interest in the signed zip >> file. New testcase added. >> >> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/ >> >> regards, >> Sean. >> >> On 27/08/2020 15:58, Weijun Wang wrote: >>>> Looks like it was a conscious design decision to only allow recording of POSIX permission bits for this field (& 0xFFF). I don't see anything about symlink support in zipfs docs. >>> As long as that*byte* is there and it?s not difficult to locate, we can manually add the*bit* for symlink and see if jarsigner can keep it. >>> >>> ?Max >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fweimer at redhat.com Mon Sep 7 09:55:28 2020 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 07 Sep 2020 11:55:28 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> (Kim Barrett's message of "Sun, 6 Sep 2020 22:19:05 -0400") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> Message-ID: <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> * Kim Barrett: > And strlen is not even necessarily the best solution, as it likely > introduces an additional otherwise unnecessary string traversal. For > example, getFlags could be changed to reject an overly long ifname, > without using strlen, thusly: > > strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); > if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { > return -1; > } > > Unfortunately, gcc10 -Wstringop-truncation whines about this entirely > reasonable code. Thanks, I filed this as: Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From coffeys at openjdk.java.net Mon Sep 7 13:58:10 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 7 Sep 2020 13:58:10 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files Message-ID: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html CSR has been approved. ------------- Commit messages: - JDK-8250968 Changes: https://git.openjdk.java.net/jdk/pull/56/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=56&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250968 Stats: 198 lines in 10 files changed: 162 ins; 1 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk/pull/56 From eric.c.liu at arm.com Mon Sep 7 14:56:53 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Mon, 7 Sep 2020 14:56:53 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , Message-ID: Hi Kim: Thanks for the discussion, this makes more sense to me now. > Kim Barrett on 06 September 2020 19:35 wrote: > > Can you be (very) specific about this.? Do all of these changes cause gcc10 to warn?? Or > do only some of them.? If only some, specifically which ones??I have a conjecture about > some of them (see below).? (I should probably try this myself; I know we have done some > testing with gcc10, but I don?t remember where to find that devkit.) I have tested 4 cases for those warnings: a) Without my patch, without asan, gcc-8 and gcc-10 are OK. b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. c) With my patch, without asan, gcc-8 and gcc-10 are OK. d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without asan, no warning would be found even through some of them doesn't align with the documentation. > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c >?232???? strncpy(searchName, name_utf, IFNAMESIZE - 1); > > A better solution here would be to eliminate the strncpy entirely. > > The strncpy is used to make a copy of a string so the copy can be > searched for a colon, and if one is found, terminate the string there. > > But there's no need to make such a copy.? The string being copied is > the local temporary string name_utf.? We could instead use name_utf > everywhere searchName is currently used, including clobbering the > first colon to NUL.? We'd have to undo that before the later loop at > line 249, but we have the information needed to do so. Yes, this copy seems unnecessary. I was thinking whether it's a good way to find parent by using strstr, so that we can not have to recover the zero. Will that be much slower? > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c > 1298???? memset((char *)&if2, 0, sizeof(if2)); > 1299???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); > 1300???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > (in getIndex) > > So gcc8 does not warn about this, but gcc10 does? That would be a > regression in gcc10 (and should be reported as such), because the > documentation for -Wstringop-truncate is clear that the above is the > proper idiom for avoiding the warning. Yse, I followed the documentation and gcc-8 does not warn about this, but gcc-10 does (both with asan enabled). > Regardless, the memset on 1298 is useless.? The code from before > JDK-8250863 was the memset then the strncpy with > sizeof(if2.ifr_name)-1 as the bound, which worked because the memset > would have zeroed the last element. > > The change for JDK-8250863 did not follow the documented idiom though. > > It would be interesting to find out if removal of the memset changes > anything.? It's barely conceivable that it's confusing the heuristics > used to decide whether -Wstringop-truncation should trigger.? For > example, the compiler might decide that the subsequent assignment of > the last element is unnecessary because of the memset and optimize the > assignment away, removing the idiomatic warning suppression. > > If gcc10 still warns about the above after removing the memset then I > see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. > > Similarly for the strncpy in getFlags: > 1362???? memset((char *)&if2, 0, sizeof(if2)); > 1363???? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); > 1364???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c > ?937???? strncpy(name, if_name, IFNAMESIZE - 1); > ?938???? name[IFNAMESIZE - 1] = '\0'; > > gcc10 presumably did not complain about the old version here, and this > was not touched as part of JDK-8250863.? Does gcc10 complain about > this new version?? If so, then I see little recoarse but to use > PRAGMA_STRINGOP_TRUNCATION_IGNORED here, because a gcc10 warning here > is contrary to the documentation. Yes, gcc-10 would warn about this both before and after my patch if asan enabled. > ------------------------------------------------------------------------------ > src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > est/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp > > These changes look good, as they follow the documented idiom for > suppressing -Wstringop-truncation. Does gcc10 warn after these changes? Gcc-10 does'n warn about this changes. > ------------------------------------------------------------------------------ > test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c > (In Java_UnixDomainSocket_bind0)? > 234???? memset(&addr, 0, sizeof(addr)); > 235???? addr.sun_family = AF_UNIX; > 236???? strncpy(addr.sun_path, nameUtf, length - 1); > 237???? addr.sun_path[length - 1] = '\0'; > > (In Java_UnixDomainSocket_connect0) > 267???? memset(&addr, 0, sizeof(addr)); > 268???? addr.sun_family = AF_UNIX; > 269???? strncpy(addr.sun_path, nameUtf, length - 1); > 270???? addr.sun_path[length - 1] = '\0'; > > These changes look good, as they follow the documented idiom for > suppressing -Wstringop-truncation. > > Does gcc10 warn after these changes? Gcc-10 doesn't warn about these changes. I'm working on a new patch that to make both gcc-8 and gcc-10 happy. Thanks, Eric From lancea at openjdk.java.net Mon Sep 7 16:43:58 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Sep 2020 16:43:58 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote: > Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. I think this looks good over all Sean. In your SymLinkTest, I probably would have the test delete the file if it exists prior to writing to it. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/56 From weijun at openjdk.java.net Mon Sep 7 16:49:19 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 7 Sep 2020 16:49:19 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote: > Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/56 From github.com+471021+marschall at openjdk.java.net Mon Sep 7 17:08:40 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 7 Sep 2020 17:08:40 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package Message-ID: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Hello, newbie here I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. - I tried to update the copyright year to 2020 in every file. - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. - All tier1 tests pass. - One jpackage/jlink tier2 test fails but I don't believe it is related. - Some tier3 Swing tests fail but I don't think they are related. ------------- Commit messages: - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8138732 Stats: 747 lines in 63 files changed: 149 ins; 148 del; 450 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From alanb at openjdk.java.net Mon Sep 7 17:53:50 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 7 Sep 2020 17:53:50 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. This one probably needs discussion on hotspot-dev to get agreement on the rename/move. It might need coordination with Graal. If the change does go ahead then please check if java.base's module-info.java still needs to export jdk.internal to jdk.jfr, I suspect that qualified export can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From coffeys at openjdk.java.net Mon Sep 7 18:57:11 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 7 Sep 2020 18:57:11 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files [v2] In-Reply-To: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: > Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Copyright and test clean up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/56/files - new: https://git.openjdk.java.net/jdk/pull/56/files/2f656ce0..27cb91f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=56&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=56&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/56.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/56/head:pull/56 PR: https://git.openjdk.java.net/jdk/pull/56 From coffeys at openjdk.java.net Mon Sep 7 19:04:08 2020 From: coffeys at openjdk.java.net (Sean Coffey) Date: Mon, 7 Sep 2020 19:04:08 GMT Subject: Integrated: 8250968: Symlinks attributes not preserved when using jarsigner on zip files In-Reply-To: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote: > Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html > > CSR has been approved. This pull request has now been integrated. Changeset: 7686e871 Author: Sean Coffey URL: https://git.openjdk.java.net/jdk/commit/7686e871 Stats: 200 lines in 10 files changed: 1 ins; 162 del; 37 mod 8250968: Symlinks attributes not preserved when using jarsigner on zip files Reviewed-by: lancea, weijun, hchao ------------- PR: https://git.openjdk.java.net/jdk/pull/56 From lancea at openjdk.java.net Mon Sep 7 19:04:07 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Sep 2020 19:04:07 GMT Subject: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files [v2] In-Reply-To: References: <_t_7x4rXraIGRyqbC_M-Q1bfBlU0e97bE5Uw97ylAkE=.a4f7c6ef-8230-4379-a29d-941d854e257b@github.com> Message-ID: On Mon, 7 Sep 2020 18:57:11 GMT, Sean Coffey wrote: >> Continuation of RFR thread from http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html >> >> CSR has been approved. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Copyright and test clean up Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/56 From kim.barrett at oracle.com Sun Sep 6 11:30:09 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 07:30:09 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87sgbxhiao.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> Message-ID: <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> > On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote: > > * Daniel Fuchs: > >> Hi, >> >> On 02/09/2020 08:19, Florian Weimer wrote: >>> At least one of the bugs was in theory user-visible: the network >>> interface code would return data for an interface that does not actually >>> exist on the system. >> >> WRT NetworkInterface.c, I might support using `strnlen` to check >> the length before hand, if that solves both cases (gcc8 and gcc10). >> I'm always a bit nervous of changing the behavior in this library >> as it's hard to verify that no regression is introduced. > > I think you should use strlen. If the string is longer than the buffer > sent to the kernel, it cannot match an existing interface because all > the names are shorter. So some sort of ?not found? error needs to > reported. That may be, but I think doing so probably won't do anything to address the -Wstringop-truncation warnings. > (I assume that it's actually a bug that you can look up a network > interface by a name that merely shares the same prefix with an actual > interface on the system.) > > Thanks, > Florian From kim.barrett at oracle.com Sun Sep 6 11:35:40 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 07:35:40 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: > On Sep 1, 2020, at 9:59 AM, Eric Liu wrote: > I just tested this patch by GCC (10.1.0) and it would really re-trigger those warnings :( > I have not noticed the history before, but it's really hard to imagine that GCC would > have different behaviors. Can you be (very) specific about this. Do all of these changes cause gcc10 to warn? Or do only some of them. If only some, specifically which ones? I have a conjecture about some of them (see below). (I should probably try this myself; I know we have done some testing with gcc10, but I don?t remember where to find that devkit.) ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 232 strncpy(searchName, name_utf, IFNAMESIZE - 1); A better solution here would be to eliminate the strncpy entirely. The strncpy is used to make a copy of a string so the copy can be searched for a colon, and if one is found, terminate the string there. But there's no need to make such a copy. The string being copied is the local temporary string name_utf. We could instead use name_utf everywhere searchName is currently used, including clobbering the first colon to NUL. We'd have to undo that before the later loop at line 249, but we have the information needed to do so. ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 1298 memset((char *)&if2, 0, sizeof(if2)); 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; (in getIndex) So gcc8 does not warn about this, but gcc10 does? That would be a regression in gcc10 (and should be reported as such), because the documentation for -Wstringop-truncate is clear that the above is the proper idiom for avoiding the warning. Regardless, the memset on 1298 is useless. The code from before JDK-8250863 was the memset then the strncpy with sizeof(if2.ifr_name)-1 as the bound, which worked because the memset would have zeroed the last element. The change for JDK-8250863 did not follow the documented idiom though. It would be interesting to find out if removal of the memset changes anything. It's barely conceivable that it's confusing the heuristics used to decide whether -Wstringop-truncation should trigger. For example, the compiler might decide that the subsequent assignment of the last element is unnecessary because of the memset and optimize the assignment away, removing the idiomatic warning suppression. If gcc10 still warns about the above after removing the memset then I see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. Similarly for the strncpy in getFlags: 1362 memset((char *)&if2, 0, sizeof(if2)); 1363 strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); 1364 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 937 strncpy(name, if_name, IFNAMESIZE - 1); 938 name[IFNAMESIZE - 1] = '\0'; gcc10 presumably did not complain about the old version here, and this was not touched as part of JDK-8250863. Does gcc10 complain about this new version? If so, then I see little recoarse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here, because a gcc10 warning here is contrary to the documentation. ------------------------------------------------------------------------------ src/hotspot/share/compiler/compileBroker.hpp 64 PRAGMA_DIAG_PUSH 65 PRAGMA_STRINGOP_TRUNCATION_IGNORED 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc 67 strncpy(_current_method, method, (size_t)cmname_buffer_length-1); 68 PRAGMA_DIAG_POP 69 _current_method[cmname_buffer_length-1] = '\0'; I think I'd prefer the PRAGMA_DIAG_POP moved one line further down, so that the push/pop surrounds the entire idiomactic usage that is supposed to prevent the warning. This seems to be a gcc8 bug. gcc10 doesn't warn about this (and shouldn't). It would be interesting to know if it too warns with --enable-asan. ------------------------------------------------------------------------------ src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c est/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp These changes look good, as they follow the documented idiom for suppressing -Wstringop-truncation. Does gcc10 warn after these changes? ------------------------------------------------------------------------------ test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c (In Java_UnixDomainSocket_bind0) 234 memset(&addr, 0, sizeof(addr)); 235 addr.sun_family = AF_UNIX; 236 strncpy(addr.sun_path, nameUtf, length - 1); 237 addr.sun_path[length - 1] = '\0'; (In Java_UnixDomainSocket_connect0) 267 memset(&addr, 0, sizeof(addr)); 268 addr.sun_family = AF_UNIX; 269 strncpy(addr.sun_path, nameUtf, length - 1); 270 addr.sun_path[length - 1] = '\0'; These changes look good, as they follow the documented idiom for suppressing -Wstringop-truncation. Does gcc10 warn after these changes? Per the discussion above about getIndex in NetworkInterface.c, does removing the memsets change that? The memsets seem entirely unnecessary, since we're filling in all (both) members. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Mon Sep 7 01:49:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 21:49:48 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <63FFE48F-03C1-4F2E-9ECE-8C3303C6AF8F@oracle.com> > On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote: > src/hotspot/share/compiler/compileBroker.hpp > 64 PRAGMA_DIAG_PUSH > 65 PRAGMA_STRINGOP_TRUNCATION_IGNORED > 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc > 67 strncpy(_current_method, method, (size_t)cmname_buffer_length-1); > 68 PRAGMA_DIAG_POP > 69 _current_method[cmname_buffer_length-1] = '\0'; > > I think I'd prefer the PRAGMA_DIAG_POP moved one line further down, so > that the push/pop surrounds the entire idiomactic usage that is > supposed to prevent the warning. This seems to be a gcc8 bug. > > gcc10 doesn't warn about this (and shouldn't). It would be > interesting to know if it too warns with --enable-asan. I keep forgetting. This is the one where we think the cast on line 67 might be confusing gcc8, and if it were eliminated we might not need the PRAGMA dance here after all. From kim.barrett at oracle.com Mon Sep 7 01:51:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 21:51:06 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> > On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote: > src/java.base/unix/native/libnet/NetworkInterface.c > 1298 memset((char *)&if2, 0, sizeof(if2)); > 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); > 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > (in getIndex) > > So gcc8 does not warn about this, but gcc10 does? That would be a > regression in gcc10 (and should be reported as such), because the > documentation for -Wstringop-truncate is clear that the above is the > proper idiom for avoiding the warning. > > Regardless, the memset on 1298 is useless. The code from before > JDK-8250863 was the memset then the strncpy with > sizeof(if2.ifr_name)-1 as the bound, which worked because the memset > would have zeroed the last element. > > The change for JDK-8250863 did not follow the documented idiom though. > > It would be interesting to find out if removal of the memset changes > anything. It's barely conceivable that it's confusing the heuristics > used to decide whether -Wstringop-truncation should trigger. For > example, the compiler might decide that the subsequent assignment of > the last element is unnecessary because of the memset and optimize the > assignment away, removing the idiomatic warning suppression. > > If gcc10 still warns about the above after removing the memset then I > see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. I found a gcc10.2 devkit that I could take for a spin with Eric's patches. I got -Wstringop-truncation warnings in NetworkInterface.c, in getIndex and getFlags. Removing the immediately preceeding memset removed those warnings. (Note that in these two cases the memset is otherwise completely superfluous, both before and after Eric's changes.) Strangely, there are other places in this file where a strncpy is preceeded by a memcpy and there is no assignment of the last element to NUL, but which no version of gcc seems to complain about. Examples include getMacAddress, getMTU, enumIPv6Interfaces. Oh, good grief! This file contains 3 identical copies of getMTU and getFlags, one each for linux, AIX, and BSD. And getIndex is kind of a mess. If changing any of these for linux, probably similar changes ought to be applied to the other copies to keep things in sync. After removing the superfluous memsets from getIndex and getFlags, my test build with gcc10.2 completed successfully with Eric's patches. From kim.barrett at oracle.com Mon Sep 7 02:19:05 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 22:19:05 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87sgbuet1g.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> Message-ID: <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> > On Sep 6, 2020, at 1:03 PM, Florian Weimer wrote: > There is no reason to use strncpy. At least on Linux, the struct field > needs to be null-terminated, and you need to compute the length for the > length check. So you might as well use memcpy with the length plus one > (to copy the null terminator). You can keep using strncpy, and the > warning should be gone (because GCC will recognize a dominating strlen > check), but it's not necessary. > > On current GNU/Linux, the most common structs now have the appropriate > annotations, so you get the strncpy warnings only in cases where there > is an actual truncation bug. [Keep in mind that gcc on recent GNU/Linux is not the only platform this code base needs to worry about. Though it is the one that is driving us a bit batty with its varying warnings here.] I'm not sure whether you are suggesting one should never use strncpy anywhere, or whether there is some specific place(s) from this webrev you are suggesting it should be avoided? I agree there are some uses of strncpy that look at least somewhat suspect. Without further analysis it's hard to know whether there is really a problem with truncation (can it occur at all, and is it a problem if it does). Figuring that out seems somewhat beyond the scope of what this change is trying to do. Please file bugs about problematic uses. (A bug of the form "don't use strncpy" might not get quick action.) And strlen is not even necessarily the best solution, as it likely introduces an additional otherwise unnecessary string traversal. For example, getFlags could be changed to reject an overly long ifname, without using strlen, thusly: strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { return -1; } Unfortunately, gcc10 -Wstringop-truncation whines about this entirely reasonable code. From kim.barrett at oracle.com Mon Sep 7 02:36:33 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 22:36:33 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> Message-ID: > On Sep 6, 2020, at 9:51 PM, Kim Barrett wrote: > Oh, good grief! This file contains 3 identical copies of getMTU and > getFlags, one each for linux, AIX, and BSD. And getIndex is kind of a > mess. If changing any of these for linux, probably similar changes > ought to be applied to the other copies to keep things in sync. Is there any reason the linux version of getIndex couldn?t be changed to use if_nametoindex (like the AIX version)? That would eliminate one of the cases that is causing problems. From david.holmes at oracle.com Tue Sep 8 01:11:09 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 11:11:09 +1000 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <369201b2-087d-44c5-d020-26c239d172aa@oracle.com> Hi Philippe, On 8/09/2020 3:08 am, Philippe Marschall wrote: > Hello, newbie here Welcome aboard! > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. That's somewhat debatable, but I don't think @since really serves any useful purpose on non-public APIs, so I'm fine either way. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. The changes all look good to me. Thanks, David ----- > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. > > ------------- > > Commit messages: > - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Changes: https://git.openjdk.java.net/jdk/pull/45/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8138732 > Stats: 747 lines in 63 files changed: 149 ins; 148 del; 450 mod > Patch: https://git.openjdk.java.net/jdk/pull/45.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 > > PR: https://git.openjdk.java.net/jdk/pull/45 > From dholmes at openjdk.java.net Tue Sep 8 01:13:41 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Sep 2020 01:13:41 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <7422UelQpc0A_Q-YQ_TIQ-ihtR0d-7lTmQVaG2o0owg=.fea1ee30-463d-44e2-b63a-26b6baa2559b@github.com> On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. The changes all look good to me. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/45 From kim.barrett at oracle.com Tue Sep 8 12:28:21 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 08:28:21 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> > On Sep 7, 2020, at 10:56 AM, Eric Liu wrote: > I have tested 4 cases for those warnings: > a) Without my patch, without asan, gcc-8 and gcc-10 are OK. > b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. > c) With my patch, without asan, gcc-8 and gcc-10 are OK. That?s *very* strange, since I get warnings in NetworkInterface getIndex and getFlags with gcc10.2 + your patch. > d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. > > Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without > asan, no warning would be found even through some of them doesn't align with the documentation. >> src/java.base/unix/native/libnet/NetworkInterface.c >> 1298 memset((char *)&if2, 0, sizeof(if2)); >> 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); >> 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >> >> (in getIndex) >> >> So gcc8 does not warn about this, but gcc10 does? That would be a >> regression in gcc10 (and should be reported as such), because the >> documentation for -Wstringop-truncate is clear that the above is the >> proper idiom for avoiding the warning. > > Yse, I followed the documentation and gcc-8 does not warn about this, but > gcc-10 does (both with asan enabled). > >> Regardless, the memset on 1298 is useless. The code from before >> JDK-8250863 was the memset then the strncpy with >> sizeof(if2.ifr_name)-1 as the bound, which worked because the memset >> would have zeroed the last element. >> >> The change for JDK-8250863 did not follow the documented idiom though. >> >> It would be interesting to find out if removal of the memset changes >> anything. It's barely conceivable that it's confusing the heuristics >> used to decide whether -Wstringop-truncation should trigger. For >> example, the compiler might decide that the subsequent assignment of >> the last element is unnecessary because of the memset and optimize the >> assignment away, removing the idiomatic warning suppression. >> >> If gcc10 still warns about the above after removing the memset then I >> see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. >> >> Similarly for the strncpy in getFlags: >> 1362 memset((char *)&if2, 0, sizeof(if2)); >> 1363 strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); >> 1364 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. I?m confused. Above you said that with your patch + asan gcc-8 did not warn. Maybe what you are saying is that *just* removing the memset, and not applying your patch, for this case with asan warns with all of gcc-8,9,10? > I'm working on a new patch that to make both gcc-8 and gcc-10 happy. Good luck! I think I?m coming around to Florian?s ?never use strncpy? position, not so much because it?s the wrong function to use (though sometimes it probably is, or is being used wrongly), but because fighting with -Wstringop-truncation is just not worth the aggravation. From kim.barrett at oracle.com Tue Sep 8 12:29:42 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 08:29:42 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> Message-ID: <089F94C7-4126-4D7C-A3E9-33373B960D7F@oracle.com> > On Sep 7, 2020, at 5:55 AM, Florian Weimer wrote: > > * Kim Barrett: > >> And strlen is not even necessarily the best solution, as it likely >> introduces an additional otherwise unnecessary string traversal. For >> example, getFlags could be changed to reject an overly long ifname, >> without using strlen, thusly: >> >> strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); >> if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { >> return -1; >> } >> >> Unfortunately, gcc10 -Wstringop-truncation whines about this entirely >> reasonable code. > > Thanks, I filed this as: Thanks. Though it looks like the response is just ?don?t use strncpy?. From iklam at openjdk.java.net Tue Sep 8 16:28:49 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Sep 2020 16:28:49 GMT Subject: RFR: 8244778: Archive full module graph in CDS Message-ID: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> This is the same patch as [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) published in [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html). The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. ------------- Commit messages: - fixed trailing spaces - Renamed ModuleEntry::write_growable_array - Update to latest repo (JDK-8251557); added comments - 8244778: Archive full module graph in CDS Changes: https://git.openjdk.java.net/jdk/pull/80/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244778 Stats: 2039 lines in 59 files changed: 1887 ins; 26 del; 126 mod Patch: https://git.openjdk.java.net/jdk/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/80/head:pull/80 PR: https://git.openjdk.java.net/jdk/pull/80 From iklam at openjdk.java.net Tue Sep 8 16:45:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Sep 2020 16:45:41 GMT Subject: RFR: 8244778: Archive full module graph in CDS In-Reply-To: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote: > This is the same patch as > [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) > published in > [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html). > The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. In response to Lois Foltain's comments on [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041616.html): > Minor nit in moduleEntry.cpp & packageEntry.cpp when dealing with the ModuleEntry's reads list and a PackageEntry's > exports list. The names of the methods to write and read those arrays is somewhat confusing. > > ModuleEntry::write_archived_entry_array > ModuleEntry::read_archived_entry_array > > At first I thought you were reading/writing an array of archived entries, not the array within an archived entry > itself. I was trying to think of a better name. Please consider adding a comment at line #400 & line #417 ahead of > those methods in moduleEntry.cpp to indicate that they are used for both reading/writing a ModuleEntry's reads list and > a PackageEntry's exports list. I renamed the functions to `ModuleEntry's::write_growable_array` and `ModuleEntry::restore_growable_array`, and added comments as you suggested. See commit [4f90e77](https://github.com/openjdk/jdk/pull/80/commits/4f90e77207de5fc7cf09a12fb89b75087be57225) // This function is used to archive ModuleEntry::_reads and PackageEntry::_qualified_exports. // GrowableArray cannot be directly archived, as it needs to be expandable at runtime. // Write it out as an Array, and convert it back to GrowableArray at runtime. Array* ModuleEntry::write_growable_array(GrowableArray* array) { > A question about this because a user's program can define modules post module initialization via > ModuleDescriptor.newModule(). See for example, tests within open/test/hotspot/jtreg/runtime/module/AccessCheck. So > all of these tests would trigger check_cds_restrictions() if -Xshare:dump was turned on. Is that a concern? Arbitrary user code cannot be executed during -Xshare:dump. The only way to do it is to use a JVMTI agent, which requires specifying `-XX:+AllowArchivingWithJavaAgent`. You can see an example in the [GCDuringDump.java](https://github.com/openjdk/jdk/blob/704f784c88ee282837c980948167e741e7227f27/test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCDuringDump.java#L65) test. If the agent tries to define an extra module, it will get an `UnsupportedOperationException` thrown by `check_cds_restrictions()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From anthony.scarpino at oracle.com Tue Sep 8 17:29:35 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 8 Sep 2020 10:29:35 -0700 Subject: getParams() for XECKey returns nonsense In-Reply-To: <43d2efdb-d82c-3008-f1b9-56c621bc22fc@gmail.com> References: <43d2efdb-d82c-3008-f1b9-56c621bc22fc@gmail.com> Message-ID: On 8/30/20 9:51 AM, Anders Rundgren wrote: > Hi, > This applies to JDK 11. > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces/XECKey.html > > what is the value of "AlgorithmParameterSpec"? > > In JDK 15 the new EdECKey has gotten a more logical solution: > https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/security/interfaces/EdECKey.html > > > thanx, > Anders > > > The return type for XECKey.getParams() was trying to be more generic, probably too generic. NamedParameterSpec implements AlgorithParameterSpec. The implementationf or XECKey returns a NamedParameterSpec. Tony From anders.rundgren.net at gmail.com Tue Sep 8 18:42:13 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Tue, 8 Sep 2020 20:42:13 +0200 Subject: getParams() for XECKey returns nonsense In-Reply-To: References: <43d2efdb-d82c-3008-f1b9-56c621bc22fc@gmail.com> Message-ID: <2db8f81c-8593-5f03-d16c-b71610e4b7e4@gmail.com> On 2020-09-08 19:29, Anthony Scarpino wrote: > On 8/30/20 9:51 AM, Anders Rundgren wrote: >> Hi, >> This applies to JDK 11. >> >> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces/XECKey.html >> >> what is the value of "AlgorithmParameterSpec"? >> >> In JDK 15 the new EdECKey has gotten a more logical solution: >> https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/security/interfaces/EdECKey.html >> >> >> thanx, >> Anders >> >> >> > > The return type for XECKey.getParams() was trying to be more generic, probably too generic. I guessed that. Don't you have the same problem with EdECKey? > NamedParameterSpec implements AlgorithParameterSpec. Right, this is clear by looking at the API. > The implementationf or XECKey returns a NamedParameterSpec. Here is gets a bit slippery (at least compared to the solution for EdECKey) because this is 1) Undocumented 2) Oracle-provider-specific, both which pretty much nullifies the value of the public interface. I may (surely) be wrong but changing the API to return NamedParameterSpec should not break any existing code based on the Oracle provider. Thanx, Anders > > Tony > From anthony.scarpino at oracle.com Tue Sep 8 20:05:39 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 8 Sep 2020 13:05:39 -0700 Subject: getParams() for XECKey returns nonsense In-Reply-To: <2db8f81c-8593-5f03-d16c-b71610e4b7e4@gmail.com> References: <43d2efdb-d82c-3008-f1b9-56c621bc22fc@gmail.com> <2db8f81c-8593-5f03-d16c-b71610e4b7e4@gmail.com> Message-ID: <3bcfae79-b3e9-d5d8-bd5b-e5238ad78e15@oracle.com> On 9/8/20 11:42 AM, Anders Rundgren wrote: > On 2020-09-08 19:29, Anthony Scarpino wrote: >> On 8/30/20 9:51 AM, Anders Rundgren wrote: >>> Hi, >>> This applies to JDK 11. >>> >>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces/XECKey.html >>> >>> >>> what is the value of "AlgorithmParameterSpec"? >>> >>> In JDK 15 the new EdECKey has gotten a more logical solution: >>> https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/security/interfaces/EdECKey.html__;!!GqivPVa7Brio!M6lIhNj1Si4NHI4Q9JggmTsJyTybhNLe9w7uQWg8WhivilAk6ALuc5-5pefjwY68yM9W$ >>> >>> >>> thanx, >>> Anders >>> >>> >>> >> >> The return type for XECKey.getParams() was trying to be more generic, >> probably too generic. > > I guessed that.? Don't you have the same problem with EdECKey? Different opinions as the APIs were developed several years apart > > >> NamedParameterSpec implements AlgorithParameterSpec. > > Right, this is clear by looking at the API. > > >> The implementationf or XECKey returns a NamedParameterSpec. > > Here is gets a bit slippery (at least compared to the solution for > EdECKey) because this is 1) Undocumented 2) Oracle-provider-specific, > both which pretty much nullifies the value of the public interface. The intention at the time was if in the future XEC required different an AlgorithmParameterSpec that it would not have to inherit NamedParameterSpec. With EdDSA, we decided that was unnecessary. The implementation returning NamedParameterSpec does not nullify the public interface. I was stating XECKey's return type in the context of the differences between EdECKey and XECKey and that it is consistent in the end. When using XECKey.getParams(), checking the instanceof maybe a good idea. I would say the API allows for more flexibility for non-oracle providers by returning AlgorithmParameterSpec. As far as being undocumented, that maybe true in other documentation, but the API should not be specifying what SunEC is returning. > > I may (surely) be wrong but changing the API to return > NamedParameterSpec should not break any existing code based on the > Oracle provider. Once the API is published, we cannot change it. Tony > > Thanx, > Anders > >> >> Tony >> > From anders.rundgren.net at gmail.com Wed Sep 9 05:16:51 2020 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Wed, 9 Sep 2020 07:16:51 +0200 Subject: getParams() for XECKey returns nonsense In-Reply-To: <3bcfae79-b3e9-d5d8-bd5b-e5238ad78e15@oracle.com> References: <43d2efdb-d82c-3008-f1b9-56c621bc22fc@gmail.com> <2db8f81c-8593-5f03-d16c-b71610e4b7e4@gmail.com> <3bcfae79-b3e9-d5d8-bd5b-e5238ad78e15@oracle.com> Message-ID: On 2020-09-08 22:05, Anthony Scarpino wrote: > On 9/8/20 11:42 AM, Anders Rundgren wrote: >> On 2020-09-08 19:29, Anthony Scarpino wrote: >>> On 8/30/20 9:51 AM, Anders Rundgren wrote: >>>> Hi, >>>> This applies to JDK 11. >>>> >>>> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/security/interfaces/XECKey.html >>>> >>>> >>>> what is the value of "AlgorithmParameterSpec"? >>>> >>>> In JDK 15 the new EdECKey has gotten a more logical solution: >>>> https://urldefense.com/v3/__https://download.java.net/java/early_access/jdk15/docs/api/java.base/java/security/interfaces/EdECKey.html__;!!GqivPVa7Brio!M6lIhNj1Si4NHI4Q9JggmTsJyTybhNLe9w7uQWg8WhivilAk6ALuc5-5pefjwY68yM9W$ >>>> >>>> >>>> thanx, >>>> Anders >>>> >>>> >>>> >>> >>> The return type for XECKey.getParams() was trying to be more generic, >>> probably too generic. >> >> I guessed that.? Don't you have the same problem with EdECKey? > > Different opinions as the APIs were developed several years apart > >> >> >>> NamedParameterSpec implements AlgorithParameterSpec. >> >> Right, this is clear by looking at the API. >> >> >>> The implementationf or XECKey returns a NamedParameterSpec. >> >> Here is gets a bit slippery (at least compared to the solution for >> EdECKey) because this is 1) Undocumented 2) Oracle-provider-specific, >> both which pretty much nullifies the value of the public interface. > > The intention at the time was if in the future XEC required different an > AlgorithmParameterSpec that it would not have to inherit > NamedParameterSpec. With EdDSA, we decided that was unnecessary. > > The implementation returning NamedParameterSpec does not nullify the > public interface. I was stating XECKey's return type in the context of > the differences between EdECKey and XECKey and that it is consistent in > the end. When using XECKey.getParams(), checking the instanceof maybe a > good idea. I would say the API allows for more flexibility for > non-oracle providers by returning AlgorithmParameterSpec. As far as > being undocumented, that maybe true in other documentation, but the API > should not be specifying what SunEC is returning. I don't understand how developers of libraries for things like the JOSE stack are supposed to deal with a public API that doesn't provide the exact type of the key. For public keys you can do your own ASN.1 parsing but for private keys there is no workaround if the key is in protected storage. Effectively you are requiring that each provider vendor publish their AlgorithmParameterSpec implementation which then library developers must know and implement specific support for! >> I may (surely) be wrong but changing the API to return >> NamedParameterSpec should not break any existing code based on the >> Oracle provider. > > Once the API is published, we cannot change it. In this case I think you can because the majority of people wanting to use curve25519 and curve448 algorithms needed signatures as well and have therefore turned to other solutions like Bouncycastle using proprietary interfaces and APIs. In the unlikely case we need new key variants based on the same core, creating a new set of key interfaces would create much less fuzz since new types won't work automatically anyway due to the complex relation between key algorithms and JCE providers. I leave it there but in my book this a design bug. Fortunately (for us all...), I expect third parties targeting the JDK interfaces will follow Oracle's implementation which then become the de-facto API :-) thanx, Anders > > Tony > >> >> Thanx, >> Anders >> >>> >>> Tony >>> >> > From eric.c.liu at arm.com Wed Sep 9 06:06:51 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 9 Sep 2020 06:06:51 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> Message-ID: Hi Kim, > Kim Barrett on Sent: 08 September 2020 20:28 ? >> On Sep 7, 2020, at 10:56 AM, Eric Liu wrote: >> I have tested 4 cases for those warnings: >> a) Without my patch, without asan, gcc-8 and gcc-10 are OK. >> b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. >> c) With my patch, without asan, gcc-8 and gcc-10 are OK. > That?s *very* strange, since I get warnings in NetworkInterface getIndex and getFlags > with gcc10.2 + your patch. Sorry for the mistake, gcc-10 exactly warn?about my patch. >> d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. >> >> Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without >> asan, no warning would be found even through some of them doesn't align with the documentation. >>> src/java.base/unix/native/libnet/NetworkInterface.c >>> 1298???? memset((char *)&if2, 0, sizeof(if2)); >>> 1299???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); >>> 1300???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >>> >>> (in getIndex) >>> >>> So gcc8 does not warn about this, but gcc10 does? That would be a >>> regression in gcc10 (and should be reported as such), because the >>> documentation for -Wstringop-truncate is clear that the above is the >>> proper idiom for avoiding the warning. >> >> Yse, I followed the documentation and gcc-8 does not warn about this, but >> gcc-10 does (both with asan enabled). >> >>> Regardless, the memset on 1298 is useless.? The code from before >>> JDK-8250863 was the memset then the strncpy with >>> sizeof(if2.ifr_name)-1 as the bound, which worked because the memset >>> would have zeroed the last element. >>> >>> The change for JDK-8250863 did not follow the documented idiom though. >>> >>> It would be interesting to find out if removal of the memset changes >>> anything.? It's barely conceivable that it's confusing the heuristics >>> used to decide whether -Wstringop-truncation should trigger.? For >>> example, the compiler might decide that the subsequent assignment of >>> the last element is unnecessary because of the memset and optimize the >>> assignment away, removing the idiomatic warning suppression. >>> >>> If gcc10 still warns about the above after removing the memset then I >>> see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. >>> >>> Similarly for the strncpy in getFlags: >>> 1362???? memset((char *)&if2, 0, sizeof(if2)); >>> 1363???? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); >>> 1364???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >> >> After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. > I?m confused.? Above you said that with your patch + asan gcc-8 did not warn. > Maybe what you are saying is that *just* removing the memset, and not applying > your patch, for this case with asan warns with all of gcc-8,9,10? Sorry for my bad expression. Actually removing memset could not make things better. My patch + asan would annoy gcc-10, removing memset changed nothing. For gcc-8 and gcc-9 part, without my patch they would warn about with asan, and removing memset can not fix them as well. Thanks, Eric From aph at redhat.com Wed Sep 9 08:49:46 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Sep 2020 09:49:46 +0100 Subject: Recent Java Sandbox escapes In-Reply-To: References: Message-ID: <328adfd8-cb73-ab05-64b9-0c344e23fa48@redhat.com> On 19/08/2020 22:46, Alkanor Oumbratok wrote: > > I may be wrong on both points, and I would be really grateful if > someone could explain why these 2 CVE have been rated this high > whereas at first glance there isn't any really exploitable related > scenario. The first rule of the OpenJDK Vulerability Group is: You do not talk about the OpenJDK Vulerability Group. :-) In particular, we do not reveal exploits. Sorry. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From github.com+471021+marschall at openjdk.java.net Wed Sep 9 09:49:44 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 9 Sep 2020 09:49:44 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/45/files - new: https://git.openjdk.java.net/jdk/pull/45/files/47328f4b..1c9dd9da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From sean.mullan at oracle.com Wed Sep 9 14:46:36 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Sep 2020 10:46:36 -0400 Subject: getParams() for XECKey returns nonsense In-Reply-To: References: <43d2efdb-d82c-3008-f1b9-56c621bc22fc@gmail.com> <2db8f81c-8593-5f03-d16c-b71610e4b7e4@gmail.com> <3bcfae79-b3e9-d5d8-bd5b-e5238ad78e15@oracle.com> Message-ID: <8526c5b9-b277-94a3-b544-541e314013a5@oracle.com> On 9/9/20 1:16 AM, Anders Rundgren wrote: > I may (surely) be wrong but changing the API to return > NamedParameterSpec should not break any existing code based on the > Oracle provider. Whether it continues to work when someone is using a specific provider is not relevant. This is a Java SE API, and must work independent of any particular implementation. It's an incompatible change. Code such as the following would break: AlgorithmParameterSpec params = XECKey.getParams(); The way to address this would be to add another method to XECKey that returns a NamedParameterSpec. We could consider this as an Enhancement request. --Sean From philippe.marschall at gmail.com Wed Sep 9 09:45:37 2020 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Wed, 9 Sep 2020 11:45:37 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, Sep 7, 2020 at 7:54 PM Alan Bateman wrote: > > On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > > > Hello, newbie here > > > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > > > - I tried to update the copyright year to 2020 in every file. > > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > > - All tier1 tests pass. > > - One jpackage/jlink tier2 test fails but I don't believe it is related. > > - Some tier3 Swing tests fail but I don't think they are related. > > This one probably needs discussion on hotspot-dev to get agreement on the rename/move. It might need coordination with > Graal. I sent out mails to hotspot-dev and graal-dev. > If the change does go ahead then please check if java.base's module-info.java still needs to export jdk.internal > to jdk.jfr, I suspect that qualified export can be removed. You're correct we can replace the jdk.internal export with the jdk.internal.vm.annotation export. I updated the PR accordingly. Cheers Philippe From valeriep at openjdk.java.net Thu Sep 10 02:06:43 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 10 Sep 2020 02:06:43 GMT Subject: RFR: 8172366: Support SHA-3 based signatures Message-ID: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Could someone please help review this RFE? Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will be updated separately (JDK-8242332). This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to various signature algorithms. Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 Thanks! Valerie ------------- Commit messages: - 8172366: Support SHA-3 based signatures Changes: https://git.openjdk.java.net/jdk/pull/102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8172366 Stats: 613 lines in 20 files changed: 541 ins; 8 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk/pull/102 From alanb at openjdk.java.net Thu Sep 10 06:58:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 06:58:57 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From github.com+2210496+thatsIch at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+2210496+thatsIch at openjdk.java.net (thatsIch) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). @doom369 jcheck requires an associated issue ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:21 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:21 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() Message-ID: **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). ------------- Commit messages: - Merge branch 'master' of https://github.com/doom369/jdk into reaplce_equals_with_is_empty - revert change in classes that maintain jdk 1.4 compatibility - Improvement: replace all occurrences of the .equals("") usages with .isEmpty() Changes: https://git.openjdk.java.net/jdk/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252999 Stats: 234 lines in 150 files changed: 0 ins; 0 del; 234 mod Patch: https://git.openjdk.java.net/jdk/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 08:52:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy wrote: >> @doom369 jcheck requires an associated issue > > @mrserb hello. Thanks for the review. Any further actions required from me? Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you should expect a longer review process, since someone from each functional area will need to look at the changes in their area (like @mrserb started to do for the `2d` area). ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 18:08:15 GMT, thatsIch wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > @doom369 jcheck requires an associated issue @mrserb hello. Thanks for the review. Any further actions required from me? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From serb at openjdk.java.net Thu Sep 10 08:52:29 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 08:52:29 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java line 187: > 185: String format = spi.getFormatNames()[0].toLowerCase(); > 186: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 187: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java line 146: > 144: String format = spi.getFormatNames()[0].toLowerCase(); > 145: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 146: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:26 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:26 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 20:21:44 GMT, Kevin Rushforth wrote: >> @mrserb hello. Thanks for the review. Any further actions required from me? > > Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a > Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement > request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once > you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing > "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you > should expect a longer review process, since someone from each functional area will need to look at the changes in > their area (like @mrserb started to do for the `2d` area). @kevinrushforth thanks. Done. Similar issues: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 could be joined somehow? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From alanb at openjdk.java.net Thu Sep 10 10:42:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 10:42:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy wrote: >> Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a >> Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement >> request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once >> you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing >> "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you >> should expect a longer review process, since someone from each functional area will need to look at the changes in >> their area (like @mrserb started to do for the `2d` area). > > @kevinrushforth thanks. Done. > > Similar issues: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 > > could be joined somehow? The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use JDK-8215014 rather than creating a new issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From dholmes at openjdk.java.net Thu Sep 10 11:24:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 11:24:10 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote: >> @kevinrushforth thanks. Done. >> >> Similar issues: >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 >> >> could be joined somehow? > > The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do > the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more > more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code > (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan > code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use > JDK-8215014 rather than creating a new issue. This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 12:07:57 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 12:07:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. I have in mind dozens of improvements all over the code like this one. I already did some further review and in most cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 12:21:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 12:21:25 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. Maybe @AlanBateman or @jddarcy can offer some advice? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From dholmes at openjdk.java.net Thu Sep 10 13:56:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 13:56:10 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote: >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests > each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. > Maybe @AlanBateman or @jddarcy can offer some advice? 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will be delayed due to all of the mails being held up for moderator approval due to: " Too many recipients to the message" I have a longer email coming once it gets through the moderator approval delay. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From alanb at openjdk.java.net Thu Sep 10 15:53:05 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 15:53:05 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote: >> @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests >> each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. >> Maybe @AlanBateman or @jddarcy can offer some advice? > > 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will > be delayed due to all of the mails being held up for moderator approval due to: > " Too many recipients to the message" > > I have a longer email coming once it gets through the moderator approval delay. :( Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should reduce the patch down to a manageable 24 or so files that should be trivial to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From xuelei at openjdk.java.net Thu Sep 10 16:32:46 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 10 Sep 2020 16:32:46 GMT Subject: RFR: 8172366: Support SHA-3 based signatures In-Reply-To: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: On Thu, 10 Sep 2020 01:58:09 GMT, Valerie Peng wrote: > Could someone please help review this RFE? > > Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will > be updated separately (JDK-8242332). > This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to > various signature algorithms. > Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 > > Thanks! > Valerie Do you want to list the "inP1363Format" SHA3 algorithms in the "Java Security Standard Algorithm Names" documentation in this CSR? ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From jvernee at openjdk.java.net Thu Sep 10 16:40:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Sep 2020 16:40:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> Message-ID: On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote: >> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will >> be delayed due to all of the mails being held up for moderator approval due to: >> " Too many recipients to the message" >> >> I have a longer email coming once it gets through the moderator approval delay. :( > > Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests > or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from > the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should > reduce the patch down to a manageable 24 or so files that should be trivial to review. Since one of the motivations for this change is micro benchmark performance, please add a benchmark to the JDKs micro benchmark suite as well. (see e.g. https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang). Also, what testing has been done for these changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From xuelei at openjdk.java.net Thu Sep 10 16:46:49 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 10 Sep 2020 16:46:49 GMT Subject: RFR: 8172366: Support SHA-3 based signatures In-Reply-To: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: On Thu, 10 Sep 2020 01:58:09 GMT, Valerie Peng wrote: > Could someone please help review this RFE? > > Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will > be updated separately (JDK-8242332). > This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to > various signature algorithms. > Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 > > Thanks! > Valerie src/java.base/share/classes/sun/security/provider/DSA.java line 56: > 54: * TLS among others. RawDSA expects the 20 byte SHA-1 digest as > 55: * input via update rather than the original data like other signature > 56: * implementations. As you were already there, do you want to mention the IEEE P1363 format in the class description? Maybe in the 1st paragraph in the class spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From xuelei at openjdk.java.net Thu Sep 10 17:22:36 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 10 Sep 2020 17:22:36 GMT Subject: RFR: 8172366: Support SHA-3 based signatures In-Reply-To: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: On Thu, 10 Sep 2020 01:58:09 GMT, Valerie Peng wrote: > Could someone please help review this RFE? > > Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will > be updated separately (JDK-8242332). > This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to > various signature algorithms. > Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 > > Thanks! > Valerie src/java.base/share/classes/sun/security/provider/DSA.java line 514: > 512: } > 513: } > 514: public static final class SHA3_224withDSAinP1363Format extends DSA { Missed the blank line. BTW, to be consistent with other styles, do you want to add class specs (/**-*/) for the new added classes? just like what you did for SHA512withDSAinP1363Format. src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 279: > 277: if (key != null) { > 278: try { > 279: int hLen = DIGEST_LENGTHS.get(KnownOIDs.findMatch(digestAlgo)); Is it possible the disgestAlgo unknown, and result in NullPointerException while casting null to int? I think it is safe to check the existence as you did in line 218-213. ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From psandoz at openjdk.java.net Thu Sep 10 18:02:26 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 10 Sep 2020 18:02:26 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From jjg at openjdk.java.net Thu Sep 10 23:31:29 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Sep 2020 23:31:29 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 12:04:48 GMT, Dmitriy Dumanskiy wrote: > I have in mind dozens of improvements all over the code like this one. That sounds scary. Broad updates like these cause unnecessary churn in the codebase, and can make merging and back porting harder. Changes should be discussed ahead of time with the appropriate teams. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From prr at openjdk.java.net Fri Sep 11 00:00:15 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 11 Sep 2020 00:00:15 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). 1) This is un-necessary churn. 2) I can't even be sure I am finding the ones in my area because there's so much here 3) The ones I can find have no need of whatever performance improvement this might bring. I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates you are making. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: Withdrawn: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 23:57:38 GMT, Phil Race wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > 1) This is un-necessary churn. > 2) I can't even be sure I am finding the ones in my area because there's so much here > 3) The ones I can find have no need of whatever performance improvement this might bring. > I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various > cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates > you are making. Ok, sorry for the distraction. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From wetmore at openjdk.java.net Fri Sep 11 15:20:36 2020 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 11 Sep 2020 15:20:36 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:15:26 GMT, Dmitriy Dumanskiy wrote: >> 1) This is un-necessary churn. >> 2) I can't even be sure I am finding the ones in my area because there's so much here >> 3) The ones I can find have no need of whatever performance improvement this might bring. >> I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various >> cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates >> you are making. > > Ok, sorry for the distraction. Our local Santuario maintainer says: In general, changes to Apache Santuario should also be made at Apache so we stay in sync. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From valeriep at openjdk.java.net Fri Sep 11 20:59:40 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 11 Sep 2020 20:59:40 GMT Subject: RFR: 8172366: Support SHA-3 based signatures In-Reply-To: References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: On Thu, 10 Sep 2020 16:29:01 GMT, Xue-Lei Andrew Fan wrote: > Do you want to list the "inP1363Format" SHA3 algorithms in the "Java Security Standard Algorithm Names" documentation > in this CSR? Yes, I will do that. Thanks~ ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From kvn at openjdk.java.net Fri Sep 11 21:57:54 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Sep 2020 21:57:54 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> Message-ID: On Thu, 10 Sep 2020 17:59:54 GMT, Paul Sandoz wrote: >> Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. > > Marked as reviewed by psandoz (Reviewer). You should consider upstreaming Graal changes (jdk.internal.vm.compiler) into https://github.com/oracle/graal Otherwise next time we do "Update Graal" in JDK they will be overwritten. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From kvn at openjdk.java.net Fri Sep 11 21:57:54 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Sep 2020 21:57:54 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> Message-ID: On Fri, 11 Sep 2020 21:53:12 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by psandoz (Reviewer). > > You should consider upstreaming Graal changes (jdk.internal.vm.compiler) into https://github.com/oracle/graal > Otherwise next time we do "Update Graal" in JDK they will be overwritten. Changes look good. I ran hs-tier1 and hs-tier3 test jobs which run Graal tests and they passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From kvn at openjdk.java.net Sat Sep 12 00:21:29 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 12 Sep 2020 00:21:29 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From jamil.j.nimeh at oracle.com Mon Sep 14 16:19:46 2020 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Mon, 14 Sep 2020 09:19:46 -0700 Subject: Notification: Certificate Transparency JEP (JDK-8171275) Message-ID: <4884741a-ef2a-436d-9f8c-eae6d760faff@oracle.com> Hello all, I wanted to let folks on the alias know that development of the Certificate Transparency feature for JSSE is now under way.? I've posted the JEP here: https://bugs.openjdk.java.net/browse/JDK-8171275 The design is in the early stages and there are a number of things that are TBD at this point.? Some of the big ones: * How the client will consume and store log information * How we deal with the thresholds for pass/fail validity checks on SCTs collected during the handshake * Assuming the server will support providing SCTs in the TLS extension, where it will consume and store the serialized SCTs. There are a few others.? At this point I've got the consumption of SCTs in the handshake by the client working for X.509 certs and TLS extensions and the OCSP stapling method is in progress. The JEP will be updated in the weeks to come as the open design elements are addressed. Thanks, --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Mon Sep 14 20:45:13 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 14 Sep 2020 20:45:13 GMT Subject: RFR: 8172366: Support SHA-3 based signatures In-Reply-To: References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: On Thu, 10 Sep 2020 16:44:13 GMT, Xue-Lei Andrew Fan wrote: >> Could someone please help review this RFE? >> >> Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will >> be updated separately (JDK-8242332). >> This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to >> various signature algorithms. >> Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 >> >> Thanks! >> Valerie > > src/java.base/share/classes/sun/security/provider/DSA.java line 56: > >> 54: * TLS among others. RawDSA expects the 20 byte SHA-1 digest as >> 55: * input via update rather than the original data like other signature >> 56: * implementations. > > As you were already there, do you want to mention the IEEE P1363 format in the class description? Maybe in the 1st > paragraph in the class spec. Ok~ ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From valeriep at openjdk.java.net Mon Sep 14 21:04:38 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 14 Sep 2020 21:04:38 GMT Subject: RFR: 8172366: Support SHA-3 based signatures In-Reply-To: References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: On Thu, 10 Sep 2020 16:46:52 GMT, Xue-Lei Andrew Fan wrote: >> Could someone please help review this RFE? >> >> Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will >> be updated separately (JDK-8242332). >> This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to >> various signature algorithms. >> Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 >> >> Thanks! >> Valerie > > src/java.base/share/classes/sun/security/provider/DSA.java line 514: > >> 512: } >> 513: } >> 514: public static final class SHA3_224withDSAinP1363Format extends DSA { > > Missed the blank line. > > BTW, to be consistent with other styles, do you want to add class specs (/**-*/) for the new added classes? just like > what you did for SHA512withDSAinP1363Format. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From valeriep at openjdk.java.net Mon Sep 14 21:26:13 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 14 Sep 2020 21:26:13 GMT Subject: RFR: 8172366: Support SHA-3 based signatures [v2] In-Reply-To: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: > Could someone please help review this RFE? > > Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will > be updated separately (JDK-8242332). > This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to > various signature algorithms. > Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 > > Thanks! > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update DSA.java Amended class javadoc with P1363 support and added javadoc for the new static classes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/102/files - new: https://git.openjdk.java.net/jdk/pull/102/files/1be073b2..01086f33 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=00-01 Stats: 39 lines in 1 file changed: 32 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk/pull/102 From valeriep at openjdk.java.net Mon Sep 14 22:41:55 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 14 Sep 2020 22:41:55 GMT Subject: RFR: 8172366: Support SHA-3 based signatures [v3] In-Reply-To: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: > Could someone please help review this RFE? > > Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will > be updated separately (JDK-8242332). > This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to > various signature algorithms. > Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 > > Thanks! > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update RSAPSSSignature.java Updated the KnownOIDs lookup code inside validateSigParams to check for unsupported digest algorithms. Changed checkKeyLength() to throw InvalidKeyException instead of SignatureException and adjusted caller code accordingly. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/102/files - new: https://git.openjdk.java.net/jdk/pull/102/files/01086f33..5a61f447 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=01-02 Stats: 50 lines in 1 file changed: 18 ins; 8 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk/pull/102 From valeriep at openjdk.java.net Tue Sep 15 01:34:56 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Sep 2020 01:34:56 GMT Subject: RFR: 8172366: Support SHA-3 based signatures [v4] In-Reply-To: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: > Could someone please help review this RFE? > > Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will > be updated separately (JDK-8242332). > This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to > various signature algorithms. > Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 > > Thanks! > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update DSA.java Removed the trailing white spaces in previous update. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/102/files - new: https://git.openjdk.java.net/jdk/pull/102/files/5a61f447..62fb5a39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk/pull/102 From xuelei at openjdk.java.net Tue Sep 15 01:42:34 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 15 Sep 2020 01:42:34 GMT Subject: RFR: 8172366: Support SHA-3 based signatures [v4] In-Reply-To: References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: <_XUn0lrSANAQzTbZtmBG0GWGxjh9JXVcOBPcBoaBns8=.a78ed2c8-a079-4c64-80fd-ad327b095955@github.com> On Tue, 15 Sep 2020 01:34:56 GMT, Valerie Peng wrote: >> Could someone please help review this RFE? >> >> Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will >> be updated separately (JDK-8242332). >> This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to >> various signature algorithms. >> Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 >> >> Thanks! >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update DSA.java > > Removed the trailing white spaces in previous update. Looks good to me, Looks good. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/102 From valeriep at openjdk.java.net Tue Sep 15 01:42:35 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Sep 2020 01:42:35 GMT Subject: RFR: 8172366: Support SHA-3 based signatures [v4] In-Reply-To: References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: <4KjCglNVHn73VJShVCaJGSTS6acD-eF3uffL-VFheIs=.c404490b-b721-4e31-b18e-f9901c98765e@github.com> On Thu, 10 Sep 2020 17:12:45 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update DSA.java >> >> Removed the trailing white spaces in previous update. > > src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java line 279: > >> 277: if (key != null) { >> 278: try { >> 279: int hLen = DIGEST_LENGTHS.get(KnownOIDs.findMatch(digestAlgo)); > > Is it possible the disgestAlgo unknown, and result in NullPointerException while casting null to int? I think it is > safe to check the existence as you did in line 218-213. Sure, will update. ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From mullan at openjdk.java.net Tue Sep 15 11:56:44 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 15 Sep 2020 11:56:44 GMT Subject: RFR: 8172366: Support SHA-3 based signatures [v4] In-Reply-To: References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: <9xmd19fjNxIwGgwsMxtxE1Fl_h4AF7t5n9OLVEHfjZ4=.19645352-fd29-4b4b-bc30-d422ff28ba10@github.com> On Tue, 15 Sep 2020 01:34:56 GMT, Valerie Peng wrote: >> Could someone please help review this RFE? >> >> Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will >> be updated separately (JDK-8242332). >> This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to >> various signature algorithms. >> Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 >> >> Thanks! >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update DSA.java > > Removed the trailing white spaces in previous update. The new constants in MGF1ParameterSpec.java should have "@since 16". ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From jpai at openjdk.java.net Tue Sep 15 15:05:36 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:05:36 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect Message-ID: Can I please get a review and a sponsor for this patch which fixes the issue reported in https://bugs.openjdk.java.net/browse/JDK-6714834? As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a mention that this can lead to incorrect manifest files ending up in jar files: > can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one > can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the `jdk:tier1` tests locally which hasn't shown any related failures. ------------- Commit messages: - 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect Changes: https://git.openjdk.java.net/jdk/pull/186/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=186&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-6714834 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/186.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/186/head:pull/186 PR: https://git.openjdk.java.net/jdk/pull/186 From alanb at openjdk.java.net Tue Sep 15 15:32:22 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Sep 2020 15:32:22 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 14:59:57 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for this patch which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-6714834? > As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally > calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it > on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a > `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable > when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a > mention that this can lead to incorrect manifest files ending up in jar files: >> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) > > I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But > my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's > created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store > these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract > and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't > see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in > this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the > nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the > `jdk:tier1` tests locally which hasn't shown any related failures. src/java.base/share/classes/java/util/jar/JarFile.java line 428: > 426: try (final InputStream is = super.getInputStream(manEntry)) { > 427: man = new Manifest(is, getName()); > 428: } There is a cleaner so shouldn't have a leak, even if the JarFile is not explicitly closed. The noisy "final" can be dropped, otherwise looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From dfuchs at openjdk.java.net Tue Sep 15 15:36:55 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Sep 2020 15:36:55 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 14:59:57 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for this patch which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-6714834? > As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally > calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it > on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a > `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable > when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a > mention that this can lead to incorrect manifest files ending up in jar files: >> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) > > I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But > my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's > created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store > these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract > and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't > see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in > this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the > nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the > `jdk:tier1` tests locally which hasn't shown any related failures. Hi Jaikiran, This is not an area I know too well - so I won't review formally, but the proposed changes look reasonable to me. Closing the stream from within `JarFile` after creating the manifest looks innocuous and should release any resource held by the stream earlier instead of waiting for the `JarFile` to be closed. As long as the input stream `close()` method is idem potent this should be safe, and AFAICS that is the case for the two input stream subclasses that can be returned by `ZipFile::getInputStream`. WRT to the claims in the JBS issue I see that that was logged against Java 6: there was no `Cleanable` at this time and it is possible that the internals of ZipFile/JarFile were quite different. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From jpai at openjdk.java.net Tue Sep 15 15:40:47 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:40:47 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: > Can I please get a review and a sponsor for this patch which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-6714834? > As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally > calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it > on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a > `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable > when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a > mention that this can lead to incorrect manifest files ending up in jar files: >> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) > > I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But > my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's > created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store > these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract > and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't > see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in > this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the > nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the > `jdk:tier1` tests locally which hasn't shown any related failures. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Remove "final" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/186/files - new: https://git.openjdk.java.net/jdk/pull/186/files/e5ab2869..11fa0776 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=186&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=186&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/186.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/186/head:pull/186 PR: https://git.openjdk.java.net/jdk/pull/186 From jpai at openjdk.java.net Tue Sep 15 15:43:23 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:43:23 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:29:44 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove "final" > > src/java.base/share/classes/java/util/jar/JarFile.java line 428: > >> 426: try (final InputStream is = super.getInputStream(manEntry)) { >> 427: man = new Manifest(is, getName()); >> 428: } > > There is a cleaner so shouldn't have a leak, even if the JarFile is not explicitly closed. > The noisy "final" can be dropped, otherwise looks good. Thank you for the review Alan. I've updated this PR to remove the `final`. And yes as you note, this doesn't really leak. This change closes the InputStream earlier, as soon as it is done, instead of waiting for the `Cleaner` to kick in. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From jpai at openjdk.java.net Tue Sep 15 15:47:31 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:47:31 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:33:51 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove "final" > > Hi Jaikiran, > > This is not an area I know too well - so I won't review formally, but the proposed changes look reasonable to me. > Closing the stream from within `JarFile` after creating the manifest looks innocuous and should release any resource > held by the stream earlier instead of waiting for the `JarFile` to be closed. As long as the input stream `close()` > method is idem potent this should be safe, and AFAICS that is the case for the two input stream subclasses that can be > returned by `ZipFile::getInputStream`. WRT to the claims in the JBS issue I see that that was logged against Java 6: > there was no `Cleanable` at this time and it is possible that the internals of ZipFile/JarFile were quite different. Thank you for the review Daniel. > WRT to the claims in the JBS issue I see that that was logged against Java 6: there was no Cleanable at this time and > it is possible that the internals of ZipFile/JarFile were quite different. You are right. I hadn't paid attention to that detail. It's likely that it might have been behaving differently at that time. As for this: > As long as the input stream close() method is idem potent this should be safe, and AFAICS that is the case for the two > input stream subclasses that can be returned by ZipFile::getInputStream. I'm curious, in the context of this change, why idempotency would be a necessity. Would there be a "double close" somehow on this `InputStream` instance? ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From dfuchs at openjdk.java.net Tue Sep 15 15:57:35 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 15 Sep 2020 15:57:35 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai wrote: > I'm curious, in the context of this change, why idempotency would be a necessity. Would there be a "double close" > somehow on this `InputStream` instance? My bad - I hadn't realised closing the input stream would also remove it from the Cleanable resource set, so I thought it might be closed again when the jar file is closed. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From jpai at openjdk.java.net Tue Sep 15 15:57:35 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 15 Sep 2020 15:57:35 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:45:05 GMT, Jaikiran Pai wrote: > As for this: > >> As long as the input stream close() method is idem potent this should be safe, and AFAICS that is the case for the two >> input stream subclasses that can be returned by ZipFile::getInputStream. > > I'm curious, in the context of this change, why idempotency would be a necessity. Would there be a "double close" > somehow on this InputStream instance? I think I understand what you meant. You were perhaps talking about the `JarFile.close` triggering the `Cleanable` to close this `InputStream` in addition to the `try-with-resources` already calling `close` on that stream. Like you rightly note, the implementation of those streams already handles that aspect correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From lancea at openjdk.java.net Tue Sep 15 17:02:39 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Sep 2020 17:02:39 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:40:47 GMT, Jaikiran Pai wrote: >> Can I please get a review and a sponsor for this patch which fixes the issue reported in >> https://bugs.openjdk.java.net/browse/JDK-6714834? >> As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally >> calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it >> on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a >> `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable >> when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a >> mention that this can lead to incorrect manifest files ending up in jar files: >>> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >>> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) >> >> I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But >> my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's >> created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store >> these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract >> and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't >> see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in >> this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the >> nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the >> `jdk:tier1` tests locally which hasn't shown any related failures. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Remove "final" I am fine with this as well. I will pull over the change and just sanity check it via mach5 and then will sponsor ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/186 From lancea at openjdk.java.net Tue Sep 15 19:45:21 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 15 Sep 2020 19:45:21 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 16:59:59 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove "final" > > I am fine with this as well. I will pull over the change and just sanity check it via mach5 and then will sponsor @jaikiran Please go ahead and integrate this and I can then sponsor (has to be done in that order) ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From valeriep at openjdk.java.net Tue Sep 15 20:18:45 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Sep 2020 20:18:45 GMT Subject: RFR: 8172366: Support SHA-3 based signatures [v5] In-Reply-To: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: > Could someone please help review this RFE? > > Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will > be updated separately (JDK-8242332). > This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to > various signature algorithms. > Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 > > Thanks! > Valerie Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update MGF1ParameterSpec.java Added "@since 16" to the new SHA-3 constants. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/102/files - new: https://git.openjdk.java.net/jdk/pull/102/files/62fb5a39..1274c9b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=102&range=03-04 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk/pull/102 From valeriep at openjdk.java.net Tue Sep 15 20:32:08 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Sep 2020 20:32:08 GMT Subject: Integrated: 8172366: Support SHA-3 based signatures In-Reply-To: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> Message-ID: On Thu, 10 Sep 2020 01:58:09 GMT, Valerie Peng wrote: > Could someone please help review this RFE? > > Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will > be updated separately (JDK-8242332). > This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to > various signature algorithms. > Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 > > Thanks! > Valerie This pull request has now been integrated. Changeset: 40206822 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/40206822 Stats: 681 lines in 20 files changed: 10 ins; 588 del; 83 mod 8172366: Support SHA-3 based signatures Enhance default JDK providers including SUN, SunRsaSign, and SunEC, with signatures using SHA-3 family of digests. Reviewed-by: xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From valeriep at openjdk.java.net Tue Sep 15 20:39:56 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Sep 2020 20:39:56 GMT Subject: RFR: 8172366: Support SHA-3 based signatures [v4] In-Reply-To: <9xmd19fjNxIwGgwsMxtxE1Fl_h4AF7t5n9OLVEHfjZ4=.19645352-fd29-4b4b-bc30-d422ff28ba10@github.com> References: <0etUpODIHPK_k-JwY0XLV6xJGb3bZBWWAWGDzBRjSzU=.e0d4b84d-b757-4009-a7ea-92186ab17f7d@github.com> <9xmd19fjNxIwGgwsMxtxE1Fl_h4AF7t5n9OLVEHfjZ4=.19645352-fd29-4b4b-bc30-d422ff28ba10@github.com> Message-ID: On Tue, 15 Sep 2020 11:54:19 GMT, Sean Mullan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update DSA.java >> >> Removed the trailing white spaces in previous update. > > The new constants in MGF1ParameterSpec.java should have "@since 16". > > > The new constants in MGF1ParameterSpec.java should have "@SInCE 16". Yes, made the change in last commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/102 From alanb at openjdk.java.net Wed Sep 16 06:19:06 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 16 Sep 2020 06:19:06 GMT Subject: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:40:47 GMT, Jaikiran Pai wrote: >> Can I please get a review and a sponsor for this patch which fixes the issue reported in >> https://bugs.openjdk.java.net/browse/JDK-6714834? >> As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally >> calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it >> on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a >> `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable >> when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a >> mention that this can lead to incorrect manifest files ending up in jar files: >>> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >>> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) >> >> I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But >> my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's >> created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store >> these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract >> and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't >> see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in >> this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the >> nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the >> `jdk:tier1` tests locally which hasn't shown any related failures. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Remove "final" Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From ckozak at ckozak.net Wed Sep 16 14:39:54 2020 From: ckozak at ckozak.net (Carter Kozak) Date: Wed, 16 Sep 2020 10:39:54 -0400 Subject: SSLSocket HandshakeCompletionListener Threading Message-ID: Hello, SSLSocket HandshakeCompletionListeners are a well known performance bottleneck due to new thread creation for each handshake, and the resulting session may be invalid by the time the listener thread has begun. Prior discussions: https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022220.html https://bugs.openjdk.java.net/browse/JDK-8246039 https://github.com/openjdk/loom/pull/16 Alan Bateman has suggested that we should re-validate calling listeners on separate threads because the resulting session may no longer be valid, and listeners themselves are capable of submitting work to an executor if they prefer. However I'm not confident we can safely change the implementation of the existing API without breaking consumers. It's reasonable to log handshake diagnostic information from a listener where it's not necessary for the session to be up to date, however without running asynchronously an https network logging appender may deadlock itself if the current implementation is updated to run all listeners on the same thread. Another option is to provide an overload of SSLSocket.addHandshakeCompletedListener which takes both a HandshakeCompletedListener and an Executor. An executor may be chosen to run listeners on the calling thread (executor Runnable::run), or an executor capable of pooling threads. There's some risk that this API could be used improperly and create a deadlock as described in the logging example, but with great power comes great responsibility and the upsides seem to outweigh the potential risk, especially given the thread-explosion problems we're currently experiencing. In the Loom PR linked above I've begun by attempting to preserve the existing behavior while reducing the cost of a listener when loom is available, using virtual threads instead of OS threads. Any and all feedback is greatly appreciated. Thanks, Carter Kozak From jpai at openjdk.java.net Wed Sep 16 15:16:49 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 16 Sep 2020 15:16:49 GMT Subject: Integrated: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 14:59:57 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for this patch which fixes the issue reported in > https://bugs.openjdk.java.net/browse/JDK-6714834? > As noted by the reporter in that issue, when the `java.util.jar.JarFile.getManifest()` method is called, it internally > calls the private `getManifestFromReference`. This private method implementation opens an `InputStream` for passing it > on to the constructor of the `Manifest`, but never closes it. The commit here fixes that part to use a > `try-with-resources` to close the `InputStream` once the `Manifest` instance is created. This issue is only applicable > when the `JarFile` is created with `verify` as `false`, which isn't the default. In that issue report, there's also a > mention that this can lead to incorrect manifest files ending up in jar files: >> can lead to serious and hard to track bugs (e.g. when replacing the manifest and generating a new JarFile, the old one >> can be unexpectedly taken in some circumstances unless one calls myJar.close() after myJar.getManifest()) > > I have gone through the code to see how this can happen and have also done some testing to see if this is possible. But > my tests and the code haven't shown this as a possibilty. The `Manifest` doesn't store any `InputStream` once it's > created nor does the `JarFile` store that stream. Although the `ZipFile`, which `JarFile` extends from, does store > these opened `InputStreams` into a `Set`, it only does it to close them as part of the `java.lang.ref.Cleaner` contract > and from what I can see, none of these APIs return or use these stored `InputStream`s for any other purpose. So I don't > see how a leaking `InputStream` can lead to a wrong `Manifest` ending up in a copy of a `JarFile`. So the commit in > this PR only addresses the leaking `InputStream`. I haven't added any new tests to verify this fix because given the > nature of this issue, I couldn't think of a consistent and determinstic way to verify it. I have however run the > `jdk:tier1` tests locally which hasn't shown any related failures. This pull request has now been integrated. Changeset: 671dfba8 Author: Jaikiran Pai Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/671dfba8 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect Reviewed-by: lancea, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/186 From xuelei.fan at oracle.com Wed Sep 16 19:21:01 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 16 Sep 2020 12:21:01 -0700 Subject: SSLSocket HandshakeCompletionListener Threading In-Reply-To: References: Message-ID: <2ac4e7eb-c6fa-dd65-19aa-a683aa1440c1@oracle.com> Good catch! Alternatively, I was wondering if it is possible to delegate the job to listeners, without modify the APIs, for example by implementing a Runnable interface (not a proposal, just a guess for now). I don't like the creation of threads in the JSSE provider, as application could take better care of the resources. I need more time to think about it. Xuelei On 9/16/2020 7:39 AM, Carter Kozak wrote: > Hello, > > SSLSocket HandshakeCompletionListeners are a well known performance bottleneck due to new thread creation for each handshake, and the resulting session may be invalid by the time the listener thread has begun. > > Prior discussions: > > https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022220.html > https://bugs.openjdk.java.net/browse/JDK-8246039 > https://github.com/openjdk/loom/pull/16 > > Alan Bateman has suggested that we should re-validate calling listeners on separate threads because the resulting session may no longer be valid, and listeners themselves are capable of submitting work to an executor if they prefer. However I'm not confident we can safely change the implementation of the existing API without breaking consumers. It's reasonable to log handshake diagnostic information from a listener where it's not necessary for the session to be up to date, however without running asynchronously an https network logging appender may deadlock itself if the current implementation is updated to run all listeners on the same thread. > > Another option is to provide an overload of SSLSocket.addHandshakeCompletedListener which takes both a HandshakeCompletedListener and an Executor. An executor may be chosen to run listeners on the calling thread (executor Runnable::run), or an executor capable of pooling threads. There's some risk that this API could be used improperly and create a deadlock as described in the logging example, but with great power comes great responsibility and the upsides seem to outweigh the potential risk, especially given the thread-explosion problems we're currently experiencing. > > In the Loom PR linked above I've begun by attempting to preserve the existing behavior while reducing the cost of a listener when loom is available, using virtual threads instead of OS threads. Any and all feedback is greatly appreciated. > > Thanks, > Carter Kozak > From bradford.wetmore at oracle.com Thu Sep 17 03:49:46 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 16 Sep 2020 20:49:46 -0700 Subject: SSLSocket HandshakeCompletionListener Threading In-Reply-To: <2ac4e7eb-c6fa-dd65-19aa-a683aa1440c1@oracle.com> References: <2ac4e7eb-c6fa-dd65-19aa-a683aa1440c1@oracle.com> Message-ID: <9d0efd48-ab64-06ea-0648-a2bf116319c4@oracle.com> From a coding point of view, if Xuelei doesn't have a further suggestion, using virtual threads like you have suggested seems to be a good solution. I'm ok with this change for Project Loom. Loom has a lot of promise for things like this. I've never been thrilled with the threading of the HandshakeCompletedListener and subsequent proposals, but unfortunately this was something we inherited long ago. That's one of the reasons I didn't include it in SSLEngine, but rather made a FINISHED HandshakeStatus Event Type. Thanks, Brad On 9/16/2020 12:21 PM, Xuelei Fan wrote: > Good catch! > > Alternatively, I was wondering if it is possible to delegate the job to > listeners, without modify the APIs, for example by implementing a > Runnable interface (not a proposal, just a guess for now).? I don't like > the creation of threads in the JSSE provider, as application could take > better care of the resources. > > I need more time to think about it. > > Xuelei > > On 9/16/2020 7:39 AM, Carter Kozak wrote: >> Hello, >> >> SSLSocket HandshakeCompletionListeners are a well known performance >> bottleneck due to new thread creation for each handshake, and the >> resulting session may be invalid by the time the listener thread has >> begun. >> >> Prior discussions: >> >> https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022220.html >> >> https://bugs.openjdk.java.net/browse/JDK-8246039 >> https://github.com/openjdk/loom/pull/16 >> >> Alan Bateman has suggested that we should re-validate calling >> listeners on separate threads because the resulting session may no >> longer be valid, and listeners themselves are capable of submitting >> work to an executor if they prefer. However I'm not confident we can >> safely change the implementation of the existing API without breaking >> consumers. It's reasonable to log handshake diagnostic information >> from a listener where it's not necessary for the session to be up to >> date, however without running asynchronously an https network logging >> appender may deadlock itself if the current implementation is updated >> to run all listeners on the same thread. >> >> Another option is to provide an overload of >> SSLSocket.addHandshakeCompletedListener which takes both a >> HandshakeCompletedListener and an Executor. An executor may be chosen >> to run listeners on the calling thread (executor Runnable::run), or an >> executor capable of pooling threads. There's some risk that this API >> could be used improperly and create a deadlock as described in the >> logging example, but with great power comes great responsibility and >> the upsides seem to outweigh the potential risk, especially given the >> thread-explosion problems we're currently experiencing. >> >> In the Loom PR linked above I've begun by attempting to preserve the >> existing behavior while reducing the cost of a listener when loom is >> available, using virtual threads instead of OS threads. Any and all >> feedback is greatly appreciated. >> >> Thanks, >> Carter Kozak >> From fyang at openjdk.java.net Thu Sep 17 04:26:15 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 17 Sep 2020 04:26:15 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic Message-ID: Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. Patch passed jtreg tier1-3 tests with QEMU system emulator. Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression. We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java We measured the performance benefit with an aarch64 cycle-accurate simulator. Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected. ------------- Commit messages: - Fix trailing whitespace issue - 8252204: AArch64: Implement SHA3 accelerator/intrinsic Changes: https://git.openjdk.java.net/jdk/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252204 Stats: 1021 lines in 31 files changed: 947 ins; 13 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From fyang at openjdk.java.net Thu Sep 17 05:21:04 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 17 Sep 2020 05:21:04 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 16:36:54 GMT, Fei Yang wrote: > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. @ardbiesheuvel : Ard, could you please ack this patch? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From sergei.tsypanov at yandex.ru Thu Sep 17 07:19:24 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 17 Sep 2020 09:19:24 +0200 Subject: Request for review of JDK-8251548 Message-ID: <408131600326592@mail.yandex.ru> Hello, is it possible to have a code review for the changes proposed in JDK-8251548? Sean Mullan has created an issue and web-review and can sponsor the patch as soos as it gets properly reviewed. As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > there is never any reason to explicitly initialize fields to 0/0.0/false/null so I believe the patch is harmless. Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ Thanks, Sergey Tsypanov From david.holmes at oracle.com Thu Sep 17 07:22:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Sep 2020 17:22:19 +1000 Subject: Request for review of JDK-8251548 In-Reply-To: <408131600326592@mail.yandex.ru> References: <408131600326592@mail.yandex.ru> Message-ID: Hi Sergey, Since OpenJDK has moved to git/github, this needs to reformulated as a Pull Request (PR). Cheers, David On 17/09/2020 5:19 pm, ?????? ??????? wrote: > Hello, > > is it possible to have a code review for the changes proposed in JDK-8251548? > > Sean Mullan has created an issue and web-review and can sponsor the patch > as soos as it gets properly reviewed. > > As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > >> there is never any reason to explicitly initialize fields to 0/0.0/false/null > > so I believe the patch is harmless. > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 > Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ > > Thanks, > Sergey Tsypanov > From sergei.tsypanov at yandex.ru Thu Sep 17 09:24:39 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Thu, 17 Sep 2020 11:24:39 +0200 Subject: Request for review of JDK-8251548 In-Reply-To: References: <408131600326592@mail.yandex.ru> Message-ID: <125311600334485@mail.yandex.ru> Hi David, thanks for pointing this out! I've created a PR there [1], but GitHub for some reason wants me to sign OCA, which I have already signed in 2017. I've redone the procedure and now I'm waiting for verification. Regards, Sergey 1. https://github.com/openjdk/jdk/pull/218 17.09.2020, 09:22, "David Holmes" : > Hi Sergey, > > Since OpenJDK has moved to git/github, this needs to reformulated as a > Pull Request (PR). > > Cheers, > David > > On 17/09/2020 5:19 pm, ?????? ??????? wrote: >> ?Hello, >> >> ?is it possible to have a code review for the changes proposed in JDK-8251548? >> >> ?Sean Mullan has created an issue and web-review and can sponsor the patch >> ?as soos as it gets properly reviewed. >> >> ?As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >> >>> ?there is never any reason to explicitly initialize fields to 0/0.0/false/null >> >> ?so I believe the patch is harmless. >> >> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 >> ?Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ >> >> ?Thanks, >> ?Sergey Tsypanov From david.holmes at oracle.com Thu Sep 17 12:10:46 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Sep 2020 22:10:46 +1000 Subject: Request for review of JDK-8251548 In-Reply-To: <125311600334485@mail.yandex.ru> References: <408131600326592@mail.yandex.ru> <125311600334485@mail.yandex.ru> Message-ID: On 17/09/2020 7:24 pm, ?????? ??????? wrote: > Hi David, > > thanks for pointing this out! > > I've created a PR there [1], but GitHub for some reason wants me to sign OCA, > which I have already signed in 2017. I've redone the procedure and now I'm waiting > for verification. Did you not follow these instructions to get your github account connected to your OCA record: "If you already are an OpenJDK Author, Committer or Reviewer, please click here[1] to open a new issue so that we can record that fact. Please use "Add GitHub user stsypanov" as summary for the issue." [1] https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 Cheers, David ----- > Regards, > Sergey > > 1. https://github.com/openjdk/jdk/pull/218 > > 17.09.2020, 09:22, "David Holmes" : >> Hi Sergey, >> >> Since OpenJDK has moved to git/github, this needs to reformulated as a >> Pull Request (PR). >> >> Cheers, >> David >> >> On 17/09/2020 5:19 pm, ?????? ??????? wrote: >>> ?Hello, >>> >>> ?is it possible to have a code review for the changes proposed in JDK-8251548? >>> >>> ?Sean Mullan has created an issue and web-review and can sponsor the patch >>> ?as soos as it gets properly reviewed. >>> >>> ?As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >>> >>>> ?there is never any reason to explicitly initialize fields to 0/0.0/false/null >>> >>> ?so I believe the patch is harmless. >>> >>> ?Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 >>> ?Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ >>> >>> ?Thanks, >>> ?Sergey Tsypanov From github.com+8448088+ardbiesheuvel at openjdk.java.net Thu Sep 17 15:35:28 2020 From: github.com+8448088+ardbiesheuvel at openjdk.java.net (Ard Biesheuvel) Date: Thu, 17 Sep 2020 15:35:28 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:18:28 GMT, Fei Yang wrote: >> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com >> >> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. >> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 >> >> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. >> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. >> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. >> >> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. >> Patch passed jtreg tier1-3 tests with QEMU system emulator. >> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make >> sure that there's no regression. >> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java >> We measured the performance benefit with an aarch64 cycle-accurate simulator. >> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. >> >> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on >> real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is >> detected. > > @ardbiesheuvel : Ard, could you please ack this patch? Thanks. Acked-by: Ard Biesheuvel ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From xuelei.fan at oracle.com Thu Sep 17 19:08:08 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Sep 2020 12:08:08 -0700 Subject: SSLSocket HandshakeCompletionListener Threading In-Reply-To: <9d0efd48-ab64-06ea-0648-a2bf116319c4@oracle.com> References: <2ac4e7eb-c6fa-dd65-19aa-a683aa1440c1@oracle.com> <9d0efd48-ab64-06ea-0648-a2bf116319c4@oracle.com> Message-ID: I thought more about the problem. I could see the performance improvement requirements for heavy loaded system. But it may not worthy of a complicated proposal, as the Loom feature could mitigate the impact. Maybe, a new system property could be defined, for example, "jdk.tls.server/client.handshakeCompletedListener.useNewThread", to turn on/off the thread creating in JDK for HandshakeCompletedEvent distribution. if (useNewThread) { // use Loom improved threading } else { // No thread created, distributed the event to each listener, the // listener will take care of the following execution, w/o thread. for each listener { listener.handshakeCompleted(event); } } There are a few drawbacks as the impact of System property is JVM globally, but should be fine. Xuelei On 9/16/2020 8:49 PM, Bradford Wetmore wrote: > From a coding point of view, if Xuelei doesn't have a further > suggestion, using virtual threads like you have suggested seems to be a > good solution.? I'm ok with this change for Project Loom.? Loom has a > lot of promise for things like this. > > I've never been thrilled with the threading of the > HandshakeCompletedListener and subsequent proposals, but unfortunately > this was something we inherited long ago.? That's one of the reasons I > didn't include it in SSLEngine, but rather made a FINISHED > HandshakeStatus Event Type. > > Thanks, > > Brad > > > > On 9/16/2020 12:21 PM, Xuelei Fan wrote: >> Good catch! >> >> Alternatively, I was wondering if it is possible to delegate the job >> to listeners, without modify the APIs, for example by implementing a >> Runnable interface (not a proposal, just a guess for now).? I don't >> like the creation of threads in the JSSE provider, as application >> could take better care of the resources. >> >> I need more time to think about it. >> >> Xuelei >> >> On 9/16/2020 7:39 AM, Carter Kozak wrote: >>> Hello, >>> >>> SSLSocket HandshakeCompletionListeners are a well known performance >>> bottleneck due to new thread creation for each handshake, and the >>> resulting session may be invalid by the time the listener thread has >>> begun. >>> >>> Prior discussions: >>> >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022220.html >>> >>> https://bugs.openjdk.java.net/browse/JDK-8246039 >>> https://github.com/openjdk/loom/pull/16 >>> >>> Alan Bateman has suggested that we should re-validate calling >>> listeners on separate threads because the resulting session may no >>> longer be valid, and listeners themselves are capable of submitting >>> work to an executor if they prefer. However I'm not confident we can >>> safely change the implementation of the existing API without breaking >>> consumers. It's reasonable to log handshake diagnostic information >>> from a listener where it's not necessary for the session to be up to >>> date, however without running asynchronously an https network logging >>> appender may deadlock itself if the current implementation is updated >>> to run all listeners on the same thread. >>> >>> Another option is to provide an overload of >>> SSLSocket.addHandshakeCompletedListener which takes both a >>> HandshakeCompletedListener and an Executor. An executor may be chosen >>> to run listeners on the calling thread (executor Runnable::run), or >>> an executor capable of pooling threads. There's some risk that this >>> API could be used improperly and create a deadlock as described in >>> the logging example, but with great power comes great responsibility >>> and the upsides seem to outweigh the potential risk, especially given >>> the thread-explosion problems we're currently experiencing. >>> >>> In the Loom PR linked above I've begun by attempting to preserve the >>> existing behavior while reducing the cost of a listener when loom is >>> available, using virtual threads instead of OS threads. Any and all >>> feedback is greatly appreciated. >>> >>> Thanks, >>> Carter Kozak >>> From github.com+10835776+stsypanov at openjdk.java.net Thu Sep 17 21:45:44 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 17 Sep 2020 21:45:44 GMT Subject: RFR: 8251548 Remove unnecessary explicit initialization of volatile variables in security-libs code Message-ID: Hello, is it possible to have a code review for the changes proposed in JDK-8251548 (originally contributed via https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)? Sean Mullan has created an issue and web-review and can sponsor the patch as soos as it gets properly reviewed. The issue itself is a continuation of changes merged into java.base before as: - https://bugs.openjdk.java.net/browse/JDK-6736490 - https://bugs.openjdk.java.net/browse/JDK-8035284 - https://bugs.openjdk.java.net/browse/JDK-8145680 As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > there is never any reason to explicitly initialize fields to 0/0.0/false/null so I believe this patch is harmless as well as previous ones. Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ Thanks, Sergey Tsypanov ------------- Commit messages: - 8251548 Remove unnecessary explicit initialization of volatile variables in security-libs code Changes: https://git.openjdk.java.net/jdk/pull/218/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=218&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 Stats: 17 lines in 8 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/218.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/218/head:pull/218 PR: https://git.openjdk.java.net/jdk/pull/218 From weijun at openjdk.java.net Thu Sep 17 23:07:58 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Sep 2020 23:07:58 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream Message-ID: This code change rewrites DerValue into a mostly immutable class and simplifies DerInputStream as a wrapper for a series of DerValues objects. DerInputBuffer is removed. All existing methods of DerValue and DerInputStream should still work with the exact same behavior, except for a few places where bugs are fixed. For example, Indefinite length must be used with a constructed tag. Except for the ObjectIdentifier class where DerInputBuffer is directly referenced, no other code is touched. ------------- Commit messages: - 8249783: Simplify DerValue and DerInputStream Changes: https://git.openjdk.java.net/jdk/pull/232/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=232&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249783 Stats: 1907 lines in 6 files changed: 467 ins; 1247 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/232/head:pull/232 PR: https://git.openjdk.java.net/jdk/pull/232 From smarks at openjdk.java.net Fri Sep 18 02:50:45 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Sep 2020 02:50:45 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote: >> Ok, sorry for the distraction. > > Our local Santuario maintainer says: > > In general, changes to Apache Santuario should also be made at Apache so we stay in sync. Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made earlier in this PR, > I have in mind dozens of improvements all over the code like this one. It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From sergei.tsypanov at yandex.ru Fri Sep 18 07:15:27 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 18 Sep 2020 09:15:27 +0200 Subject: Request for review of JDK-8251548 In-Reply-To: References: <408131600326592@mail.yandex.ru> <125311600334485@mail.yandex.ru> Message-ID: <260361600412955@mail.yandex.ru> Hi, > Did you not follow these instructions to get your github account > connected to your OCA record: Those are for "OpenJDK Author, Committer or Reviewer", but I'm only a contributor, i.e. I cannot file an issue or commit directly. My previous contributions were shipped as *.patch files in mail attachments. Anyway, OCA was approved again and the PR (https://github.com/openjdk/jdk/pull/218) is ready for review :) Cheers, Sergey 17.09.2020, 14:11, "David Holmes" : > On 17/09/2020 7:24 pm, ?????? ??????? wrote: >> ?Hi David, >> >> ?thanks for pointing this out! >> >> ?I've created a PR there [1], but GitHub for some reason wants me to sign OCA, >> ?which I have already signed in 2017. I've redone the procedure and now I'm waiting >> ?for verification. > > Did you not follow these instructions to get your github account > connected to your OCA record: > > "If you already are an OpenJDK Author, Committer or Reviewer, please > click here[1] to open a new issue so that we can record that fact. > Please use "Add GitHub user stsypanov" as summary for the issue." > > [1] > https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 > > Cheers, > David > ----- > >> ?Regards, >> ?Sergey >> >> ?1. https://github.com/openjdk/jdk/pull/218 >> >> ?17.09.2020, 09:22, "David Holmes" : >>> ?Hi Sergey, >>> >>> ?Since OpenJDK has moved to git/github, this needs to reformulated as a >>> ?Pull Request (PR). >>> >>> ?Cheers, >>> ?David >>> >>> ?On 17/09/2020 5:19 pm, ?????? ??????? wrote: >>>> ???Hello, >>>> >>>> ???is it possible to have a code review for the changes proposed in JDK-8251548? >>>> >>>> ???Sean Mullan has created an issue and web-review and can sponsor the patch >>>> ???as soos as it gets properly reviewed. >>>> >>>> ???As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >>>> >>>>> ???there is never any reason to explicitly initialize fields to 0/0.0/false/null >>>> >>>> ???so I believe the patch is harmless. >>>> >>>> ???Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 >>>> ???Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ >>>> >>>> ???Thanks, >>>> ???Sergey Tsypanov From github.com+1536494+doom369 at openjdk.java.net Fri Sep 18 11:07:46 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 18 Sep 2020 11:07:46 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <668fR1wEZWaC0TDCyRIeOZ4AddXZXnKQhyHQdXtOab8=.6cb419cb-632b-4524-980e-18a6e06958e8@github.com> On Fri, 18 Sep 2020 02:48:15 GMT, Stuart Marks wrote: >> Our local Santuario maintainer says: >> >> In general, changes to Apache Santuario should also be made at Apache so we stay in sync. > > Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made > earlier in this PR, >> I have in mind dozens of improvements all over the code like this one. > > It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and > sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source > bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... > so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to > code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything > outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and > sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. > There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some > code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is > definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd > like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. @stuart-marks thanks. Sure, I understand that maintaining OpenJDK is not a simple task. I thought as change is super simple without any side effects it can go through. But I was wrong. That's fine. I'll focus on `java.base` when I have some free time. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From aph at redhat.com Fri Sep 18 13:47:54 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Sep 2020 14:47:54 +0100 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: <28d501ee-0f96-48e0-bfc4-230721018968@redhat.com> On 17/09/2020 05:26, Fei Yang wrote: > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Given that there's no real hardware, it's extra-important to add the new instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cc:asm_check. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From fyang at openjdk.java.net Fri Sep 18 15:54:57 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Fri, 18 Sep 2020 15:54:57 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v2] In-Reply-To: References: Message-ID: > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge master - Fix trailing whitespace issue - 8252204: AArch64: Implement SHA3 accelerator/intrinsic Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com ------------- Changes: https://git.openjdk.java.net/jdk/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=01 Stats: 1012 lines in 29 files changed: 940 ins; 13 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From mullan at openjdk.java.net Fri Sep 18 15:59:13 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 18 Sep 2020 15:59:13 GMT Subject: RFR: 8251548 Remove unnecessary explicit initialization of volatile variables in security-libs code In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 08:09:31 GMT, ?????? ??????? wrote: > Hello, > > is it possible to have a code review for the changes proposed in JDK-8251548 (originally contributed via > https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)? > Sean Mullan has created an issue and web-review and can sponsor the patch as soos as it gets properly reviewed. > > The issue itself is a continuation of changes merged into java.base before as: > > - https://bugs.openjdk.java.net/browse/JDK-6736490 > - https://bugs.openjdk.java.net/browse/JDK-8035284 > - https://bugs.openjdk.java.net/browse/JDK-8145680 > > As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > >> there is never any reason to explicitly initialize fields to 0/0.0/false/null > > so I believe this patch is harmless as well as previous ones. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 > Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ > > Thanks, > Sergey Tsypanov Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/218 From fyang at openjdk.java.net Fri Sep 18 16:05:31 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Fri, 18 Sep 2020 16:05:31 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v3] In-Reply-To: References: Message-ID: <0uUIKwe29qJd177yzRttb-vvIkccG_wV5YuEQG4VmNY=.d2b684c1-e098-4384-9ea6-bba1dded72cf@github.com> > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Rebase ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/32f0bdc3..3e155193 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=01-02 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From ckozak at ckozak.net Fri Sep 18 18:09:09 2020 From: ckozak at ckozak.net (Carter Kozak) Date: Fri, 18 Sep 2020 14:09:09 -0400 Subject: SSLSocket HandshakeCompletionListener Threading In-Reply-To: References: <2ac4e7eb-c6fa-dd65-19aa-a683aa1440c1@oracle.com> <9d0efd48-ab64-06ea-0648-a2bf116319c4@oracle.com> Message-ID: <6c39582e-4e57-4803-acb3-355ac381d924@www.fastmail.com> Thanks Xuelei, As someone who primarily produces libraries consumed across many projects I would prefer not to use global jvm state. I worry that a global property requires administrators to have knowledge of every HandshakeCompletedListener that is used, and library authors have limited ability to take advantage of the optimization. Using loom virtual threads is likely good enough, otherwise I can put together proposals for per-SSLSocket and per-HandshakeCompletionListner executor configuration if that's helpful. Thanks, Carter Kozak On Thu, Sep 17, 2020, at 15:08, Xuelei Fan wrote: > I thought more about the problem. I could see the performance > improvement requirements for heavy loaded system. But it may not worthy > of a complicated proposal, as the Loom feature could mitigate the impact. > > Maybe, a new system property could be defined, for example, > "jdk.tls.server/client.handshakeCompletedListener.useNewThread", to turn > on/off the thread creating in JDK for HandshakeCompletedEvent distribution. > > if (useNewThread) { > // use Loom improved threading > } else { > // No thread created, distributed the event to each listener, the > // listener will take care of the following execution, w/o thread. > for each listener { > listener.handshakeCompleted(event); > } > } > > There are a few drawbacks as the impact of System property is JVM > globally, but should be fine. > > Xuelei > > On 9/16/2020 8:49 PM, Bradford Wetmore wrote: > > From a coding point of view, if Xuelei doesn't have a further > > suggestion, using virtual threads like you have suggested seems to be a > > good solution. I'm ok with this change for Project Loom. Loom has a > > lot of promise for things like this. > > > > I've never been thrilled with the threading of the > > HandshakeCompletedListener and subsequent proposals, but unfortunately > > this was something we inherited long ago. That's one of the reasons I > > didn't include it in SSLEngine, but rather made a FINISHED > > HandshakeStatus Event Type. > > > > Thanks, > > > > Brad > > > > > > > > On 9/16/2020 12:21 PM, Xuelei Fan wrote: > >> Good catch! > >> > >> Alternatively, I was wondering if it is possible to delegate the job > >> to listeners, without modify the APIs, for example by implementing a > >> Runnable interface (not a proposal, just a guess for now). I don't > >> like the creation of threads in the JSSE provider, as application > >> could take better care of the resources. > >> > >> I need more time to think about it. > >> > >> Xuelei > >> > >> On 9/16/2020 7:39 AM, Carter Kozak wrote: > >>> Hello, > >>> > >>> SSLSocket HandshakeCompletionListeners are a well known performance > >>> bottleneck due to new thread creation for each handshake, and the > >>> resulting session may be invalid by the time the listener thread has > >>> begun. > >>> > >>> Prior discussions: > >>> > >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022220.html > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8246039 > >>> https://github.com/openjdk/loom/pull/16 > >>> > >>> Alan Bateman has suggested that we should re-validate calling > >>> listeners on separate threads because the resulting session may no > >>> longer be valid, and listeners themselves are capable of submitting > >>> work to an executor if they prefer. However I'm not confident we can > >>> safely change the implementation of the existing API without breaking > >>> consumers. It's reasonable to log handshake diagnostic information > >>> from a listener where it's not necessary for the session to be up to > >>> date, however without running asynchronously an https network logging > >>> appender may deadlock itself if the current implementation is updated > >>> to run all listeners on the same thread. > >>> > >>> Another option is to provide an overload of > >>> SSLSocket.addHandshakeCompletedListener which takes both a > >>> HandshakeCompletedListener and an Executor. An executor may be chosen > >>> to run listeners on the calling thread (executor Runnable::run), or > >>> an executor capable of pooling threads. There's some risk that this > >>> API could be used improperly and create a deadlock as described in > >>> the logging example, but with great power comes great responsibility > >>> and the upsides seem to outweigh the potential risk, especially given > >>> the thread-explosion problems we're currently experiencing. > >>> > >>> In the Loom PR linked above I've begun by attempting to preserve the > >>> existing behavior while reducing the cost of a listener when loom is > >>> available, using virtual threads instead of OS threads. Any and all > >>> feedback is greatly appreciated. > >>> > >>> Thanks, > >>> Carter Kozak > >>> > From ecki at zusammenkunft.net Fri Sep 18 20:37:08 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 18 Sep 2020 20:37:08 +0000 Subject: SSLSocket HandshakeCompletionListener Threading In-Reply-To: <6c39582e-4e57-4803-acb3-355ac381d924@www.fastmail.com> References: <2ac4e7eb-c6fa-dd65-19aa-a683aa1440c1@oracle.com> <9d0efd48-ab64-06ea-0648-a2bf116319c4@oracle.com> , <6c39582e-4e57-4803-acb3-355ac381d924@www.fastmail.com> Message-ID: I agree with that statement as an author of applications which have to connect to a wide range of external systems with a wide range of libraries and components. It should be configurable as a parameter on socket, session or factory level. I find a new API is more than welcome, especially if it is not only synchron but also provides context and interaction (especially deny a handshake for rate limiting purposes) Gru? Bernd -- https://Bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Carter Kozak Gesendet: Friday, September 18, 2020 8:09:09 PM An: Xuelei Fan ; Bradford Wetmore ; security-dev at openjdk.java.net Betreff: Re: SSLSocket HandshakeCompletionListener Threading Thanks Xuelei, As someone who primarily produces libraries consumed across many projects I would prefer not to use global jvm state. I worry that a global property requires administrators to have knowledge of every HandshakeCompletedListener that is used, and library authors have limited ability to take advantage of the optimization. Using loom virtual threads is likely good enough, otherwise I can put together proposals for per-SSLSocket and per-HandshakeCompletionListner executor configuration if that's helpful. Thanks, Carter Kozak On Thu, Sep 17, 2020, at 15:08, Xuelei Fan wrote: > I thought more about the problem. I could see the performance > improvement requirements for heavy loaded system. But it may not worthy > of a complicated proposal, as the Loom feature could mitigate the impact. > > Maybe, a new system property could be defined, for example, > "jdk.tls.server/client.handshakeCompletedListener.useNewThread", to turn > on/off the thread creating in JDK for HandshakeCompletedEvent distribution. > > if (useNewThread) { > // use Loom improved threading > } else { > // No thread created, distributed the event to each listener, the > // listener will take care of the following execution, w/o thread. > for each listener { > listener.handshakeCompleted(event); > } > } > > There are a few drawbacks as the impact of System property is JVM > globally, but should be fine. > > Xuelei > > On 9/16/2020 8:49 PM, Bradford Wetmore wrote: > > From a coding point of view, if Xuelei doesn't have a further > > suggestion, using virtual threads like you have suggested seems to be a > > good solution. I'm ok with this change for Project Loom. Loom has a > > lot of promise for things like this. > > > > I've never been thrilled with the threading of the > > HandshakeCompletedListener and subsequent proposals, but unfortunately > > this was something we inherited long ago. That's one of the reasons I > > didn't include it in SSLEngine, but rather made a FINISHED > > HandshakeStatus Event Type. > > > > Thanks, > > > > Brad > > > > > > > > On 9/16/2020 12:21 PM, Xuelei Fan wrote: > >> Good catch! > >> > >> Alternatively, I was wondering if it is possible to delegate the job > >> to listeners, without modify the APIs, for example by implementing a > >> Runnable interface (not a proposal, just a guess for now). I don't > >> like the creation of threads in the JSSE provider, as application > >> could take better care of the resources. > >> > >> I need more time to think about it. > >> > >> Xuelei > >> > >> On 9/16/2020 7:39 AM, Carter Kozak wrote: > >>> Hello, > >>> > >>> SSLSocket HandshakeCompletionListeners are a well known performance > >>> bottleneck due to new thread creation for each handshake, and the > >>> resulting session may be invalid by the time the listener thread has > >>> begun. > >>> > >>> Prior discussions: > >>> > >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022220.html > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8246039 > >>> https://github.com/openjdk/loom/pull/16 > >>> > >>> Alan Bateman has suggested that we should re-validate calling > >>> listeners on separate threads because the resulting session may no > >>> longer be valid, and listeners themselves are capable of submitting > >>> work to an executor if they prefer. However I'm not confident we can > >>> safely change the implementation of the existing API without breaking > >>> consumers. It's reasonable to log handshake diagnostic information > >>> from a listener where it's not necessary for the session to be up to > >>> date, however without running asynchronously an https network logging > >>> appender may deadlock itself if the current implementation is updated > >>> to run all listeners on the same thread. > >>> > >>> Another option is to provide an overload of > >>> SSLSocket.addHandshakeCompletedListener which takes both a > >>> HandshakeCompletedListener and an Executor. An executor may be chosen > >>> to run listeners on the calling thread (executor Runnable::run), or > >>> an executor capable of pooling threads. There's some risk that this > >>> API could be used improperly and create a deadlock as described in > >>> the logging example, but with great power comes great responsibility > >>> and the upsides seem to outweigh the potential risk, especially given > >>> the thread-explosion problems we're currently experiencing. > >>> > >>> In the Loom PR linked above I've begun by attempting to preserve the > >>> existing behavior while reducing the cost of a listener when loom is > >>> available, using virtual threads instead of OS threads. Any and all > >>> feedback is greatly appreciated. > >>> > >>> Thanks, > >>> Carter Kozak > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.java.net Fri Sep 18 21:25:28 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 18 Sep 2020 21:25:28 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: Message-ID: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> > This code change rewrites DerValue into a mostly immutable class and simplifies DerInputStream as a wrapper for a > series of DerValues objects. DerInputBuffer is removed. > All existing methods of DerValue and DerInputStream should still work with the exact same behavior, except for a few > places where bugs are fixed. For example, Indefinite length must be used with a constructed tag. > Except for the ObjectIdentifier class where DerInputBuffer is directly referenced, no other code is touched. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: Enhance DerValue::getOctetString to be able to read multi-level constructed value. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/232/files - new: https://git.openjdk.java.net/jdk/pull/232/files/6f63d1ae..e8f804c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=232&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=232&range=00-01 Stats: 59 lines in 2 files changed: 58 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/232/head:pull/232 PR: https://git.openjdk.java.net/jdk/pull/232 From github.com+10835776+stsypanov at openjdk.java.net Fri Sep 18 21:29:45 2020 From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Fri, 18 Sep 2020 21:29:45 GMT Subject: Integrated: 8251548 Remove unnecessary explicit initialization of volatile variables in security-libs code In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 08:09:31 GMT, ?????? ??????? wrote: > Hello, > > is it possible to have a code review for the changes proposed in JDK-8251548 (originally contributed via > https://mail.openjdk.java.net/pipermail/security-dev/2020-June/022137.html)? > Sean Mullan has created an issue and web-review and can sponsor the patch as soos as it gets properly reviewed. > > The issue itself is a continuation of changes merged into java.base before as: > > - https://bugs.openjdk.java.net/browse/JDK-6736490 > - https://bugs.openjdk.java.net/browse/JDK-8035284 > - https://bugs.openjdk.java.net/browse/JDK-8145680 > > As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html > >> there is never any reason to explicitly initialize fields to 0/0.0/false/null > > so I believe this patch is harmless as well as previous ones. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 > Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ > > Thanks, > Sergey Tsypanov This pull request has now been integrated. Changeset: f55dd9d4 Author: Sergey Tsypanov Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/f55dd9d4 Stats: 17 lines in 8 files changed: 0 ins; 0 del; 17 mod 8251548: Remove unnecessary explicit initialization of volatile variables in security-libs code Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/218 From minqi at openjdk.java.net Fri Sep 18 23:54:11 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 18 Sep 2020 23:54:11 GMT Subject: RFR: 8253208: Move CDS related code to a separate class Message-ID: With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is specific to CDS. Tests: tier1-4 ------------- Commit messages: - 8253208: Move CDS related code to a separate class - Merge branch 'master' of https://github.com/yminqi/jdk into jdk-8253208 - Merge remote-tracking branch 'origin/jdk-8252689' - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used Changes: https://git.openjdk.java.net/jdk/pull/261/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253208 Stats: 196 lines in 20 files changed: 110 ins; 53 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261 PR: https://git.openjdk.java.net/jdk/pull/261 From xuelei.fan at oracle.com Sat Sep 19 00:16:59 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 18 Sep 2020 17:16:59 -0700 Subject: SSLSocket HandshakeCompletionListener Threading In-Reply-To: <6c39582e-4e57-4803-acb3-355ac381d924@www.fastmail.com> References: <2ac4e7eb-c6fa-dd65-19aa-a683aa1440c1@oracle.com> <9d0efd48-ab64-06ea-0648-a2bf116319c4@oracle.com> <6c39582e-4e57-4803-acb3-355ac381d924@www.fastmail.com> Message-ID: <9ee39350-f837-2f8e-ae70-4648f02cde6c@oracle.com> I'm not sure if it really worthy of new APIs. Old applications cannot benefit from new APIs. Let's see if the Loom project could meet the performance requirements firstly. Xuelei On 9/18/2020 11:09 AM, Carter Kozak wrote: > Thanks Xuelei, > > As someone who primarily produces libraries consumed across many projects I would prefer not to use global jvm state. I worry that a global property requires administrators to have knowledge of every HandshakeCompletedListener that is used, and library authors have limited ability to take advantage of the optimization. Using loom virtual threads is likely good enough, otherwise I can put together proposals for per-SSLSocket and per-HandshakeCompletionListner executor configuration if that's helpful. > > Thanks, > Carter Kozak > > On Thu, Sep 17, 2020, at 15:08, Xuelei Fan wrote: >> I thought more about the problem. I could see the performance >> improvement requirements for heavy loaded system. But it may not worthy >> of a complicated proposal, as the Loom feature could mitigate the impact. >> >> Maybe, a new system property could be defined, for example, >> "jdk.tls.server/client.handshakeCompletedListener.useNewThread", to turn >> on/off the thread creating in JDK for HandshakeCompletedEvent distribution. >> >> if (useNewThread) { >> // use Loom improved threading >> } else { >> // No thread created, distributed the event to each listener, the >> // listener will take care of the following execution, w/o thread. >> for each listener { >> listener.handshakeCompleted(event); >> } >> } >> >> There are a few drawbacks as the impact of System property is JVM >> globally, but should be fine. >> >> Xuelei >> >> On 9/16/2020 8:49 PM, Bradford Wetmore wrote: >>> From a coding point of view, if Xuelei doesn't have a further >>> suggestion, using virtual threads like you have suggested seems to be a >>> good solution. I'm ok with this change for Project Loom. Loom has a >>> lot of promise for things like this. >>> >>> I've never been thrilled with the threading of the >>> HandshakeCompletedListener and subsequent proposals, but unfortunately >>> this was something we inherited long ago. That's one of the reasons I >>> didn't include it in SSLEngine, but rather made a FINISHED >>> HandshakeStatus Event Type. >>> >>> Thanks, >>> >>> Brad >>> >>> >>> >>> On 9/16/2020 12:21 PM, Xuelei Fan wrote: >>>> Good catch! >>>> >>>> Alternatively, I was wondering if it is possible to delegate the job >>>> to listeners, without modify the APIs, for example by implementing a >>>> Runnable interface (not a proposal, just a guess for now). I don't >>>> like the creation of threads in the JSSE provider, as application >>>> could take better care of the resources. >>>> >>>> I need more time to think about it. >>>> >>>> Xuelei >>>> >>>> On 9/16/2020 7:39 AM, Carter Kozak wrote: >>>>> Hello, >>>>> >>>>> SSLSocket HandshakeCompletionListeners are a well known performance >>>>> bottleneck due to new thread creation for each handshake, and the >>>>> resulting session may be invalid by the time the listener thread has >>>>> begun. >>>>> >>>>> Prior discussions: >>>>> >>>>> https://mail.openjdk.java.net/pipermail/security-dev/2020-July/022220.html >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8246039 >>>>> https://urldefense.com/v3/__https://github.com/openjdk/loom/pull/16__;!!GqivPVa7Brio!LPVHdNV7-skDUGoz5TQU3LJAHJbheBWrocf-5ZB_USkbKxUJfcZkMLQ54dBoj56v$ >>>>> >>>>> Alan Bateman has suggested that we should re-validate calling >>>>> listeners on separate threads because the resulting session may no >>>>> longer be valid, and listeners themselves are capable of submitting >>>>> work to an executor if they prefer. However I'm not confident we can >>>>> safely change the implementation of the existing API without breaking >>>>> consumers. It's reasonable to log handshake diagnostic information >>>>> from a listener where it's not necessary for the session to be up to >>>>> date, however without running asynchronously an https network logging >>>>> appender may deadlock itself if the current implementation is updated >>>>> to run all listeners on the same thread. >>>>> >>>>> Another option is to provide an overload of >>>>> SSLSocket.addHandshakeCompletedListener which takes both a >>>>> HandshakeCompletedListener and an Executor. An executor may be chosen >>>>> to run listeners on the calling thread (executor Runnable::run), or >>>>> an executor capable of pooling threads. There's some risk that this >>>>> API could be used improperly and create a deadlock as described in >>>>> the logging example, but with great power comes great responsibility >>>>> and the upsides seem to outweigh the potential risk, especially given >>>>> the thread-explosion problems we're currently experiencing. >>>>> >>>>> In the Loom PR linked above I've begun by attempting to preserve the >>>>> existing behavior while reducing the cost of a listener when loom is >>>>> available, using virtual threads instead of OS threads. Any and all >>>>> feedback is greatly appreciated. >>>>> >>>>> Thanks, >>>>> Carter Kozak >>>>> >> From alanb at openjdk.java.net Sat Sep 19 15:54:25 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 19 Sep 2020 15:54:25 GMT Subject: RFR: 8253208: Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote: > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 src/java.base/share/classes/jdk/internal/misc/CDS.java line 42: > 40: public static native void defineArchivedModules(ClassLoader platformLoader, ClassLoader systemLoader); > 41: > 42: public static native long getRandomSeedForCDSDump(); The moving of the archive methods to CDS looks okay but inconsistent to only comment 3 of the 5 methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From iklam at openjdk.java.net Sun Sep 20 06:13:47 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Sun, 20 Sep 2020 06:13:47 GMT Subject: RFR: 8253208: Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote: > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 src/java.base/share/classes/jdk/internal/misc/CDS.java line 52: > 50: * Check if CDS sharing is enabled by via the UseSharedSpaces flag. > 51: */ > 52: public static native boolean isCDSSharingEnabled(); I think the word CDS is redundant in the method names. How about getRandomSeedForCDSDump() -> getRandomSeedForDumping() isCDSDumpingEnabled() -> isDynamicDumpingEnabled() // doesn't return true if we're doing a static dump isCDSSharingEnabled() -> isSharingEnabled() src/java.base/share/native/libjava/CDS.c line 49: > 47: JNIEXPORT jboolean JNICALL > 48: Java_jdk_internal_misc_CDS_isCDSDumpingEnabled(JNIEnv *env, jclass jcls) { > 49: return JVM_IsCDSDumpingEnabled(env); Maybe: return JVM_IsCDSDynamicDumpingEnabled(env) ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From fyang at openjdk.java.net Sun Sep 20 13:53:00 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Sun, 20 Sep 2020 13:53:00 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v4] In-Reply-To: References: Message-ID: > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/3e155193..04bdb42e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=02-03 Stats: 474 lines in 2 files changed: 61 ins; 9 del; 404 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From rriggs at openjdk.java.net Sun Sep 20 14:01:41 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sun, 20 Sep 2020 14:01:41 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter Message-ID: # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter Debugging functions that utilize ASN.1, DER, and BER encoded streams is difficult without test utilities to show the contents. The ASN.1 formatter reads a stream and produces annotated output of the tags, values, and structures. When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized with the hex formatted output. Small changes to HexPrinter are included to improve the output readability. Example decoding of a .pem certificate: SEQUENCE [910] SEQUENCE [630] CONTEXT cons 0 [3] BYTE 2, BYTE 3, SEQUENCE [13] OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) NULL SEQUENCE [76] SET [11] SEQUENCE [9] OBJECT ID [3] 2.5.4.6 (CountryName) 'IN' ... SET [16] SEQUENCE [14] OBJECT ID [3] 2.5.4.3 (CommonName) Client1 SEQUENCE [30] UTCTIME [13] '150526221718Z' UTCTIME [13] '250523221718Z' ... SEQUENCE [290] SEQUENCE [13] OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) NULL BIT STRING [271] CONTEXT cons 3 [123] SEQUENCE [121] SEQUENCE [9] OBJECT ID [3] 2.5.29.19 (BasicConstraints) OCTET STRING [2] SEQUENCE [44] OBJECT ID [9] 2.16.840.1.113730.1.13 OCTET STRING [31] '..OpenSSL Generated Certificate' SEQUENCE [29] OBJECT ID [3] 2.5.29.14 (SubjectKeyID) OCTET STRING [22] SEQUENCE [31] OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) OCTET STRING [24] SEQUENCE [13] OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) NULL BIT STRING [257] When used with the HexPrinter test utility, the formatting of the hexadecimal values is selected with the parameters to HexPrinter. 0000: 30 82 03 8e ; SEQUENCE [910] 0004: 30 82 02 76 ; SEQUENCE [630] 0008: a0 03 ; CONTEXT cons 0 [3] 000a: 02 01 02 ; BYTE 2, 000d: 02 01 03 ; BYTE 3, 0010: 30 0d ; SEQUENCE [13] 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) 001d: 05 00 ; NULL 001f: 30 ; SEQUENCE [76] 0020: 4c ; 0021: 31 0b ; SET [11] 0023: 30 09 ; SEQUENCE [9] 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) 002a: 13 02 49 4e ; 'IN' ... ... 005b: 31 10 ; SET [16] 005d: 30 0e ; SEQUENCE [14] 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) 0060: 03 55 04 03 ; 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 006d: 30 1e ; SEQUENCE [30] 006f: 17 ; UTCTIME [13] '150526221718Z' 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; 007e: 17 0d ; UTCTIME [13] '250523221718Z' 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; ... ... 00db: 30 82 01 22 ; SEQUENCE [290] 00df: 30 ; SEQUENCE [13] 00e0: 0d ; 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) 00ec: 05 00 ; NULL 00ee: 03 82 ; BIT STRING [271] 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; ... 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; 0200: 01 ; 0201: a3 7b ; CONTEXT cons 3 [123] 0203: 30 79 ; SEQUENCE [121] 0205: 30 09 ; SEQUENCE [9] 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) 020c: 04 02 30 00 ; OCTET STRING [2] 0210: 30 2c ; SEQUENCE [44] 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; 023e: 30 1d ; SEQUENCE [29] 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; 025d: 30 1f ; SEQUENCE [31] 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) 0260: 03 55 1d 23 ; 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; 027e: 30 0d ; SEQUENCE [13] 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) 028b: 05 00 ; NULL 028d: 03 82 01 ; BIT STRING [257] 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; ... 0390: 6d 94 ; ------------- Commit messages: - Add ASN1 Formatter to work with HexPrinter Changes: https://git.openjdk.java.net/jdk/pull/268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252523 Stats: 737 lines in 5 files changed: 727 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From rriggs at openjdk.java.net Sun Sep 20 14:14:51 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sun, 20 Sep 2020 14:14:51 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Small cleanups to javadoc and code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/268/files - new: https://git.openjdk.java.net/jdk/pull/268/files/67df141f..915dfe7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=00-01 Stats: 31 lines in 2 files changed: 12 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From david.holmes at oracle.com Mon Sep 21 03:11:16 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Sep 2020 13:11:16 +1000 Subject: Request for review of JDK-8251548 In-Reply-To: <260361600412955@mail.yandex.ru> References: <408131600326592@mail.yandex.ru> <125311600334485@mail.yandex.ru> <260361600412955@mail.yandex.ru> Message-ID: <1793e736-fc94-06f4-828c-9c75252ee2cc@oracle.com> On 18/09/2020 5:15 pm, ?????? ??????? wrote: > Hi, > >> Did you not follow these instructions to get your github account >> connected to your OCA record: > > Those are for "OpenJDK Author, Committer or Reviewer", but I'm only a contributor, > i.e. I cannot file an issue or commit directly. My previous contributions were shipped as *.patch > files in mail attachments. Ah sorry I overlooked that bit. > Anyway, OCA was approved again and the PR (https://github.com/openjdk/jdk/pull/218) is ready for review :) It wasn't necessary to re-do the OCA, but glad it is now sorted. David ----- > Cheers, > Sergey > > 17.09.2020, 14:11, "David Holmes" : >> On 17/09/2020 7:24 pm, ?????? ??????? wrote: >>> ?Hi David, >>> >>> ?thanks for pointing this out! >>> >>> ?I've created a PR there [1], but GitHub for some reason wants me to sign OCA, >>> ?which I have already signed in 2017. I've redone the procedure and now I'm waiting >>> ?for verification. >> >> Did you not follow these instructions to get your github account >> connected to your OCA record: >> >> "If you already are an OpenJDK Author, Committer or Reviewer, please >> click here[1] to open a new issue so that we can record that fact. >> Please use "Add GitHub user stsypanov" as summary for the issue." >> >> [1] >> https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 >> >> Cheers, >> David >> ----- >> >>> ?Regards, >>> ?Sergey >>> >>> ?1. https://github.com/openjdk/jdk/pull/218 >>> >>> ?17.09.2020, 09:22, "David Holmes" : >>>> ?Hi Sergey, >>>> >>>> ?Since OpenJDK has moved to git/github, this needs to reformulated as a >>>> ?Pull Request (PR). >>>> >>>> ?Cheers, >>>> ?David >>>> >>>> ?On 17/09/2020 5:19 pm, ?????? ??????? wrote: >>>>> ???Hello, >>>>> >>>>> ???is it possible to have a code review for the changes proposed in JDK-8251548? >>>>> >>>>> ???Sean Mullan has created an issue and web-review and can sponsor the patch >>>>> ???as soos as it gets properly reviewed. >>>>> >>>>> ???As Doug Lea claims in http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014770.html >>>>> >>>>>> ???there is never any reason to explicitly initialize fields to 0/0.0/false/null >>>>> >>>>> ???so I believe the patch is harmless. >>>>> >>>>> ???Issue: https://bugs.openjdk.java.net/browse/JDK-8251548 >>>>> ???Webrev: https://cr.openjdk.java.net/~mullan/webrevs/8251548/ >>>>> >>>>> ???Thanks, >>>>> ???Sergey Tsypanov From abakhtin at openjdk.java.net Mon Sep 21 08:26:04 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Mon, 21 Sep 2020 08:26:04 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos Message-ID: Hi, Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is "tls-server-end-point" CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 Thank you Alexey ------------- Commit messages: - 8245527: LDAP Channel Binding support for Java GSS/Kerberos Changes: https://git.openjdk.java.net/jdk/pull/278/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245527 Stats: 536 lines in 10 files changed: 524 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk/pull/278 From weijun at openjdk.java.net Mon Sep 21 14:07:48 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 21 Sep 2020 14:07:48 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 14:14:51 GMT, Roger Riggs wrote: >> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter >> >> Debugging functions that utilize ASN.1, DER, and BER encoded streams is >> difficult without test utilities to show the contents. >> The ASN.1 formatter reads a stream and produces annotated output of the >> tags, values, and structures. >> When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized >> with the hex formatted output. >> >> Small changes to HexPrinter are included to improve the output readability. >> >> >> Example decoding of a .pem certificate: >> SEQUENCE [910] >> SEQUENCE [630] >> CONTEXT cons 0 [3] >> BYTE 2, >> BYTE 3, >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> SEQUENCE [76] >> SET [11] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.4.6 (CountryName) >> 'IN' >> ... >> SET [16] >> SEQUENCE [14] >> OBJECT ID [3] 2.5.4.3 (CommonName) >> Client1 >> SEQUENCE [30] >> UTCTIME [13] '150526221718Z' >> UTCTIME [13] '250523221718Z' >> ... >> SEQUENCE [290] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> NULL >> BIT STRING [271] >> CONTEXT cons 3 [123] >> SEQUENCE [121] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> OCTET STRING [2] >> SEQUENCE [44] >> OBJECT ID [9] 2.16.840.1.113730.1.13 >> OCTET STRING [31] '..OpenSSL Generated Certificate' >> SEQUENCE [29] >> OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> OCTET STRING [22] >> SEQUENCE [31] >> OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> OCTET STRING [24] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> BIT STRING [257] >> When used with the HexPrinter test utility, the formatting of the >> hexadecimal values is selected with the parameters to HexPrinter. >> >> 0000: 30 82 03 8e ; SEQUENCE [910] >> 0004: 30 82 02 76 ; SEQUENCE [630] >> 0008: a0 03 ; CONTEXT cons 0 [3] >> 000a: 02 01 02 ; BYTE 2, >> 000d: 02 01 03 ; BYTE 3, >> 0010: 30 0d ; SEQUENCE [13] >> 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 001d: 05 00 ; NULL >> 001f: 30 ; SEQUENCE [76] >> 0020: 4c ; >> 0021: 31 0b ; SET [11] >> 0023: 30 09 ; SEQUENCE [9] >> 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) >> 002a: 13 02 49 4e ; 'IN' >> >> ... ... >> >> 005b: 31 10 ; SET [16] >> 005d: 30 0e ; SEQUENCE [14] >> 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) >> 0060: 03 55 04 03 ; >> 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 >> 006d: 30 1e ; SEQUENCE [30] >> 006f: 17 ; UTCTIME [13] '150526221718Z' >> 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; >> 007e: 17 0d ; UTCTIME [13] '250523221718Z' >> 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; >> >> ... ... >> >> 00db: 30 82 01 22 ; SEQUENCE [290] >> 00df: 30 ; SEQUENCE [13] >> 00e0: 0d ; >> 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> 00ec: 05 00 ; NULL >> 00ee: 03 82 ; BIT STRING [271] >> 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; >> >> ... >> >> 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; >> 0200: 01 ; >> 0201: a3 7b ; CONTEXT cons 3 [123] >> 0203: 30 79 ; SEQUENCE [121] >> 0205: 30 09 ; SEQUENCE [9] >> 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> 020c: 04 02 30 00 ; OCTET STRING [2] >> 0210: 30 2c ; SEQUENCE [44] >> 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 >> 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated >> Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; >> 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; >> 023e: 30 1d ; SEQUENCE [29] >> 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] >> 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; >> 025d: 30 1f ; SEQUENCE [31] >> 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> 0260: 03 55 1d 23 ; >> 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] >> 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; >> 027e: 30 0d ; SEQUENCE [13] >> 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 028b: 05 00 ; NULL >> 028d: 03 82 01 ; BIT STRING [257] >> 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; >> >> ... >> >> 0390: 6d 94 ; > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Small cleanups to javadoc and code Just some comments based on the output example. test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 228: > 226: break; > 227: > 228: case TAG_OctetString: I'd rather print nothing for OCTET STRING. My understanding of it is opaque octets and not meant to be printable. test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 362: > 360: switch (tag & 0xc0) { > 361: case TAG_APPLICATION: > 362: return "APPLICATION " + cons + (tag & 0x1f); I am not sure how important it is to print out "cons". Also, the tag here is usually shown as "[1]" in ASN.1 definition. Of course, if you choose this style, you might want to avoid using brackets for length. test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 355: > 353: String cons = isConstructed(tag) ? "cons " : ""; > 354: if (tag > 0 && tag < tagNames.length) > 355: return tagNames[tag] + " " + cons; Extra space when cons is "". ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From minqi at openjdk.java.net Mon Sep 21 18:17:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 18:17:55 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8253208: Move CDS related code to a separate class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/261/files - new: https://git.openjdk.java.net/jdk/pull/261/files/b9789c8b..c01deec7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=00-01 Stats: 27 lines in 7 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261 PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Mon Sep 21 18:25:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 18:25:55 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: <7rL3zSJi28q_2LUdGaxlpMg8b2fFh1IHNF07U3uaaeU=.b4a7e852-9c61-43bf-aadf-30b5d5d6af32@github.com> On Sun, 20 Sep 2020 06:10:53 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8253208: Move CDS related code to a separate class > > src/java.base/share/native/libjava/CDS.c line 49: > >> 47: JNIEXPORT jboolean JNICALL >> 48: Java_jdk_internal_misc_CDS_isCDSDumpingEnabled(JNIEnv *env, jclass jcls) { >> 49: return JVM_IsCDSDumpingEnabled(env); > > Maybe: return JVM_IsCDSDynamicDumpingEnabled(env) updated with comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From mchung at openjdk.java.net Mon Sep 21 19:00:33 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Sep 2020 19:00:33 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class This patch looks okay. Please add the javadoc for `CDS::getRandomSeedForDumping` and `CDS::defineArchiveModules` for completeness. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From erikj at openjdk.java.net Mon Sep 21 19:07:13 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Sep 2020 19:07:13 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: <65z5iR9UPXmBfCEVJkOgnegcyctdCIOZJ_tMl0bEdAI=.0457ea07-f4ff-48e4-b793-2e8011ee1a45@github.com> On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Build changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From david.holmes at oracle.com Thu Sep 10 13:49:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Sep 2020 23:49:24 +1000 Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote: > On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: > >>> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >>> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >>> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >>> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >>> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >>> JDK-8215014 rather than creating a new issue. >> >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > I have in mind dozens of improvements all over the code like this one. I already did some further review and in most > cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would > multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. Find a reasonable middle ground. You have around 14 mailing lists cc'd here, for changes on 150 files. It is very unlikely anyone will review all 150, and files in different areas are, by convention, reviewed by Reviewers for those areas. Even if people only look at a subset of files, communicating that to you effectively so you can figure out when all 150 have been reviewed, is not very practical. My initial breakdown would be: - build - desktop (awt/swing/2d) - serviceability/jmx (the SA and JVMTI changes) - security - core-libs Also note that while the original PR email went out to 14 lists, most people trying to reply-all won't be able to as they don't subscribe to all 14 lists, so the review threads will get very fragmented. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/29 > From felix.yang at huawei.com Mon Sep 21 02:59:47 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 21 Sep 2020 02:59:47 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: <28d501ee-0f96-48e0-bfc4-230721018968@redhat.com> References: <28d501ee-0f96-48e0-bfc4-230721018968@redhat.com> Message-ID: Hi, > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-retn at openjdk.java.net] On Behalf > Of Andrew Haley > Sent: Friday, September 18, 2020 9:48 PM > To: Fei Yang ; hotspot-dev at openjdk.java.net; > security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On 17/09/2020 05:26, Fei Yang wrote: > > For now, this feature will not be enabled automatically for aarch64. > > We can auto-enable this when it is fully tested on real hardware. But > > for the above testing purposes, this is auto-enabled when the > corresponding hardware feature is detected. > > Given that there's no real hardware, it's extra-important to add the new > instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in > assembler_aarch64.cc:asm_check. I have added on commit in PR resolving this: https://github.com/openjdk/jdk/pull/207/commits/04bdb42e971aa1c2f78bb5c916db62910e167053?file-filters%5B%5D= I grouped SHA512SIMDOp, SHA3SIMDOp and SVEVectorOp after the # ARMv8.2A comment. So anticipate more changes in file assembler_aarch64.cpp. BTW: If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java 15 #-----testresult----- 16 description=file\:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java 17 elapsed=31546 0\:00\:31.546 18 end=Mon Sep 21 10\:27\:58 CST 2020 19 environment=regtest 20 execStatus=Failed. Execution failed\: `main' threw exception\: java.lang.AssertionError\: Option 'UseSHA3Intrinsics' is expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default Any suggestions for this? Thanks, Felix From iklam at openjdk.java.net Mon Sep 21 21:57:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 21 Sep 2020 21:57:01 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Mon Sep 21 22:24:15 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 22:24:15 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v3] In-Reply-To: References: Message-ID: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8253208: Move CDS related code to a separate class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/261/files - new: https://git.openjdk.java.net/jdk/pull/261/files/c01deec7..953b6bac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=01-02 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261 PR: https://git.openjdk.java.net/jdk/pull/261 From ascarpino at openjdk.java.net Mon Sep 21 23:14:18 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Mon, 21 Sep 2020 23:14:18 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves Message-ID: This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 ------------- Commit messages: - 8235710: Remove the legacy elliptic curves Changes: https://git.openjdk.java.net/jdk/pull/289/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8235710 Stats: 20143 lines in 75 files changed: 25 ins; 20038 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289 From erikj at openjdk.java.net Mon Sep 21 23:52:50 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Sep 2020 23:52:50 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 21:10:58 GMT, Anthony Scarpino wrote: > This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 make/autoconf/jdk-options.m4 line 234: > 232: # Enable or disable the elliptic curve crypto implementation > 233: # > 234: AC_DEFUN_ONCE([JDKOPT_DETECT_INTREE_EC], There should be a call to this macro from either configure.ac or this file that also needs to be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Tue Sep 22 00:18:08 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 22 Sep 2020 00:18:08 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 23:50:07 GMT, Erik Joelsson wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > make/autoconf/jdk-options.m4 line 234: > >> 232: # Enable or disable the elliptic curve crypto implementation >> 233: # >> 234: AC_DEFUN_ONCE([JDKOPT_DETECT_INTREE_EC], > > There should be a call to this macro from either configure.ac or this file that also needs to be removed. found it in configure.ac and removed ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Tue Sep 22 00:18:07 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 22 Sep 2020 00:18:07 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: > This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: remove JDKOPT_DETECT_INTREE_EC from configure.ac ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/289/files - new: https://git.openjdk.java.net/jdk/pull/289/files/47eee3f4..8a04ce7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289 From xuelei at openjdk.java.net Tue Sep 22 01:31:08 2020 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Tue, 22 Sep 2020 01:31:08 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/289 From github.com+471021+marschall at openjdk.java.net Tue Sep 22 05:26:31 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Tue, 22 Sep 2020 05:26:31 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v3] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=02 Stats: 748 lines in 64 files changed: 149 ins; 149 del; 450 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From egahlin at openjdk.java.net Tue Sep 22 08:45:52 2020 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 22 Sep 2020 08:45:52 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Sat, 12 Sep 2020 00:19:00 GMT, Vladimir Kozlov wrote: >> Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. The pull request contains one new >> commit since the last revision: >> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Marked as reviewed by kvn (Reviewer). Have you run the JFR tests in test/jdk/jdk/jfr? ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From erikj at openjdk.java.net Tue Sep 22 13:23:40 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Sep 2020 13:23:40 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac Build changes look good. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From mullan at openjdk.java.net Tue Sep 22 14:08:44 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 22 Sep 2020 14:08:44 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: <8nr0RrYr-7cnjo4sSs9BpMWPCfFptjBDVu56hoDxl0U=.d5addb7e-5646-4f58-a5e7-29eda6cae1fc@github.com> On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac throw new IllegalStateException( new InvalidAlgorithmParameterException( "Curve not supported: Private: " + ((privNC != null) ? privNC.toString() : " unknown") + ", PublicKey:" + ((pubNC != null) ? pubNC.toString() : " unknown"))); src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 180: > 178: ((privNC != null) ? privNC.toString() : " unknown") + > 179: ", PublicKey:" + > 180: ((pubNC != null) ? pubNC.toString() : " unknown"))); Spacing issues: "PublicKey:" should be "PublicKey: " and " unknown" should be "unknown". ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From dfuchs at openjdk.java.net Tue Sep 22 14:29:07 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Sep 2020 14:29:07 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey Thanks for the PR Alexey! Let me run a last round of testing - and if that comes back clean I'll approve. Please don't integrate until you get a reviewer from security-libs too. best regards, -- daniel ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From dfuchs at openjdk.java.net Tue Sep 22 14:53:34 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Sep 2020 14:53:34 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 994: > 992: } > 993: > 994: private CompletableFuture tlsHandshakeCompleted = Should be `final`? src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 63: > 61: * Channel binding on the basis of TLS Finished message > 62: */ > 63: TLS_UNIQUE("tls-unique"), Is that still used? If not maybe it should be removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From abakhtin at openjdk.java.net Tue Sep 22 15:01:20 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 15:01:20 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 14:41:57 GMT, Daniel Fuchs wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 994: > >> 992: } >> 993: >> 994: private CompletableFuture tlsHandshakeCompleted = > > Should be `final`? Thank you. Agree. It should be final. ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From abakhtin at openjdk.java.net Tue Sep 22 15:20:07 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 15:20:07 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 14:47:35 GMT, Daniel Fuchs wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 63: > >> 61: * Channel binding on the basis of TLS Finished message >> 62: */ >> 63: TLS_UNIQUE("tls-unique"), > > Is that still used? If not maybe it should be removed? No, It is not used. However, I'd like to leave it as is (it is mentioned in the documentation as unsupported value). Otherwise, TlsChannelBindingType enum will have one element only and should be simplified/removed in all places. In this case, it would be double work to add TlsChannelBindingType enum back in the future if "tls-unique" required. If required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType enum ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From dfuchs at openjdk.java.net Tue Sep 22 15:38:52 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Sep 2020 15:38:52 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:17:23 GMT, Alexey Bakhtin wrote: >> src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 63: >> >>> 61: * Channel binding on the basis of TLS Finished message >>> 62: */ >>> 63: TLS_UNIQUE("tls-unique"), >> >> Is that still used? If not maybe it should be removed? > > No, It is not used. > However, I'd like to leave it as is (it is mentioned in the documentation as unsupported value). > Otherwise, TlsChannelBindingType enum will have one element only and should be simplified/removed in all places. In > this case, it would be double work to add TlsChannelBindingType enum back in the future if "tls-unique" required. If > required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType enum OK ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From weijun at openjdk.java.net Tue Sep 22 15:43:56 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 22 Sep 2020 15:43:56 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey I'm mostly OK with the SASL/JGSS part, except for the small nits in this comment. I'm not an expert on HandshakeCompletedListener. src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java line 156: > 154: if (props != null) { > 155: // TLS Channel Binding > 156: byte[] tlsCB = (byte[])props.get("jdk.internal.sasl.tlschannelbinding"); You can say the name is defined in another class in another module. If we really want to rename it one day we will know where it's from. src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java line 389: > 387: int acceptorAddressType = getAddrType(acceptorAddress, > 388: (channelBinding instanceof TlsChannelBindingImpl)? > 389: CHANNEL_BINDING_AF_UNSPEC:CHANNEL_BINDING_AF_NULL_ADDR); Normally we put a white space around "?" and ":". src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 82: > 80: /** > 81: * Parse value of "com.sun.jndi.ldap.tls.cbtype" property > 82: * @param cbType Please add a `@return` here, esp, about null. src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 137: > 135: public TlsChannelBindingType getType() { > 136: return cbType; > 137: } Add a new line here. ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From mchung at openjdk.java.net Tue Sep 22 16:03:07 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Sep 2020 16:03:07 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v3] In-Reply-To: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> References: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> Message-ID: <8hwfOa6oYGE3dZPVcdltbIO_lVzRHFeztiTrFAFaIr0=.f4082018-d17a-40ee-94f7-14fef9872579@github.com> On Mon, 21 Sep 2020 22:24:15 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Tue Sep 22 16:14:40 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 22 Sep 2020 16:14:40 GMT Subject: Integrated: 8253208: Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote: > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 This pull request has now been integrated. Changeset: c1df13b8 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/c1df13b8 Stats: 218 lines in 23 files changed: 53 ins; 119 del; 46 mod 8253208: Move CDS related code to a separate class Reviewed-by: mchung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From rriggs at openjdk.java.net Tue Sep 22 19:54:31 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Sep 2020 19:54:31 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v3] In-Reply-To: References: Message-ID: <9q8q70FXeg-Nd4ym4zvOsTwT4pg60kSaQIQUR3sPcgc=.fcab4d54-793d-4a0a-a307-682132156154@github.com> > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: For octet strings, dropped output of bytes; improved tag output for constructed tags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/268/files - new: https://git.openjdk.java.net/jdk/pull/268/files/915dfe7e..d56007bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=01-02 Stats: 24 lines in 2 files changed: 7 ins; 9 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From abakhtin at openjdk.java.net Tue Sep 22 20:19:21 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 20:19:21 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: 8245527: version.01 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/278/files - new: https://git.openjdk.java.net/jdk/pull/278/files/3f4ae08c..8b135f48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=278&range=00-01 Stats: 15 lines in 4 files changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/278.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/278/head:pull/278 PR: https://git.openjdk.java.net/jdk/pull/278 From abakhtin at openjdk.java.net Tue Sep 22 20:19:22 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 20:19:22 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: <5_WchmlW1dR-XMytqx__iZ0ZMcWSy7vo6X6S7knzvBQ=.b9751c22-81db-4ef1-ae06-3261a9e5036a@github.com> On Tue, 22 Sep 2020 15:36:24 GMT, Daniel Fuchs wrote: >> No, It is not used. >> However, I'd like to leave it as is (it is mentioned in the documentation as unsupported value). >> Otherwise, TlsChannelBindingType enum will have one element only and should be simplified/removed in all places. In >> this case, it would be double work to add TlsChannelBindingType enum back in the future if "tls-unique" required. If >> required I can remove TLS_UNIQUE item, but not remove TlsChannelBindingType enum > > I was suggesting to keep TlsChannelBindingType but remove TLS_UNIQUE; However, I'm OK to keep things as is: this is an > internal API. I wonder if it would deserve a comment: > /** > * Channel binding on the basis of TLS Finished message > */ > // TLS_UNIQUE is defined by RFC 5929 but is not supported by the current LDAP stack. > TLS_UNIQUE("tls-unique"), Thank you. Added suggested comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From abakhtin at openjdk.java.net Tue Sep 22 20:19:25 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Tue, 22 Sep 2020 20:19:25 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: <-GwI0o39ByGxRTf5tsgTzuPxjxz_M0Q8XQKqJprkK4g=.1da6ca12-db0b-4693-95a8-e9b11a64ce71@github.com> On Tue, 22 Sep 2020 15:11:57 GMT, Weijun Wang wrote: >> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: >> >> 8245527: version.01 > > src/jdk.security.jgss/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java line 156: > >> 154: if (props != null) { >> 155: // TLS Channel Binding >> 156: byte[] tlsCB = (byte[])props.get("jdk.internal.sasl.tlschannelbinding"); > > You can say the name is defined in another class in another module. If we really want to rename it one day we will know > where it's from. Thank you. Comment is added > src/java.security.jgss/share/classes/sun/security/jgss/krb5/InitialToken.java line 389: > >> 387: int acceptorAddressType = getAddrType(acceptorAddress, >> 388: (channelBinding instanceof TlsChannelBindingImpl)? >> 389: CHANNEL_BINDING_AF_UNSPEC:CHANNEL_BINDING_AF_NULL_ADDR); > > Normally we put a white space around "?" and ":". Thank you. Fixed. > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 82: > >> 80: /** >> 81: * Parse value of "com.sun.jndi.ldap.tls.cbtype" property >> 82: * @param cbType > > Please add a `@return` here, esp, about null. Added @return with comments > src/java.naming/share/classes/com/sun/jndi/ldap/sasl/TlsChannelBinding.java line 137: > >> 135: public TlsChannelBindingType getType() { >> 136: return cbType; >> 137: } > > Add a new line here. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From hchao at openjdk.java.net Tue Sep 22 22:27:29 2020 From: hchao at openjdk.java.net (Hai-May Chao) Date: Tue, 22 Sep 2020 22:27:29 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier Message-ID: This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a Null tag. ------------- Commit messages: - 8252377: Incorrect encoding for EC AlgorithmIdentifier Changes: https://git.openjdk.java.net/jdk/pull/312/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=312&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252377 Stats: 217 lines in 2 files changed: 216 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/312/head:pull/312 PR: https://git.openjdk.java.net/jdk/pull/312 From weijun at openjdk.java.net Wed Sep 23 02:52:20 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 23 Sep 2020 02:52:20 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 22:21:20 GMT, Hai-May Chao wrote: > This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a > Null tag. I don't quite understand what the test is for. The bug is about encoding but the test seems to be decoding the certificates. Does the test fail before this fix and succeed after it? ------------- PR: https://git.openjdk.java.net/jdk/pull/312 From github.com+471021+marschall at openjdk.java.net Wed Sep 23 04:03:05 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 23 Sep 2020 04:03:05 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v4] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=03 Stats: 753 lines in 65 files changed: 153 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From dholmes at openjdk.java.net Wed Sep 23 05:13:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 05:13:17 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous reviews/comments obsolete. There is no way for the reviewers to see what changed between the commit they reviewed and the commit now in the PR. To update to latest changes you should have just merged your branch with your (up-to-date) local master, committed that merge in your local branch and then pushed that commit to your Personal Fork. The skara tooling will flatten the series of commits in a PR into one single well-formed commit that is pushed to the master branch of the repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From hchao at openjdk.java.net Wed Sep 23 06:10:16 2020 From: hchao at openjdk.java.net (Hai-May Chao) Date: Wed, 23 Sep 2020 06:10:16 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier In-Reply-To: References: Message-ID: <8_DfI5w0Cnz-JRLIDzlOa7eYV1lt3l-iLZdcQNZHBLM=.02dc2125-b0a9-43b2-8fac-62e44c53e129@github.com> On Wed, 23 Sep 2020 02:49:29 GMT, Weijun Wang wrote: >> This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a >> Null tag. > > I don't quite understand what the test is for. The bug is about encoding but the test seems to be decoding the > certificates. Does the test fail before this fix and succeed after it? This is because the encoding of Algorithm Identifier incorrectly adds two NULL tags to the parameters field in the canned certificate. (There are two Algorithm Identifiers in the cert, with each NULL tag containing two bytes: tag + length.) I use the length of an encoded certificate (x509Cert.getEncoded().length) to verify that the certificate contains an extra 4 bytes to hold the two NULL tags. Therefore, the certificate without the fix should be 4 bytes (5 bytes if one byte alignment is applied) longer in length than the certificate with the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/312 From eric.c.liu at arm.com Wed Sep 23 06:10:07 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 23 Sep 2020 06:10:07 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com>, Message-ID: Hi Kim,? Sorry for the delay. This patch removes a redundant string copy in NetworkInterface.c to avoid string-truncation warning. Other warnings we talked before, which are unable to completely fix in different version of gcc, I have to use pragma to suppress them as a workaround. This patch now could compile with gcc-7, gcc-8, gcc-9, gcc-10 both with or without asan. [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252407 Thanks, Eric From dfuchs at openjdk.java.net Wed Sep 23 11:52:27 2020 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 23 Sep 2020 11:52:27 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: <0P4iJvOu6L8Itu3gKZyIE_0sGLCJC2SseA3LJsO2PCQ=.69fc69db-b9c4-4ee3-a9fc-6445f42cb450@github.com> On Tue, 22 Sep 2020 20:19:21 GMT, Alexey Bakhtin wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > 8245527: version.01 Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From aefimov at openjdk.java.net Wed Sep 23 12:21:02 2020 From: aefimov at openjdk.java.net (Aleksei Efimov) Date: Wed, 23 Sep 2020 12:21:02 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 20:19:21 GMT, Alexey Bakhtin wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is >> "tls-server-end-point" >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > 8245527: version.01 Hi Alexey, The latest changes looks good to me. ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.java.net/jdk/pull/278 From weijun at openjdk.java.net Wed Sep 23 13:13:37 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 23 Sep 2020 13:13:37 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier In-Reply-To: <8_DfI5w0Cnz-JRLIDzlOa7eYV1lt3l-iLZdcQNZHBLM=.02dc2125-b0a9-43b2-8fac-62e44c53e129@github.com> References: <8_DfI5w0Cnz-JRLIDzlOa7eYV1lt3l-iLZdcQNZHBLM=.02dc2125-b0a9-43b2-8fac-62e44c53e129@github.com> Message-ID: On Wed, 23 Sep 2020 06:07:09 GMT, Hai-May Chao wrote: >> I don't quite understand what the test is for. The bug is about encoding but the test seems to be decoding the >> certificates. Does the test fail before this fix and succeed after it? > > This is because the encoding of Algorithm Identifier incorrectly adds two NULL tags to the parameters field in the > canned certificate. (There are two Algorithm Identifiers in the cert, with each NULL tag containing two bytes: tag + > length.) I use the length of an encoded certificate (x509Cert.getEncoded().length) to verify that the certificate > contains an extra 4 bytes to hold the two NULL tags. Therefore, the certificate without the fix should be 4 bytes (5 > bytes if one byte alignment is applied) longer in length than the certificate with the fix. But the certificates included in the test are static and if one day we mistakenly add the NULL back it will not be detected by the test. My idea is to generate a cert on the fly inside the test so that can check the `derEncode` method in *this* JDK. As for checking if the NULL is there, you can try looking at the `DerUtils::shouldNotExist` method with "021" and "11" as arguments. ------------- PR: https://git.openjdk.java.net/jdk/pull/312 From weijun at openjdk.java.net Wed Sep 23 14:49:26 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 23 Sep 2020 14:49:26 GMT Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA Message-ID: Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274: - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms - A new JarSigner property "directsign" - Updating the jarsigner tool doc Major code changes: - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS. - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed ------------- Commit messages: - 8242068: Signed JAR support for RSASSA-PSS and EdDSA Changes: https://git.openjdk.java.net/jdk/pull/322/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242068 Stats: 1641 lines in 20 files changed: 930 ins; 548 del; 163 mod Patch: https://git.openjdk.java.net/jdk/pull/322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322 PR: https://git.openjdk.java.net/jdk/pull/322 From jpai at openjdk.java.net Wed Sep 23 15:42:06 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Sep 2020 15:42:06 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException In-Reply-To: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? > > As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds > the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This > is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is > larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the > `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent > this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the > necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which > reproduces the issue and verifies the fix. I had created a copy of this branch in my personal fork and included the `submit.yml` workflow as noted in this recent mail here[1] to try and run the `tier1` testing for this change. But it looks like that has failed for unrelated reasons[2]. So I'll go ahead and trigger the `tier1` tests locally instead. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] https://github.com/jaikiran/jdk/actions/runs/268948812 test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 60: > 58: final OutOfMemoryError oome = Assert.expectThrows(OutOfMemoryError.class, () -> jar.getManifest()); > 59: // additionally verify that the OOM was for the right/expected reason > 60: if (!"Required array size too large".equals(oome.getMessage())) { I wasn't too sure if I should add this additional check on the message of the `OutOfMemoryError`, but decided to do it anyway, given that from what I remember there were some discussions in the `core-libs-dev` list a while back on the exact messages that such OOMs should throw. So I guessed that it might be OK to rely on those messages in the tests within this project. However, I am open to removing specific check if it's considered unnecessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From jpai at openjdk.java.net Wed Sep 23 15:42:06 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Sep 2020 15:42:06 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException Message-ID: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which reproduces the issue and verifies the fix. ------------- Commit messages: - 8242882: opening jar file with large manifest might throw NegativeArraySizeException Changes: https://git.openjdk.java.net/jdk/pull/323/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=323&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242882 Stats: 88 lines in 2 files changed: 86 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/323/head:pull/323 PR: https://git.openjdk.java.net/jdk/pull/323 From bchristi at openjdk.java.net Wed Sep 23 16:51:46 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 23 Sep 2020 16:51:46 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 23 Sep 2020 15:12:58 GMT, Jaikiran Pai wrote: >> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? >> >> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds >> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This >> is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is >> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the >> `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent >> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the >> necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which >> reproduces the issue and verifies the fix. > > I had created a copy of this branch in my personal fork and included the `submit.yml` workflow as noted in this recent > mail here[1] to try and run the `tier1` testing for this change. But it looks like that has failed for unrelated > reasons[2]. So I'll go ahead and trigger the `tier1` tests locally instead. [1] > https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] > https://github.com/jaikiran/jdk/actions/runs/268948812 Hi, Jaikiran. I can sponsor this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From valeriep at openjdk.java.net Wed Sep 23 17:09:51 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Sep 2020 17:09:51 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 00:18:07 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > remove JDKOPT_DETECT_INTREE_EC from configure.ac src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 219: > 217: > 218: Collection supportedCurves; > 219: supportedCurves = CurveDB.getSupportedCurves(); Shouldn't the supportedCurves be the hardcoded 3 curves? ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From github.com+471021+marschall at openjdk.java.net Wed Sep 23 18:41:06 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 23 Sep 2020 18:41:06 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=04 Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From rriggs at openjdk.java.net Wed Sep 23 18:46:07 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Sep 2020 18:46:07 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v4] In-Reply-To: References: Message-ID: > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Cleanup of indeterminate length tag values and correct skipping of large tag-values. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/268/files - new: https://git.openjdk.java.net/jdk/pull/268/files/d56007bc..25115595 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=02-03 Stats: 50 lines in 1 file changed: 20 ins; 4 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From rriggs at openjdk.java.net Wed Sep 23 18:51:22 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 23 Sep 2020 18:51:22 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 00:19:53 GMT, Weijun Wang wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Small cleanups to javadoc and code > > test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 228: > >> 226: break; >> 227: >> 228: case TAG_OctetString: > > I'd rather print nothing for OCTET STRING. My understanding of it is opaque octets and not meant to be printable. Octet Strings can may contain printable strings and it is useful to print them. A heuristic is used to determine if they are printable and the length is limited to avoid spewing garbage. > test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 362: > >> 360: switch (tag & 0xc0) { >> 361: case TAG_APPLICATION: >> 362: return "APPLICATION " + cons + (tag & 0x1f); > > I am not sure how important it is to print out "cons". Also, the tag here is usually shown as "[1]" in ASN.1 > definition. Of course, if you choose this style, you might want to avoid using brackets for length. It provides a more complete info on the tag even though the application may not have publicly defined its values. ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From kvn at openjdk.java.net Wed Sep 23 18:55:29 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Sep 2020 18:55:29 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 18:41:06 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Update seems fine. Thanks for JFR testing and fixing. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/45 From kustos at gmx.net Wed Sep 23 18:40:22 2020 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 23 Sep 2020 20:40:22 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On 22.09.20 10:45, Erik Gahlin wrote: > On Sat, 12 Sep 2020 00:19:00 GMT, Vladimir Kozlov wrote: > >>> Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The >>> incremental views will show differences compared to the previous content of the PR. The pull request contains one new >>> commit since the last revision: >>> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate >> >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? I initially did not but now I have. jdk.jfr.event.runtime.TestModuleEvents was failing, I have updated it to what makes sense to me. Cheers Philippe From kustos at gmx.net Wed Sep 23 18:42:59 2020 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 23 Sep 2020 20:42:59 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On 23.09.20 07:13, David Holmes wrote: > On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: > >>> Marked as reviewed by kvn (Reviewer). >> >> Have you run the JFR tests in test/jdk/jdk/jfr? > > @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous > reviews/comments obsolete. There is no way for the reviewers to see what changed between the commit they reviewed and > the commit now in the PR. > > To update to latest changes you should have just merged your branch with your (up-to-date) local master, committed that > merge in your local branch and then pushed that commit to your Personal Fork. The skara tooling will flatten the series > of commits in a PR into one single well-formed commit that is pushed to the master branch of the repo. My apologies, I was not aware of this, I won't make this mistake in the future again. I don't assume there is a way to fix this now. Philippe From egahlin at openjdk.java.net Wed Sep 23 20:05:14 2020 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 23 Sep 2020 20:05:14 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 18:41:06 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From ascarpino at openjdk.java.net Wed Sep 23 22:27:34 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 23 Sep 2020 22:27:34 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: <8nr0RrYr-7cnjo4sSs9BpMWPCfFptjBDVu56hoDxl0U=.d5addb7e-5646-4f58-a5e7-29eda6cae1fc@github.com> References: <8nr0RrYr-7cnjo4sSs9BpMWPCfFptjBDVu56hoDxl0U=.d5addb7e-5646-4f58-a5e7-29eda6cae1fc@github.com> Message-ID: On Tue, 22 Sep 2020 13:53:12 GMT, Sean Mullan wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > src/jdk.crypto.ec/share/classes/sun/security/ec/ECDHKeyAgreement.java line 180: > >> 178: ((privNC != null) ? privNC.toString() : " unknown") + >> 179: ", PublicKey:" + >> 180: ((pubNC != null) ? pubNC.toString() : " unknown"))); > > Spacing issues: "PublicKey:" should be "PublicKey: " and " unknown" should be "unknown". After considering the keys closer, I don't need to specify the key anymore. PrivateKey and PublicKey were removed ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Wed Sep 23 22:27:34 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 23 Sep 2020 22:27:34 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v2] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 17:07:21 GMT, Valerie Peng wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> remove JDKOPT_DETECT_INTREE_EC from configure.ac > > src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java line 219: > >> 217: >> 218: Collection supportedCurves; >> 219: supportedCurves = CurveDB.getSupportedCurves(); > > Shouldn't the supportedCurves be the hardcoded 3 curves? Ah yes. Thanks for seeing that. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From kvn at openjdk.java.net Wed Sep 23 22:50:52 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Sep 2020 22:50:52 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 20:02:45 GMT, Erik Gahlin wrote: >> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains one commit: >> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Marked as reviewed by egahlin (Reviewer). @marschall I will sponsor it after you integrate the latest update. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From ascarpino at openjdk.java.net Wed Sep 23 23:38:03 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 23 Sep 2020 23:38:03 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: References: Message-ID: > This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: change exception for ec keyagreement fix supportedcurves in SunEC ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/289/files - new: https://git.openjdk.java.net/jdk/pull/289/files/8a04ce7a..1f9820ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=289&range=01-02 Stats: 20 lines in 3 files changed: 4 ins; 10 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/289.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/289/head:pull/289 PR: https://git.openjdk.java.net/jdk/pull/289 From jai.forums2013 at gmail.com Thu Sep 24 07:04:57 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 24 Sep 2020 12:34:57 +0530 Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: Hello Brent, Thank you for sponsoring this change. In the meantime, I triggered the pre-submit GitHub action job to run the "tier1" tests for a duplicate branch of this PR. That completed successfully https://github.com/jaikiran/jdk/actions/runs/269960940. I'll wait for the reviews, before initiating any /integrate command. -Jaikiran On 23/09/20 10:21 pm, Brent Christian wrote: > On Wed, 23 Sep 2020 15:12:58 GMT, Jaikiran Pai wrote: > >>> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? >>> >>> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds >>> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This >>> is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is >>> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the >>> `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent >>> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the >>> necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which >>> reproduces the issue and verifies the fix. >> I had created a copy of this branch in my personal fork and included the `submit.yml` workflow as noted in this recent >> mail here[1] to try and run the `tier1` testing for this change. But it looks like that has failed for unrelated >> reasons[2]. So I'll go ahead and trigger the `tier1` tests locally instead. [1] >> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2] >> https://github.com/jaikiran/jdk/actions/runs/268948812 > Hi, Jaikiran. I can sponsor this change. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/323 From kim.barrett at oracle.com Thu Sep 24 08:59:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Sep 2020 04:59:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> Message-ID: <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> > On Sep 23, 2020, at 2:10 AM, Eric Liu wrote: > > Hi Kim, > > Sorry for the delay. > > This patch removes a redundant string copy in NetworkInterface.c to avoid string-truncation > warning. Other warnings we talked before, which are unable to completely fix in different version > of gcc, I have to use pragma to suppress them as a workaround. > > This patch now could compile with gcc-7, gcc-8, gcc-9, gcc-10 both with or without asan. > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8252407 If possible, my preference would be to avoid the pragma cruft and write the code in such a way that gcc8/9 without asan doesn't warn, and gcc10 doesn't warn with or without asan. I've kind of lost track in the discussion of all the variants whether that's actually feasible. From Alan.Bateman at oracle.com Thu Sep 24 09:32:05 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Sep 2020 10:32:05 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: On 24/09/2020 09:59, Kim Barrett wrote: > If possible, my preference would be to avoid the pragma cruft and write the > code in such a way that gcc8/9 without asan doesn't warn, and gcc10 doesn't > warn with or without asan. I've kind of lost track in the discussion of all > the variants whether that's actually feasible. > > I agree, the program cruft in NetworkInterface.c is unmaintainable and not the right place for it. -Alan. From bchristi at openjdk.java.net Thu Sep 24 16:40:36 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 24 Sep 2020 16:40:36 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException In-Reply-To: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai wrote: > Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? > > As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds > the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This > is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is > larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the > `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent > this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the > necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which > reproduces the issue and verifies the fix. Changes requested by bchristi (Reviewer). src/java.base/share/classes/java/util/jar/JarFile.java line 791: > 789: private byte[] getBytes(ZipEntry ze) throws IOException { > 790: try (InputStream is = super.getInputStream(ze)) { > 791: int len = (int)ze.getSize(); I think the main issue is the casting of the 'long' value from ZipEntry.getSize() into an 'int'. I think checking if the size is > the maximum array size and throwing an OOME here might be a sufficient fix on its own. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From weijun at openjdk.java.net Thu Sep 24 20:44:56 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 24 Sep 2020 20:44:56 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: References: Message-ID: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> On Wed, 23 Sep 2020 23:38:03 GMT, Anthony Scarpino wrote: >> This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files >> associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The >> SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will >> remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, >> secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, >> sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, >> sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, >> X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 >> prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > change exception for ec keyagreement > fix supportedcurves in SunEC src/java.base/share/conf/security/java.security line 636: > 634: # > 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ > 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 `jdk.disabled.namedCurves` still exists. If someone decides to add a curve there, shouldn't it be also disabled here? ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Thu Sep 24 21:19:05 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 24 Sep 2020 21:19:05 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> References: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> Message-ID: <4NaHde8FhqOKFtSMByp6WSZuB0xEM1i4COfU2w-NdCM=.15c29dce-df92-486c-a567-c7b764b1fe63@github.com> On Thu, 24 Sep 2020 19:48:45 GMT, Weijun Wang wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> change exception for ec keyagreement >> fix supportedcurves in SunEC > > src/java.base/share/conf/security/java.security line 636: > >> 634: # >> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ >> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 > > `jdk.disabled.namedCurves` still exists. If someone decides to add a curve there, shouldn't it be also disabled here? jdk.disabled.namedCurves is commented out and I don't think it's good for every operation disabled algorithms call to check an empty property. The description for the disabledAlgorithm properties say you have to use "include", so I don't think it is necessary to we keep it active.. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From weijun at openjdk.java.net Thu Sep 24 21:40:07 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 24 Sep 2020 21:40:07 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: <4NaHde8FhqOKFtSMByp6WSZuB0xEM1i4COfU2w-NdCM=.15c29dce-df92-486c-a567-c7b764b1fe63@github.com> References: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> <4NaHde8FhqOKFtSMByp6WSZuB0xEM1i4COfU2w-NdCM=.15c29dce-df92-486c-a567-c7b764b1fe63@github.com> Message-ID: <0fVNVOSd-7OZnI9Pj_CxoIcGT2Guv47FXy2N6cQDNmg=.e035384e-66d0-4b18-b9dd-3c5146e2b000@github.com> On Thu, 24 Sep 2020 21:15:34 GMT, Anthony Scarpino wrote: >> src/java.base/share/conf/security/java.security line 636: >> >>> 634: # >>> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \ >>> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224 >> >> `jdk.disabled.namedCurves` still exists. If someone decides to add a curve there, shouldn't it be also disabled here? > > jdk.disabled.namedCurves is commented out and I don't think it's good for every operation disabled algorithms call to > check an empty property. The description for the disabledAlgorithm properties say you have to use "include", so I > don't think it is necessary to we keep it active.. I just think this is an unnecessary behavior change. After all, the purpose of `jdk.disabled.namedCurves` is to be included in other disabledAlgorithms properties. No strong opinion on this. Please decide yourself. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From ascarpino at openjdk.java.net Thu Sep 24 21:52:53 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 24 Sep 2020 21:52:53 GMT Subject: RFR: 8235710: Remove the legacy elliptic curves [v3] In-Reply-To: <0fVNVOSd-7OZnI9Pj_CxoIcGT2Guv47FXy2N6cQDNmg=.e035384e-66d0-4b18-b9dd-3c5146e2b000@github.com> References: <-ljn2FU7DqIvcoKq3qO-yYHZNEU9rqJek3S4z8Ha7sQ=.c9175e31-2b48-432f-912e-2367079a92df@github.com> <4NaHde8FhqOKFtSMByp6WSZuB0xEM1i4COfU2w-NdCM=.15c29dce-df92-486c-a567-c7b764b1fe63@github.com> <0fVNVOSd-7OZnI9Pj_CxoIcGT2Guv47FXy2N6cQDNmg=.e035384e-66d0-4b18-b9dd-3c5146e2b000@github.com> Message-ID: On Thu, 24 Sep 2020 21:37:14 GMT, Weijun Wang wrote: >> jdk.disabled.namedCurves is commented out and I don't think it's good for every operation disabled algorithms call to >> check an empty property. The description for the disabledAlgorithm properties say you have to use "include", so I >> don't think it is necessary to we keep it active.. > > I just think this is an unnecessary behavior change. After all, the purpose of `jdk.disabled.namedCurves` is to be > included in other disabledAlgorithms properties. > No strong opinion on this. Please decide yourself. I understand what you are saying. The property only existed because there were so many curves that would have overwhelmed the disabledAlgorithms. I also don't like making this a permanent addition to the disabledAlgorithm properties. It's possible we may remove the property in the future as it's likely unnecessary going forward. ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From hchao at openjdk.java.net Thu Sep 24 23:49:08 2020 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 24 Sep 2020 23:49:08 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier [v2] In-Reply-To: References: Message-ID: > This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a > Null tag. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Updated test case to use DerUtils ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/312/files - new: https://git.openjdk.java.net/jdk/pull/312/files/f52268a7..edc71d03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=312&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=312&range=00-01 Stats: 189 lines in 1 file changed: 35 ins; 132 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/312/head:pull/312 PR: https://git.openjdk.java.net/jdk/pull/312 From weijun at openjdk.java.net Fri Sep 25 00:47:47 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 25 Sep 2020 00:47:47 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier [v2] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 23:49:08 GMT, Hai-May Chao wrote: >> This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a >> Null tag. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Updated test case to use DerUtils src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 214: > 212: || algid.equals(SHA512withECDSA_oid)) { > 213: // RFC 4055 3.3: when an RSASSA-PSS key does not require > 214: // parameter validation, field is absent. Would you like to add more comments on other RFCs here? ------------- PR: https://git.openjdk.java.net/jdk/pull/312 From ascarpino at openjdk.java.net Fri Sep 25 02:42:57 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 25 Sep 2020 02:42:57 GMT Subject: Integrated: 8235710: Remove the legacy elliptic curves In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 21:10:58 GMT, Anthony Scarpino wrote: > This change removes the native elliptic curves library code; as well as, and calls to that code, tests, and files > associated with those libraries. The makefiles have been changed to remove from all source builds of the ec code. The > SunEC system property is removed and java.security configurations changed to reflect the removed curves. This will > remove the following elliptic curves from SunEC: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, > secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, > sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, > X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 > prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1 This pull request has now been integrated. Changeset: 0b83fc01 Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/0b83fc01 Stats: 20155 lines in 77 files changed: 28 ins; 20048 del; 79 mod 8235710: Remove the legacy elliptic curves Reviewed-by: xuelei, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/289 From hchao at openjdk.java.net Fri Sep 25 04:21:04 2020 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 25 Sep 2020 04:21:04 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier [v3] In-Reply-To: References: Message-ID: > This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a > Null tag. Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: Added comment for RFC ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/312/files - new: https://git.openjdk.java.net/jdk/pull/312/files/edc71d03..4f4e3688 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=312&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=312&range=01-02 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/312/head:pull/312 PR: https://git.openjdk.java.net/jdk/pull/312 From hchao at openjdk.java.net Fri Sep 25 04:21:05 2020 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 25 Sep 2020 04:21:05 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier [v2] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 00:45:09 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated test case to use DerUtils > > src/java.base/share/classes/sun/security/x509/AlgorithmId.java line 214: > >> 212: || algid.equals(SHA512withECDSA_oid)) { >> 213: // RFC 4055 3.3: when an RSASSA-PSS key does not require >> 214: // parameter validation, field is absent. > > Would you like to add more comments on other RFCs here? Added the comments for RFC reference. ------------- PR: https://git.openjdk.java.net/jdk/pull/312 From abakhtin at openjdk.java.net Fri Sep 25 07:29:32 2020 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Fri, 25 Sep 2020 07:29:32 GMT Subject: Integrated: 8245527: LDAP Channel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote: > Hi, > > Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. > Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html > This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is > "tls-server-end-point" > CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 > > Thank you > Alexey This pull request has now been integrated. Changeset: cfa3f749 Author: Alexey Bakhtin URL: https://git.openjdk.java.net/jdk/commit/cfa3f749 Stats: 543 lines in 10 files changed: 531 ins; 0 del; 12 mod 8245527: LDAP Channel Binding support for Java GSS/Kerberos Reviewed-by: dfuchs, aefimov, mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/278 From weijun at openjdk.java.net Fri Sep 25 13:17:16 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 25 Sep 2020 13:17:16 GMT Subject: RFR: 8252377: Incorrect encoding for EC AlgorithmIdentifier [v3] In-Reply-To: References: Message-ID: <-29AEvy0FO4smagfnXRmsn07fpJMjjgCd1pwyL2NCIc=.defc772f-aaf4-48d0-9666-52ec06d4639f@github.com> On Fri, 25 Sep 2020 04:21:04 GMT, Hai-May Chao wrote: >> This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a >> Null tag. > > Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: > > Added comment for RFC Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/312 From ascarpino at openjdk.java.net Fri Sep 25 19:06:27 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 25 Sep 2020 19:06:27 GMT Subject: RFR: 8253637: Update EC removal Message-ID: Hi, I need a quick review for two changes. The primary is a failure that shows up on linux-aarch64 because the systems do not have NSS. The default was to allow all curves tested, which before the native library removal was ok. The second was a missed changeset that got left in the local repo that helped find the curve name on an exception message. Thanks Tony ------------- Commit messages: - 8253637: Update EC removal - left behind message change Changes: https://git.openjdk.java.net/jdk/pull/366/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=366&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253637 Stats: 6 lines in 3 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/366.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/366/head:pull/366 PR: https://git.openjdk.java.net/jdk/pull/366 From dcubed at openjdk.java.net Fri Sep 25 19:30:03 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 19:30:03 GMT Subject: RFR: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 17:15:01 GMT, Daniel D. Daugherty wrote: > Reduce noise in CI Tier2 by ProblemListing this test. My Tier2 test job ran sun/security/ec/TestEC.java on all regular Oracle platforms except for linux-aarch64. I also updated the generic-ARCH header comment to include 'aarch64' in the list so folks don't have to wonder whether to use 'aarch64' or 'arm' or 'arm64'. ------------- PR: https://git.openjdk.java.net/jdk/pull/362 From dcubed at openjdk.java.net Fri Sep 25 19:30:03 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 19:30:03 GMT Subject: RFR: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 Message-ID: Reduce noise in CI Tier2 by ProblemListing this test. ------------- Commit messages: - Add 'aarch64' to the generic-ARCH comment so folks know what to use. - Use the correct bug ID: 8253637. - 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 Changes: https://git.openjdk.java.net/jdk/pull/362/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=362&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253659 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/362.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/362/head:pull/362 PR: https://git.openjdk.java.net/jdk/pull/362 From iklam at openjdk.java.net Fri Sep 25 19:35:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 19:35:56 GMT Subject: RFR: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 In-Reply-To: References: Message-ID: <6NJpEia398_KuMI-K8RAhX0fbhw7jvPtqne2VVerEvY=.5d728aae-b091-4272-89b1-d46c75fb97e6@github.com> On Fri, 25 Sep 2020 17:15:01 GMT, Daniel D. Daugherty wrote: > Reduce noise in CI Tier2 by ProblemListing this test. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/362 From iklam at openjdk.java.net Fri Sep 25 19:35:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 19:35:56 GMT Subject: RFR: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 In-Reply-To: <6NJpEia398_KuMI-K8RAhX0fbhw7jvPtqne2VVerEvY=.5d728aae-b091-4272-89b1-d46c75fb97e6@github.com> References: <6NJpEia398_KuMI-K8RAhX0fbhw7jvPtqne2VVerEvY=.5d728aae-b091-4272-89b1-d46c75fb97e6@github.com> Message-ID: On Fri, 25 Sep 2020 19:31:36 GMT, Ioi Lam wrote: >> Reduce noise in CI Tier2 by ProblemListing this test. > > Marked as reviewed by iklam (Reviewer). Looks like a trivial change to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/362 From dcubed at openjdk.java.net Fri Sep 25 19:42:34 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 19:42:34 GMT Subject: RFR: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 In-Reply-To: References: <6NJpEia398_KuMI-K8RAhX0fbhw7jvPtqne2VVerEvY=.5d728aae-b091-4272-89b1-d46c75fb97e6@github.com> Message-ID: On Fri, 25 Sep 2020 19:32:57 GMT, Ioi Lam wrote: >> Marked as reviewed by iklam (Reviewer). > > Looks like a trivial change to me. @iklam - thanks for the fast review. ------------- PR: https://git.openjdk.java.net/jdk/pull/362 From dcubed at openjdk.java.net Fri Sep 25 19:42:34 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 19:42:34 GMT Subject: Integrated: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 17:15:01 GMT, Daniel D. Daugherty wrote: > Reduce noise in CI Tier2 by ProblemListing this test. This pull request has now been integrated. Changeset: 9150b902 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/9150b902 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/362 From anthony.scarpino at oracle.com Fri Sep 25 19:44:49 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 25 Sep 2020 12:44:49 -0700 Subject: RFR: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 In-Reply-To: References: Message-ID: <8be53405-6b1d-a7d9-f012-7a7f5e6cd97f@oracle.com> I had the fix in review if you could have waited. Tony On 9/25/20 12:30 PM, Daniel D.Daugherty wrote: > Reduce noise in CI Tier2 by ProblemListing this test. > > ------------- > > Commit messages: > - Add 'aarch64' to the generic-ARCH comment so folks know what to use. > - Use the correct bug ID: 8253637. > - 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 > > Changes: https://git.openjdk.java.net/jdk/pull/362/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=362&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253659 > Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/362.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/362/head:pull/362 > > PR: https://git.openjdk.java.net/jdk/pull/362 > From hchao at openjdk.java.net Fri Sep 25 19:50:56 2020 From: hchao at openjdk.java.net (Hai-May Chao) Date: Fri, 25 Sep 2020 19:50:56 GMT Subject: Integrated: 8252377: Incorrect encoding for EC AlgorithmIdentifier In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 22:21:20 GMT, Hai-May Chao wrote: > This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the parameters field instead of encoding a > Null tag. This pull request has now been integrated. Changeset: 0e855fe5 Author: Hai-May Chao Committer: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/0e855fe5 Stats: 125 lines in 2 files changed: 124 ins; 0 del; 1 mod 8252377: Incorrect encoding for EC AlgorithmIdentifier Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/312 From ascarpino at openjdk.java.net Fri Sep 25 19:57:49 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 25 Sep 2020 19:57:49 GMT Subject: RFR: 8253637: Update EC removal [v2] In-Reply-To: References: Message-ID: > Hi, > > I need a quick review for two changes. The primary is a failure that shows up on linux-aarch64 because the systems do > not have NSS. The default was to allow all curves tested, which before the native library removal was ok. The second > was a missed changeset that got left in the local repo that helped find the curve name on an exception message. Thanks > > Tony Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'ecfix' of github.com:ascarpino/jdk into ecfix - 8253637: Update EC removal - left behind message change - remove problem list entry - 8253637: Update EC removal - left behind message change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/366/files - new: https://git.openjdk.java.net/jdk/pull/366/files/eff89cf0..3c1cc898 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=366&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=366&range=00-01 Stats: 126 lines in 3 files changed: 124 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/366.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/366/head:pull/366 PR: https://git.openjdk.java.net/jdk/pull/366 From dcubed at openjdk.java.net Fri Sep 25 20:11:48 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 20:11:48 GMT Subject: RFR: 8253659: ProblemList sun/security/ec/TestEC.java on linux-aarch64 In-Reply-To: References: <6NJpEia398_KuMI-K8RAhX0fbhw7jvPtqne2VVerEvY=.5d728aae-b091-4272-89b1-d46c75fb97e6@github.com> Message-ID: On Fri, 25 Sep 2020 19:37:25 GMT, Daniel D. Daugherty wrote: >> Looks like a trivial change to me. > > @iklam - thanks for the fast review. Tony - sorry about that. The last time I checked your bug (about 2 hours ago) it wasn't "in progress". Please update your fix to remove the test from the ProblemList. ------------- PR: https://git.openjdk.java.net/jdk/pull/362 From dcubed at openjdk.java.net Fri Sep 25 20:41:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 20:41:10 GMT Subject: RFR: 8253637: Update EC removal In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 18:56:00 GMT, Anthony Scarpino wrote: > Hi, > > I need a quick review for two changes. The primary is a failure that shows up on linux-aarch64 because the systems do > not have NSS. The default was to allow all curves tested, which before the native library removal was ok. The second > was a missed changeset that got left in the local repo that helped find the curve name on an exception message. Thanks > > Tony @ascarpino - Thanks for removing the ProblemList entry that I added with JDK-8253659. I did check the status of your bug (JDK-8253637) but apparently I did that just before you started working on it today (about 1400 ET was the last time I checked it). My apologies. ------------- PR: https://git.openjdk.java.net/jdk/pull/366 From ascarpino at openjdk.java.net Fri Sep 25 20:49:15 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Fri, 25 Sep 2020 20:49:15 GMT Subject: RFR: 8253637: Update EC removal In-Reply-To: References: Message-ID: <59r74dJoQJ3Ov8z5BPJ5rMAf8Imn4eKQ_ODDcy-yzaA=.4398fd9f-0b61-4a1c-a5ca-9b63aaed7414@github.com> On Fri, 25 Sep 2020 20:38:12 GMT, Daniel D. Daugherty wrote: >> Hi, >> >> I need a quick review for two changes. The primary is a failure that shows up on linux-aarch64 because the systems do >> not have NSS. The default was to allow all curves tested, which before the native library removal was ok. The second >> was a missed changeset that got left in the local repo that helped find the curve name on an exception message. Thanks >> >> Tony > > @ascarpino - Thanks for removing the ProblemList entry that I added > with JDK-8253659. I did check the status of your bug (JDK-8253637) > but apparently I did that just before you started working on it today > (about 1400 ET was the last time I checked it). > > My apologies. @dcubed-ojdk That's ok. I had been working on it all morning (PT). If I realized you were looking at the bug status I would have changed it right away. Though given my PR has been sitting for a while, maybe on the list was for the best. ------------- PR: https://git.openjdk.java.net/jdk/pull/366 From valeriep at openjdk.java.net Fri Sep 25 21:30:48 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 25 Sep 2020 21:30:48 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Fri, 18 Sep 2020 21:25:28 GMT, Weijun Wang wrote: >> This code change rewrites DerValue into a mostly immutable class and simplifies DerInputStream as a wrapper for a >> series of DerValues objects. DerInputBuffer is removed. >> All existing methods of DerValue and DerInputStream should still work with the exact same behavior, except for a few >> places where bugs are fixed. For example, Indefinite length must be used with a constructed tag. >> Except for the ObjectIdentifier class where DerInputBuffer is directly referenced, no other code is touched. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > Enhance DerValue::getOctetString to be able to read multi-level constructed value. src/java.base/share/classes/sun/security/util/DerInputStream.java line 69: > 67: int mark; > 68: > 69: public DerInputStream(byte[] data, int start, int length, boolean allowBER) { Add javadoc for the new impl? Do we need to validate things like data != null, start and length have valid values? Or assuming that since all its callers are internal, no need to check. src/java.base/share/classes/sun/security/util/DerInputStream.java line 100: > 98: * @return the read DerValue. > 99: * @throws IOException if a DerValue cannot be constructed starting from this position > 100: * because of byte shortage or encoding error. Add javadoc for the new impl? src/java.base/share/classes/sun/security/util/DerInputStream.java line 90: > 88: } > 89: > 90: public byte[] toByteArray() { Add javadoc? Returns the remaining unread bytes? The name may lead people to expect the bytes returned are the one passing to the constructor. src/java.base/share/classes/sun/security/util/DerInputStream.java line 62: > 60: final byte[] data; > 61: final int start; > 62: final int end; Well, end is really "start + length", the data range is from start to (end -1) (inclusive). src/java.base/share/classes/sun/security/util/DerInputStream.java line 103: > 101: */ > 102: public DerValue getDerValue() throws IOException { > 103: DerValue result = new DerValue( Check (this.end - this.pos > 0) before calling DerValue()? src/java.base/share/classes/sun/security/util/DerInputStream.java line 139: > 137: // does not accept constructed OCTET STRING. > 138: DerValue v = getDerValue(); > 139: if (v.tag != DerValue.tag_OctetString) { Only this method checks tag of the DerValue? src/java.base/share/classes/sun/security/util/DerInputStream.java line 280: > 278: * a later call to reset will return here. > 279: */ > 280: public void mark(int value) { mark = pos; } This seems very strange, having an int argument which is not used? src/java.base/share/classes/sun/security/util/DerInputStream.java line 207: > 205: } > 206: > 207: static int getLength(InputStream in) throws IOException { This and other getLength(...) methods seems out-of-place with the new implementation code? test/jdk/sun/security/util/DerValue/DeepOctets.java line 56: > 54: Utils.runAndCheckException( > 55: () -> new DerInputStream(input).getOctetString(), > 56: IOException.class); It seems that the existing impl already differs and you are just adding a regression test to highlight the difference, right? src/java.base/share/classes/sun/security/util/DerValue.java line 163: > 161: // should call withTag() or data() instead (do not use the data field). > 162: > 163: public /*final*/ byte tag; Conceptually, the class is far from immutable if the tag is public and non-final. Any caller could have changed the tag value. Is it that we are keeping all public fields/methods the same for max compatibility-sake? It'd be nice if it can be real immutable. src/java.base/share/classes/sun/security/util/DerValue.java line 170: > 168: > 169: // Unsafe. Legacy. Never null. > 170: final public DerInputStream data; nit: public final for sake of consistency? If not meant to be used anymore, mark it clearly across all relevant methods with deprecated javadoc tag? src/java.base/share/classes/sun/security/util/DerValue.java line 294: > 292: > 293: /** > 294: * Parse an ASN.1/BER encoded datum from a byte array. DER instead of BER? src/java.base/share/classes/sun/security/util/DerValue.java line 284: > 282: > 283: /** > 284: * Parse an ASN.1/BER encoded datum. The entire encoding must hold exactly Are you intentionally put BER here because allowBER=true? src/java.base/share/classes/sun/security/util/DerValue.java line 301: > 299: * @param allowBER whether BER is allowed > 300: * @param allowMore whether extra bytes are allowed after the encoded datum. > 301: * If true, {@code len} can be bigger than the length og typo: og =>of? src/java.base/share/classes/sun/security/util/DerValue.java line 305: > 303: * > 304: * @throws IOException if it's an invalid encoding or there are extra bytes > 305: * after the encoded datum but {@code allowMore} is false. but => and or when? src/java.base/share/classes/sun/security/util/DerValue.java line 318: > 316: > 317: int length; > 318: if (lenByte == (byte)0x80) { Add comment for this being the indefinite case? src/java.base/share/classes/sun/security/util/DerValue.java line 322: > 320: } else if ((lenByte & 0x080) == 0x00) { // short form, 1 byte datum > 321: length = lenByte; > 322: } else { // long form or indefinite This should just the long form. Isn't the indefinite case covered by the first if-check? src/java.base/share/classes/sun/security/util/DerValue.java line 325: > 323: lenByte &= 0x07f; > 324: if (lenByte == 0) { > 325: length = -1; This should never happen given the first if-check? There is a lot of duplicated code (line 318-348)with the various length-parsing methods in DerInputStream class. Have you considered consolidating them? It seems that you are keeping track of the pos value for the subsequent "Too-little"/"Too much" checks. Is "allowMore" really used? If "allowBER" is false, could "allowMore" be true? src/java.base/share/classes/sun/security/util/DerValue.java line 226: > 224: this.end = end; > 225: this.allowBER = allowBER; > 226: this.data = new DerInputStream(this); this.data used to just contain the "value" part of the DerValue, now it's the whole DerValue (including tag and length in addition to value). Is its usage still compatible? src/java.base/share/classes/sun/security/util/DerValue.java line 446: > 444: } > 445: > 446: public final DerInputStream getData() { Mark this method as deprecated javadoc tag? Is it possible to just change this method impl with the new impl under data()? The data field is already public, can't we just update the impl of this method? Having the data field, getData() method and now data() looks very confusing. src/java.base/share/classes/sun/security/util/DerValue.java line 584: > 582: } > 583: // TODO > 584: return new BigInteger(1, buffer, start, end - start).intValue(); More info for what to do? - // TODO Enumerated is just integer, is there any spec/doc saying it's non-negative? All I can find is just integer. src/java.base/share/classes/sun/security/util/DerValue.java line 638: > 636: } > 637: if (end == start) { > 638: throw new IOException("No padding"); Well, I find the original error message is clearer: Invalid encoding: zero length bit string. Just the "No padding" may be somewhat unclear since no padding is needed when it's multiple of 8. Or, maybe something like "DerValue.getBitString, empty value". src/java.base/share/classes/sun/security/util/DerValue.java line 670: > 668: } > 669: if (end == start) { > 670: throw new IOException("No padding"); Same as above comment regarding "No Padding". src/java.base/share/classes/sun/security/util/DerValue.java line 675: > 673: if (end == start + 1) { > 674: return new BitArray(0); > 675: } else { This is different from the existing impl in DerInputBuffer.getUnalignedBitString() which throws IOException if the numberOfPadBits is invalid. It's also different from the getBitString() impl in this PR where the numOfPadBits is still checked. Is this difference in behavior intentional? src/java.base/share/classes/sun/security/util/DerValue.java line 680: > 678: throw new IOException("Invalid number of padding bits"); > 679: } > 680: return new BitArray((end - start - 1) * 8 - numOfPadBits, << 3 src/java.base/share/classes/sun/security/util/DerValue.java line 768: > 766: */ > 767: public String getUniversalString() throws IOException { > 768: return readStringInternal(tag_UniversalString, new UTF_32BE()); It looks like UTF_32BE now is always supported? If yes, perhaps adding a constant for it just like for other charsets? Also the "return" javadoc tag for this method needs to be updated? src/java.base/share/classes/sun/security/util/DerValue.java line 976: > 974: throw new IOException("DER UTC Time length error"); > 975: } > 976: } nit: add a javadoc for this like other public methods of this class. nit: move getNull() up before getTime() so all the time-related methods are together. The IOException messages in this method has UTC Time related words, maybe copy-n-paste error? src/java.base/share/classes/sun/security/util/DerValue.java line 777: > 775: * if UTC Time is to be read. > 776: */ > 777: private Date getTime(int len, boolean generalized) throws IOException { You have the Internal suffix on other private helper routines. Maybe add it here as well? src/java.base/share/classes/sun/security/util/DerValue.java line 991: > 989: > 990: data.pos = data.end; // Compatibility. Reach end. > 991: return getTime(end - start, false); Given that getTime() have access to all the fields, it seems redundant to have to specify (end-start) when calling it. src/java.base/share/classes/sun/security/util/DerValue.java line 1043: > 1041: @Override > 1042: public String toString() { > 1043: return String.format("DerValue(%02x, %s, %d, 5d)", 5d should be %d? src/java.base/share/classes/sun/security/util/DerValue.java line 1154: > 1152: * @return a new DerValue > 1153: */ > 1154: public DerValue withTag(byte newTag) { Seems like a somewhat dangerous method. The value may not match the new tag? The caller is expected to know what it's doing? src/java.base/share/classes/sun/security/util/DerValue.java line 1173: > 1171: > 1172: DerValue[] subs(byte expectedTag, int startLen) throws IOException { > 1173: if (expectedTag != 0 && expectedTag != tag) { so if expectedTag == 0, then we don't check for tag match? Looks strange. If this is intentional, we should add comment to clarify why. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Fri Sep 25 21:30:49 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Fri, 25 Sep 2020 21:30:49 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Fri, 25 Sep 2020 02:38:40 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> Enhance DerValue::getOctetString to be able to read multi-level constructed value. > > src/java.base/share/classes/sun/security/util/DerValue.java line 638: > >> 636: } >> 637: if (end == start) { >> 638: throw new IOException("No padding"); > > Well, I find the original error message is clearer: Invalid encoding: zero length bit string. Just the "No padding" may > be somewhat unclear since no padding is needed when it's multiple of 8. Or, maybe something like > "DerValue.getBitString, empty value". It also seems strange that it only checks that length !=0. The spec of BitString seems to suggest the length must be >=2 where the first byte is the number of padding bits. It seems that the right check should be (end - start) > 1? ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From weijun at openjdk.java.net Sat Sep 26 01:00:21 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 26 Sep 2020 01:00:21 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Sat, 19 Sep 2020 00:36:23 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> Enhance DerValue::getOctetString to be able to read multi-level constructed value. > > src/java.base/share/classes/sun/security/util/DerInputStream.java line 62: > >> 60: final byte[] data; >> 61: final int start; >> 62: final int end; > > Well, end is really "start + length", the data range is from start to (end -1) (inclusive). Will add some comments. > src/java.base/share/classes/sun/security/util/DerInputStream.java line 69: > >> 67: int mark; >> 68: >> 69: public DerInputStream(byte[] data, int start, int length, boolean allowBER) { > > Add javadoc for the new impl? Do we need to validate things like data != null, start and length have valid values? Or > assuming that since all its callers are internal, no need to check. I don't intend to add any check because callers are internal. I can add a comment. > src/java.base/share/classes/sun/security/util/DerInputStream.java line 100: > >> 98: * @return the read DerValue. >> 99: * @throws IOException if a DerValue cannot be constructed starting from this position >> 100: * because of byte shortage or encoding error. > > Add javadoc for the new impl? OK. > src/java.base/share/classes/sun/security/util/DerInputStream.java line 90: > >> 88: } >> 89: >> 90: public byte[] toByteArray() { > > Add javadoc? Returns the remaining unread bytes? The name may lead people to expect the bytes returned are the one > passing to the constructor. Well. This method is sometimes used to read remaining bytes and sometimes used to read all (suppose none has been read yet). I will clarify. > src/java.base/share/classes/sun/security/util/DerInputStream.java line 103: > >> 101: */ >> 102: public DerValue getDerValue() throws IOException { >> 103: DerValue result = new DerValue( > > Check (this.end - this.pos > 0) before calling DerValue()? new DerValue() would fail in this case. > src/java.base/share/classes/sun/security/util/DerInputStream.java line 139: > >> 137: // does not accept constructed OCTET STRING. >> 138: DerValue v = getDerValue(); >> 139: if (v.tag != DerValue.tag_OctetString) { > > Only this method checks tag of the DerValue? Yes, this is because `DerValue::getOctetString` allows constructed value but `DerInputStream::getOctetString` only accepts primitive value. This is for compatibility. All other methods will have tag checked inside the corresponding DerValue method. Do you prefer a fast fail? > src/java.base/share/classes/sun/security/util/DerInputStream.java line 207: > >> 205: } >> 206: >> 207: static int getLength(InputStream in) throws IOException { > > This and other getLength(...) methods seems out-of-place with the new implementation code? Yes, I should do some refactoring. Both methods are internal (to these 2 classes). > src/java.base/share/classes/sun/security/util/DerInputStream.java line 280: > >> 278: * a later call to reset will return here. >> 279: */ >> 280: public void mark(int value) { mark = pos; } > > This seems very strange, having an int argument which is not used? `ByteArrayInoutStream::mark` also does this. When the data is all there and no need to decide how many to remember, this argument is useless. I'll rename it to dummy. > src/java.base/share/classes/sun/security/util/DerValue.java line 163: > >> 161: // should call withTag() or data() instead (do not use the data field). >> 162: >> 163: public /*final*/ byte tag; > > Conceptually, the class is far from immutable if the tag is public and non-final. Any caller could have changed the tag > value. Is it that we are keeping all public fields/methods the same for max compatibility-sake? It'd be nice if it can > be real immutable. Yes, I should have said that this class can be used as an immutable class if you do not use this and that. We will decide if we can remove those usages and make this really immutable in the future. > src/java.base/share/classes/sun/security/util/DerValue.java line 170: > >> 168: >> 169: // Unsafe. Legacy. Never null. >> 170: final public DerInputStream data; > > nit: public final for sake of consistency? If not meant to be used anymore, mark it clearly across all relevant methods > with deprecated javadoc tag? public for compatibility, and final because it won't need to change. I'll see how many `@deprecated` I can add. Or, I'll see if I can move all will-be-deprecated code together. > src/java.base/share/classes/sun/security/util/DerValue.java line 226: > >> 224: this.end = end; >> 225: this.allowBER = allowBER; >> 226: this.data = new DerInputStream(this); > > this.data used to just contain the "value" part of the DerValue, now it's the whole DerValue (including tag and length > in addition to value). Is its usage still compatible? The constructor `DerInputStream(DerValue)` has not read tag at all. I can rewrite it the last line to `new DerInputStream(buffer, start, end - start, allowBER)`. > src/java.base/share/classes/sun/security/util/DerValue.java line 284: > >> 282: >> 283: /** >> 284: * Parse an ASN.1/BER encoded datum. The entire encoding must hold exactly > > Are you intentionally put BER here because allowBER=true? Yes. In fact I'm not quite confident on our usage of allowBER. In a lot of cases we are actually quite strict. Since this code change is meant to be a refactoring and does not intend to fix many things, I don't intent to make many behavior change. > src/java.base/share/classes/sun/security/util/DerValue.java line 294: > >> 292: >> 293: /** >> 294: * Parse an ASN.1/BER encoded datum from a byte array. > > DER instead of BER? There is allowBER, so BER. > src/java.base/share/classes/sun/security/util/DerValue.java line 301: > >> 299: * @param allowBER whether BER is allowed >> 300: * @param allowMore whether extra bytes are allowed after the encoded datum. >> 301: * If true, {@code len} can be bigger than the length og > > typo: og =>of? Oops. > src/java.base/share/classes/sun/security/util/DerValue.java line 305: > >> 303: * >> 304: * @throws IOException if it's an invalid encoding or there are extra bytes >> 305: * after the encoded datum but {@code allowMore} is false. > > but => and or when? and. > src/java.base/share/classes/sun/security/util/DerValue.java line 318: > >> 316: >> 317: int length; >> 318: if (lenByte == (byte)0x80) { > > Add comment for this being the indefinite case? Sure. > src/java.base/share/classes/sun/security/util/DerValue.java line 322: > >> 320: } else if ((lenByte & 0x080) == 0x00) { // short form, 1 byte datum >> 321: length = lenByte; >> 322: } else { // long form or indefinite > > This should just the long form. Isn't the indefinite case covered by the first if-check? Correct. > src/java.base/share/classes/sun/security/util/DerValue.java line 325: > >> 323: lenByte &= 0x07f; >> 324: if (lenByte == 0) { >> 325: length = -1; > > This should never happen given the first if-check? > > There is a lot of duplicated code (line 318-348)with the various length-parsing methods in DerInputStream class. Have > you considered consolidating them? It seems that you are keeping track of the pos value for the subsequent > "Too-little"/"Too much" checks. Is "allowMore" really used? If "allowBER" is false, could "allowMore" be true? Correct. I didn't really modify the old code much here. Will see if worth fixing. allowMore is still useful for allowBER == true unless indefinite length is used. For indefinite length, our current DerIndefLenConverter always consumes all available bytes. This is not perfect, let's see if we can enhance it later. > src/java.base/share/classes/sun/security/util/DerValue.java line 446: > >> 444: } >> 445: >> 446: public final DerInputStream getData() { > > Mark this method as deprecated javadoc tag? Is it possible to just change this method impl with the new impl under > data()? The data field is already public, can't we just update the impl of this method? Having the data field, > getData() method and now data() looks very confusing. There are a lot of classes calling this method and it's different from `data()`. `data()` returns a new stream always pointing to the 1st sub-value in the content, but `getData()` returns the data field which could advance after a read call. This means you can call `getData().getDerValue()` to read the 1st sub-value, and then `getData().getDerValue()` again to read the 2nd. Quite unobvious but the actual behavior. I can add some comments. I named the new method `data()` because I want the future nice-behavior method looks simple. > src/java.base/share/classes/sun/security/util/DerValue.java line 584: > >> 582: } >> 583: // TODO >> 584: return new BigInteger(1, buffer, start, end - start).intValue(); > > More info for what to do? - // TODO > Enumerated is just integer, is there any spec/doc saying it's non-negative? All I can find is just integer. Maybe that's what I meant? The positive thing? I'll refactor `getBigIntegerInternal()` so this method will call it. > src/java.base/share/classes/sun/security/util/DerValue.java line 670: > >> 668: } >> 669: if (end == start) { >> 670: throw new IOException("No padding"); > > Same as above comment regarding "No Padding". Yes. > src/java.base/share/classes/sun/security/util/DerValue.java line 675: > >> 673: if (end == start + 1) { >> 674: return new BitArray(0); >> 675: } else { > > This is different from the existing impl in DerInputBuffer.getUnalignedBitString() which throws IOException if the > numberOfPadBits is invalid. It's also different from the getBitString() impl in this PR where the numOfPadBits is still > checked. Is this difference in behavior intentional? No. I didn't intend to make any change. I'll investigate. Maybe I copied from an old version? > src/java.base/share/classes/sun/security/util/DerValue.java line 680: > >> 678: throw new IOException("Invalid number of padding bits"); >> 679: } >> 680: return new BitArray((end - start - 1) * 8 - numOfPadBits, > > << 3 Sure. > src/java.base/share/classes/sun/security/util/DerValue.java line 768: > >> 766: */ >> 767: public String getUniversalString() throws IOException { >> 768: return readStringInternal(tag_UniversalString, new UTF_32BE()); > > It looks like UTF_32BE now is always supported? If yes, perhaps adding a constant for it just like for other charsets? > Also the "return" javadoc tag for this method needs to be updated? That's a public Java SE API and I don't intent to add one. I'll fix the javadoc. > src/java.base/share/classes/sun/security/util/DerValue.java line 777: > >> 775: * if UTC Time is to be read. >> 776: */ >> 777: private Date getTime(int len, boolean generalized) throws IOException { > > You have the Internal suffix on other private helper routines. Maybe add it here as well? Good idea. > src/java.base/share/classes/sun/security/util/DerValue.java line 976: > >> 974: throw new IOException("DER UTC Time length error"); >> 975: } >> 976: } > > nit: add a javadoc for this like other public methods of this class. > nit: move getNull() up before getTime() so all the time-related methods are together. > The IOException messages in this method has UTC Time related words, maybe copy-n-paste error? Ah, yes. > src/java.base/share/classes/sun/security/util/DerValue.java line 991: > >> 989: >> 990: data.pos = data.end; // Compatibility. Reach end. >> 991: return getTime(end - start, false); > > Given that getTime() have access to all the fields, it seems redundant to have to specify (end-start) when calling it. Good idea. > src/java.base/share/classes/sun/security/util/DerValue.java line 1043: > >> 1041: @Override >> 1042: public String toString() { >> 1043: return String.format("DerValue(%02x, %s, %d, 5d)", > > 5d should be %d? Ouch. > src/java.base/share/classes/sun/security/util/DerValue.java line 1154: > >> 1152: * @return a new DerValue >> 1153: */ >> 1154: public DerValue withTag(byte newTag) { > > Seems like a somewhat dangerous method. The value may not match the new tag? The caller is expected to know what it's > doing? I intend to use it to turn back IMPLICIT element to its original tag, otherwise getXyz() calls would fail because they are checking the tag. In the old design, checking the tag (in DerValue) and reading the value (in DerInputBuffer) are separated but now they are in a single method (in DerValue). The caller pattern should always look like `withTag(INTEGER).getInteger()`. > src/java.base/share/classes/sun/security/util/DerValue.java line 1173: > >> 1171: >> 1172: DerValue[] subs(byte expectedTag, int startLen) throws IOException { >> 1173: if (expectedTag != 0 && expectedTag != tag) { > > so if expectedTag == 0, then we don't check for tag match? Looks strange. If this is intentional, we should add comment > to clarify why. For IMPLICIT. Will comment. > test/jdk/sun/security/util/DerValue/DeepOctets.java line 56: > >> 54: Utils.runAndCheckException( >> 55: () -> new DerInputStream(input).getOctetString(), >> 56: IOException.class); > > It seems that the existing impl already differs and you are just adding a regression test to highlight the difference, > right? The existing impl already differs, but `DerValue::getOctetString` can only read one level of constructed OCTET STRING. My second commit can read arbitrary levels and hence this this regression test. There are two levels of 0x24 here. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From weijun at openjdk.java.net Sat Sep 26 01:00:11 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 26 Sep 2020 01:00:11 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Fri, 18 Sep 2020 21:25:28 GMT, Weijun Wang wrote: >> This code change rewrites DerValue into a mostly immutable class and simplifies DerInputStream as a wrapper for a >> series of DerValues objects. DerInputBuffer is removed. >> All existing methods of DerValue and DerInputStream should still work with the exact same behavior, except for a few >> places where bugs are fixed. For example, Indefinite length must be used with a constructed tag. >> Except for the ObjectIdentifier class where DerInputBuffer is directly referenced, no other code is touched. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > Enhance DerValue::getOctetString to be able to read multi-level constructed value. Thanks a lot for your detailed code review. I'll push a new commit early next week. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From weijun at openjdk.java.net Sat Sep 26 01:00:21 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Sat, 26 Sep 2020 01:00:21 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Fri, 25 Sep 2020 02:47:59 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 638: >> >>> 636: } >>> 637: if (end == start) { >>> 638: throw new IOException("No padding"); >> >> Well, I find the original error message is clearer: Invalid encoding: zero length bit string. Just the "No padding" may >> be somewhat unclear since no padding is needed when it's multiple of 8. Or, maybe something like >> "DerValue.getBitString, empty value". > > It also seems strange that it only checks that length !=0. The spec of BitString seems to suggest the length must > be >=2 where the first byte is the number of padding bits. It seems that the right check should be (end - start) > 1? I'll look into it. If there's anything wrong, will fix and add a regression test. What if there is zero bit? And yes, the old exception message is better. Don't know why I modified it. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From github.com+471021+marschall at openjdk.java.net Sun Sep 27 19:03:44 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sun, 27 Sep 2020 19:03:44 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v6] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8138732 - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=05 Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From eric.c.liu at arm.com Mon Sep 28 15:13:58 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Mon, 28 Sep 2020 15:13:58 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com>, Message-ID: Hi, Thanks for looking at this. For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' to replace 'strncpy'. Thanks, Eric From github.com+471021+marschall at openjdk.java.net Mon Sep 28 19:10:41 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 28 Sep 2020 19:10:41 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 22:47:47 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by egahlin (Reviewer). > > @marschall I will sponsor it after you integrate the latest update. @vnkozlov done, I hope I now made it correctly with a merge commit for the latest merge conflict ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From valeriep at openjdk.java.net Tue Sep 29 00:16:02 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 00:16:02 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Fri, 25 Sep 2020 22:47:42 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerInputStream.java line 69: >> >>> 67: int mark; >>> 68: >>> 69: public DerInputStream(byte[] data, int start, int length, boolean allowBER) { >> >> Add javadoc for the new impl? Do we need to validate things like data != null, start and length have valid values? Or >> assuming that since all its callers are internal, no need to check. > > I don't intend to add any check because callers are internal. I can add a comment. Add a comment is good. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 00:25:44 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 00:25:44 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Fri, 25 Sep 2020 22:58:26 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerInputStream.java line 103: >> >>> 101: */ >>> 102: public DerValue getDerValue() throws IOException { >>> 103: DerValue result = new DerValue( >> >> Check (this.end - this.pos > 0) before calling DerValue()? > > new DerValue() would fail in this case. Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 01:03:32 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 01:03:32 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Fri, 25 Sep 2020 23:00:22 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerInputStream.java line 139: >> >>> 137: // does not accept constructed OCTET STRING. >>> 138: DerValue v = getDerValue(); >>> 139: if (v.tag != DerValue.tag_OctetString) { >> >> Only this method checks tag of the DerValue? > > Yes, this is because `DerValue::getOctetString` allows constructed value but `DerInputStream::getOctetString` only > accepts primitive value. This is for compatibility. > All other methods will have tag checked inside the corresponding DerValue method. Do you prefer a fast fail? I just wonder why the different handling. Do you know why? Is it really used/needed, just curious? ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 02:51:15 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 02:51:15 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Fri, 25 Sep 2020 23:57:35 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 170: >> >>> 168: >>> 169: // Unsafe. Legacy. Never null. >>> 170: final public DerInputStream data; >> >> nit: public final for sake of consistency? If not meant to be used anymore, mark it clearly across all relevant methods >> with deprecated javadoc tag? > > public for compatibility, and final because it won't need to change. I'll see how many `@deprecated` I can add. Or, > I'll see if I can move all will-be-deprecated code together. Yeah, it'd be nice if all will-be-deprecated code are together. Easier to spot and less chance for them to be picked up and used. >> src/java.base/share/classes/sun/security/util/DerValue.java line 294: >> >>> 292: >>> 293: /** >>> 294: * Parse an ASN.1/BER encoded datum from a byte array. >> >> DER instead of BER? > > There is allowBER, so BER. Well, allowBER may be false? How about ASN.1/DER/BER? ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 02:59:20 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 02:59:20 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Sat, 26 Sep 2020 00:04:28 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 284: >> >>> 282: >>> 283: /** >>> 284: * Parse an ASN.1/BER encoded datum. The entire encoding must hold exactly >> >> Are you intentionally put BER here because allowBER=true? > > Yes. In fact I'm not quite confident on our usage of allowBER. In a lot of cases we are actually quite strict. Since > this code change is meant to be a refactoring and does not intend to fix many things, I don't intent to make many > behavior change. We have to be strict in "sensitive" area such as signatures. The parsing code seems to be still mainly DER. It was never fully BER, but just some. It's good to keep behavior change minimum as this is like a re-write and may already have some unintentional changes. >> src/java.base/share/classes/sun/security/util/DerValue.java line 322: >> >>> 320: } else if ((lenByte & 0x080) == 0x00) { // short form, 1 byte datum >>> 321: length = lenByte; >>> 322: } else { // long form or indefinite >> >> This should just the long form. Isn't the indefinite case covered by the first if-check? > > Correct. Fix the comment then? >> src/java.base/share/classes/sun/security/util/DerValue.java line 226: >> >>> 224: this.end = end; >>> 225: this.allowBER = allowBER; >>> 226: this.data = new DerInputStream(this); >> >> this.data used to just contain the "value" part of the DerValue, now it's the whole DerValue (including tag and length >> in addition to value). Is its usage still compatible? > > The constructor `DerInputStream(DerValue)` has not read tag at all. I can rewrite it the last line to `new > DerInputStream(buffer, start, end - start, allowBER)`. Yes, I think it is better to just use the buffer/start/end-start/allowBER for this.data. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From weijun at openjdk.java.net Tue Sep 29 03:15:21 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 03:15:21 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Tue, 29 Sep 2020 01:01:12 GMT, Valerie Peng wrote: >> Yes, this is because `DerValue::getOctetString` allows constructed value but `DerInputStream::getOctetString` only >> accepts primitive value. This is for compatibility. >> All other methods will have tag checked inside the corresponding DerValue method. Do you prefer a fast fail? > > I just wonder why the different handling. Do you know why? Is it really used/needed, just curious? I don't know. Both methods are called, and `DerValue::getOctetString` is actual used in reality when reading content data embedded inside PKCS #7 (which is not uncommon). All I can do now is to make them unchanged. >> There is allowBER, so BER. > > Well, allowBER may be false? How about ASN.1/DER/BER? I'll just write ASN.1 then. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From weijun at openjdk.java.net Tue Sep 29 03:18:47 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 03:18:47 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Tue, 29 Sep 2020 02:53:10 GMT, Valerie Peng wrote: >> Yes. In fact I'm not quite confident on our usage of allowBER. In a lot of cases we are actually quite strict. Since >> this code change is meant to be a refactoring and does not intend to fix many things, I don't intent to make many >> behavior change. > > We have to be strict in "sensitive" area such as signatures. The parsing code seems to be still mainly DER. It was > never fully BER, but just some. It's good to keep behavior change minimum as this is like a re-write and may already > have some unintentional changes. As this constructor calls another with allowBER=true, I leave the BER word there. Yes, I understand our impl is not always precise. To make it so, we need to adjust the callers everywhere to match the RFCs, but then there will be compatibility issues. >> Correct. > > Fix the comment then? Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 03:29:47 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 03:29:47 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Sat, 26 Sep 2020 00:21:10 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 584: >> >>> 582: } >>> 583: // TODO >>> 584: return new BigInteger(1, buffer, start, end - start).intValue(); >> >> More info for what to do? - // TODO >> Enumerated is just integer, is there any spec/doc saying it's non-negative? All I can find is just integer. > > Maybe that's what I meant? The positive thing? > > I'll refactor `getBigIntegerInternal()` so this method will call it. Existing impl does not make it positive, so I am not sure why you changed it here. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From weijun at openjdk.java.net Tue Sep 29 03:29:47 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 03:29:47 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: <3x76JXdxLopabtSZIjFG9EhGJ5uuaim7kv9cpQP9G5c=.ea0b043c-8e9b-4cf8-8e98-ea464eb20d8d@github.com> On Tue, 29 Sep 2020 03:25:29 GMT, Valerie Peng wrote: >> Maybe that's what I meant? The positive thing? >> >> I'll refactor `getBigIntegerInternal()` so this method will call it. > > Existing impl does not make it positive, so I am not sure why you changed it here. I'll keep it signed. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 03:55:58 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 03:55:58 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Sat, 26 Sep 2020 00:18:11 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 446: >> >>> 444: } >>> 445: >>> 446: public final DerInputStream getData() { >> >> Mark this method as deprecated javadoc tag? Is it possible to just change this method impl with the new impl under >> data()? The data field is already public, can't we just update the impl of this method? Having the data field, >> getData() method and now data() looks very confusing. > > There are a lot of classes calling this method and it's different from `data()`. `data()` returns a new stream always > pointing to the 1st sub-value in the content, but `getData()` returns the data field which could advance after a read > call. This means you can call `getData().getDerValue()` to read the 1st sub-value, and then `getData().getDerValue()` > again to read the 2nd. Quite unobvious but the actual behavior. I can add some comments. I named the new method > `data()` because I want the future nice-behavior method looks simple. Both the data field and `getData()`are public and seems interchangeable (redundant?). With this new method named data(), it sounds like a replacement for the data field which I am not sure if this is your intention or not. Do we really needs data()? There is the subs() method for returning the sub values, no? ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 04:02:02 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 04:02:02 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Sat, 26 Sep 2020 00:33:17 GMT, Weijun Wang wrote: >> It also seems strange that it only checks that length !=0. The spec of BitString seems to suggest the length must >> be >=2 where the first byte is the number of padding bits. It seems that the right check should be (end - start) > 1? > > I'll look into it. If there's anything wrong, will fix and add a regression test. What if there is zero bit? > > And yes, the old exception message is better. Don't know why I modified it. 0-bit BitArray? Maybe no need for this scenario? Just my wild guess. Keep the same existing behavior is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 04:06:30 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 04:06:30 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Sat, 26 Sep 2020 00:52:38 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 1154: >> >>> 1152: * @return a new DerValue >>> 1153: */ >>> 1154: public DerValue withTag(byte newTag) { >> >> Seems like a somewhat dangerous method. The value may not match the new tag? The caller is expected to know what it's >> doing? > > I intend to use it to turn back IMPLICIT element to its original tag, otherwise getXyz() calls would fail because they > are checking the tag. In the old design, checking the tag (in DerValue) and reading the value (in DerInputBuffer) are > separated but now they are in a single method (in DerValue). The caller pattern should always look like > `withTag(INTEGER).getInteger()`. Hmm, I see, maybe add more comments then. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 04:16:45 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 04:16:45 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Tue, 29 Sep 2020 03:12:42 GMT, Weijun Wang wrote: >> Well, allowBER may be false? How about ASN.1/DER/BER? > > I'll just write ASN.1 then. Sure. >> We have to be strict in "sensitive" area such as signatures. The parsing code seems to be still mainly DER. It was >> never fully BER, but just some. It's good to keep behavior change minimum as this is like a re-write and may already >> have some unintentional changes. > > As this constructor calls another with allowBER=true, I leave the BER word there. Yes, I understand our impl is not > always precise. To make it so, we need to adjust the callers everywhere to match the RFCs, but then there will be > compatibility issues. Yes, I agree. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Tue Sep 29 04:16:46 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 04:16:46 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Sat, 26 Sep 2020 00:43:30 GMT, Weijun Wang wrote: >> src/java.base/share/classes/sun/security/util/DerValue.java line 768: >> >>> 766: */ >>> 767: public String getUniversalString() throws IOException { >>> 768: return readStringInternal(tag_UniversalString, new UTF_32BE()); >> >> It looks like UTF_32BE now is always supported? If yes, perhaps adding a constant for it just like for other charsets? >> Also the "return" javadoc tag for this method needs to be updated? > > That's a public Java SE API and I don't intent to add one. I'll fix the javadoc. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From weijun at openjdk.java.net Tue Sep 29 05:32:17 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 05:32:17 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Tue, 29 Sep 2020 02:46:48 GMT, Valerie Peng wrote: >> public for compatibility, and final because it won't need to change. I'll see how many `@deprecated` I can add. Or, >> I'll see if I can move all will-be-deprecated code together. > > Yeah, it'd be nice if all will-be-deprecated code are together. Easier to spot and less chance for them to be picked up > and used. I'll try to put the will-be-deprecated field and methods together. There are still other methods referencing them for compatibility. >> There are a lot of classes calling this method and it's different from `data()`. `data()` returns a new stream always >> pointing to the 1st sub-value in the content, but `getData()` returns the data field which could advance after a read >> call. This means you can call `getData().getDerValue()` to read the 1st sub-value, and then `getData().getDerValue()` >> again to read the 2nd. Quite unobvious but the actual behavior. I can add some comments. I named the new method >> `data()` because I want the future nice-behavior method looks simple. > > Both the data field and `getData()`are public and seems interchangeable (redundant?). With this new method named > data(), it sounds like a replacement for the data field which I am not sure if this is your intention or not. Do we > really needs data()? There is the subs() method for returning the sub values, no? I suggest future app uses data() only. subs() might not be easy to use (Ex: when dealing with OPTIONAL fields), otherwise DerInputStream will be useless. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From weijun at openjdk.java.net Tue Sep 29 05:34:57 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 05:34:57 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: <8S5F3w4jRtYgpKVRXE0BKlVshtBg8XB33W83KBFf-es=.88492319-8c04-4791-97c2-5cb87bfaa444@github.com> On Tue, 29 Sep 2020 03:59:40 GMT, Valerie Peng wrote: >> I'll look into it. If there's anything wrong, will fix and add a regression test. What if there is zero bit? >> >> And yes, the old exception message is better. Don't know why I modified it. > > 0-bit BitArray? Maybe no need for this scenario? Just my wild guess. Keep the same existing behavior is fine. It does exist. Sometimes the least number of bits should be encoded and therefore empty if all zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From aph at openjdk.java.net Tue Sep 29 09:24:46 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 29 Sep 2020 09:24:46 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 06:03:57 GMT, Ard Biesheuvel wrote: >> @ardbiesheuvel : Ard, could you please ack this patch? Thanks. > > Acked-by: Ard Biesheuvel > If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following > test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > 15 #-----testresult----- > 16 > description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > 19 environment=regtest > 20 execStatus=Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Option 'UseSHA3Intrinsics' is > expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? I don't understand your question. There should be two acceptable results, either "Pass" or "Not supported". What else is possible? ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From kim.barrett at oracle.com Tue Sep 29 10:51:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 06:51:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: > On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: > > Hi, > > Thanks for looking at this. > > For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). > I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' > to replace 'strncpy'. > > > Thanks, > Eric I don't think using memory functions in place of string functions for string manipulation is really an improvement. I did a bit of experimenting. With gcc10.2, and using the --enable-asan configure option, we get a -Wstringop-truncation warning in CompilerCounters::set_current_method, even after careful adjustment of the code to use the documented idiom for avoiding that warning. I initially wondered whether this might be only in fastdebug builds, where we also define _FORTIFY_SOURCE=2. The asan faq https://github.com/google/sanitizers/wiki/AddressSanitizer#faq says asan doesn't work well with _FORTIFY_SOURCE. But the same warning occurs in a release build, where we aren't defining _FORTIFY_SOURCE. At this point all I can conclude is that --enable-asan (i.e. -fsanitize=address) is simply incompatible with -Wstringop-truncation, at least through gcc10. That seems like a bug that someone should report. (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) We don't normally build with -fsanitize=address; that's something that someone might want to turn on sometimes for testing or debugging, but I don't think we're planning to have it always on, even in debug builds. Since it seems to be incompatible with various other options that we *do* normally use, I think the way to allow --enable-asan to be (possibly) usable is in the build system at configure time. That is, the --enable-asan configure option should, in addition to adding -fsanitize=address, also (1) disable -Wstringop-truncation and (2) disable the defining of _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes involves conditionalizing their addition/removal using ${ASAN_ENABLED}. Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. From kim.barrett at oracle.com Tue Sep 29 11:17:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 07:17:50 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> > On Sep 29, 2020, at 6:51 AM, Kim Barrett wrote: > >> On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: >> >> Hi, >> >> Thanks for looking at this. >> >> For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). >> I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' >> to replace 'strncpy'. >> >> >> Thanks, >> Eric > > [?] > At this point all I can conclude is that --enable-asan (i.e. > -fsanitize=address) is simply incompatible with -Wstringop-truncation, at > least through gcc10. That seems like a bug that someone should report. > (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) > > [?] > > Since it seems to be incompatible with various other options that we *do* > normally use, I think the way to allow --enable-asan to be (possibly) usable > is in the build system at configure time. That is, the --enable-asan > configure option should, in addition to adding -fsanitize=address, also (1) > disable -Wstringop-truncation and (2) disable the defining of > _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes > involves conditionalizing their addition/removal using ${ASAN_ENABLED}. > > Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 From jpai at openjdk.java.net Tue Sep 29 11:39:20 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 29 Sep 2020 11:39:20 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: > Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? > > As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds > the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This > is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is > larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the > `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent > this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the > necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which > reproduces the issue and verifies the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Address the review comments and introduce an array size check in JarFile.getBytes() method itself ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/323/files - new: https://git.openjdk.java.net/jdk/pull/323/files/76dcea76..279c7c83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=323&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=323&range=00-01 Stats: 17 lines in 1 file changed: 10 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/323/head:pull/323 PR: https://git.openjdk.java.net/jdk/pull/323 From jpai at openjdk.java.net Tue Sep 29 11:47:58 2020 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 29 Sep 2020 11:47:58 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: <30rEkG2yhP3TeNWwtOgtebkVP9FhGLnhe5XCxLyfN5Y=.167dab69-401e-42b9-bf8d-094657df5bfb@github.com> On Thu, 24 Sep 2020 16:36:28 GMT, Brent Christian wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Address the review comments and introduce an array size check in JarFile.getBytes() method itself > > src/java.base/share/classes/java/util/jar/JarFile.java line 791: > >> 789: private byte[] getBytes(ZipEntry ze) throws IOException { >> 790: try (InputStream is = super.getInputStream(ze)) { >> 791: int len = (int)ze.getSize(); > > I think the main issue is the casting of the 'long' value from ZipEntry.getSize() into an 'int'. I think checking if > the size is > the maximum array size and throwing an OOME here might be a sufficient fix on its own. Hello Brent, Thank you for the review and sorry about the delayed response - I was involved in a few other things so couldn't get to this sooner. I have taken your input and updated this patch to address this part. Specifically, I have introduced a new `MAX_BUFFER_SIZE` within the `JarFile`. This `MAX_BUFFER_SIZE` is an actual copy of the field (and value) of `java.io.InputStream#MAX_BUFFER_SIZE`. I have done a minor change to the javadoc of this field as compared to what is in the javadoc of its `InputStream` counterpart. I did this so that the OOM exception message being thrown matches the comment in this javadoc (the `InputStream` has a mismatch in its javadoc and the actual message that gets thrown). Additionally, in this patch, the `if (len != -1 ...)` has been changed to `if (len >= 0 ...)` to prevent the code from entering this block when `Zip64` format is involved where (from what I can gather) an uncompressed entry size value can have 2^64 (unsigned) bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From rriggs at openjdk.java.net Tue Sep 29 14:23:29 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 14:23:29 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 14:04:19 GMT, Weijun Wang wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Small cleanups to javadoc and code > > Just some comments based on the output example. Are there any other comments or suggestions? ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From weijun at openjdk.java.net Tue Sep 29 14:29:59 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 14:29:59 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:20:50 GMT, Roger Riggs wrote: >> Just some comments based on the output example. > > Are there any other comments or suggestions? Can you post an example output of that cert? What about indefinite length? (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, 2, 'c', 'd', 0, 0) ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From rriggs at openjdk.java.net Tue Sep 29 14:52:07 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 14:52:07 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:27:29 GMT, Weijun Wang wrote: >> Are there any other comments or suggestions? > > Can you post an example output of that cert? What about indefinite length? (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, > 2, 'c', 'd', 0, 0) For your example the output is: 0000: 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' 000a: 00 00 ; END-OF-CONTENT ``` It seems to have lost an indent, I'll take a look at that. ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From weijun at openjdk.java.net Tue Sep 29 15:20:24 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 15:20:24 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v3] In-Reply-To: References: Message-ID: > This code change rewrites DerValue into a mostly immutable class and simplifies DerInputStream as a wrapper for a > series of DerValues objects. DerInputBuffer is removed. > All existing methods of DerValue and DerInputStream should still work with the exact same behavior, except for a few > places where bugs are fixed. For example, Indefinite length must be used with a constructed tag. > Except for the ObjectIdentifier class where DerInputBuffer is directly referenced, no other code is touched. Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - 8249783: Simplify DerValue and DerInputStream - Merge remote-tracking branch 'origin/master' into 8249783 - Enhance DerValue::getOctetString to be able to read multi-level constructed value. - 8249783: Simplify DerValue and DerInputStream ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/232/files - new: https://git.openjdk.java.net/jdk/pull/232/files/e8f804c6..ac77172e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=232&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=232&range=01-02 Stats: 13102 lines in 448 files changed: 7078 ins; 4729 del; 1295 mod Patch: https://git.openjdk.java.net/jdk/pull/232.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/232/head:pull/232 PR: https://git.openjdk.java.net/jdk/pull/232 From jnimeh at openjdk.java.net Tue Sep 29 15:22:50 2020 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 29 Sep 2020 15:22:50 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:49:49 GMT, Roger Riggs wrote: >> Can you post an example output of that cert? What about indefinite length? (Ex: 0x24, (byte) 0x80, 4, 2, 'a', 'b', 4, >> 2, 'c', 'd', 0, 0) > > For your example the output is: > 0000: 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] > 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' > 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' > 000a: 00 00 ; END-OF-CONTENT ``` > > It seems to have lost an indent, I'll take a look at that. Also in that last example, it seems to suggest that the second octet string is nested within the first one since it sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the same indentation level as the initial indefinite length encoding? ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From weijun at openjdk.java.net Tue Sep 29 15:28:06 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 15:28:06 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: On Sat, 26 Sep 2020 00:57:23 GMT, Weijun Wang wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> Enhance DerValue::getOctetString to be able to read multi-level constructed value. > > Thanks a lot for your detailed code review. I'll push a new commit early next week. New change pushed. I haven't really moved the "deprecated" codes together in DerValue. I just put the data-related and tag-related methods together and add more comments. Besides following your suggestions in the comment, this time I made some fine tuned changes for indefinite length parsing, esp, for the uncertainty about remaining data after conversion. in the future, we can enhance DerIndefLenConverter to be more precise and efficient. ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From mullan at openjdk.java.net Tue Sep 29 17:35:52 2020 From: mullan at openjdk.java.net (Sean Mullan) Date: Tue, 29 Sep 2020 17:35:52 GMT Subject: RFR: 8253637: Update EC removal [v2] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 19:57:49 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a quick review for two changes. The primary is a failure that shows up on linux-aarch64 because the systems do >> not have NSS. The default was to allow all curves tested, which before the native library removal was ok. The second >> was a missed changeset that got left in the local repo that helped find the curve name on an exception message. Thanks >> >> Tony > > Anthony Scarpino has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since > the last revision: > - Merge branch 'ecfix' of github.com:ascarpino/jdk into ecfix > - 8253637: Update EC removal > - left behind message change > - remove problem list entry > - 8253637: Update EC removal > - left behind message change Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/366 From rriggs at openjdk.java.net Tue Sep 29 17:52:11 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 17:52:11 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v5] In-Reply-To: References: Message-ID: <3Kr8YyqwdaS2mhqkGNNEdNV5a0TXdDvDmtHrhIJ-0nc=.a4346874-bfe3-450e-94c3-1f61f82f6369@github.com> > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Corrected reading of extended length bytes, depth of indefinite length tag-values, added test for indefinite length ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/268/files - new: https://git.openjdk.java.net/jdk/pull/268/files/25115595..91741d4a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=268&range=03-04 Stats: 21 lines in 2 files changed: 18 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/268/head:pull/268 PR: https://git.openjdk.java.net/jdk/pull/268 From ascarpino at openjdk.java.net Tue Sep 29 18:08:16 2020 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Tue, 29 Sep 2020 18:08:16 GMT Subject: Integrated: 8253637: Update EC removal In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 18:56:00 GMT, Anthony Scarpino wrote: > Hi, > > I need a quick review for two changes. The primary is a failure that shows up on linux-aarch64 because the systems do > not have NSS. The default was to allow all curves tested, which before the native library removal was ok. The second > was a missed changeset that got left in the local repo that helped find the curve name on an exception message. Thanks > > Tony This pull request has now been integrated. Changeset: fb206908 Author: Anthony Scarpino URL: https://git.openjdk.java.net/jdk/commit/fb206908 Stats: 7 lines in 4 files changed: 2 ins; 1 del; 4 mod 8253637: Update EC removal Reviewed-by: mullan ------------- PR: https://git.openjdk.java.net/jdk/pull/366 From rriggs at openjdk.java.net Tue Sep 29 19:23:17 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 19:23:17 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: Message-ID: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> On Tue, 29 Sep 2020 15:20:13 GMT, Jamil Nimeh wrote: > Also in that last example, it seems to suggest that the second octet string is nested within the first one since it > sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they > sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for > separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the > same indentation level as the initial indefinite length encoding? Yes, all of the enclosed items should be at the same indent level. (A bug as it turns out). I chose to indent the END-OF-CONTENT line at the same level to terminate the list of tag-values at that level All of the items enclosed are at the same level. The updated output is: 0000: 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' 000a: 00 00 ; END-OF-CONTENT ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From jnimeh at openjdk.java.net Tue Sep 29 19:38:21 2020 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 29 Sep 2020 19:38:21 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> References: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> Message-ID: On Tue, 29 Sep 2020 19:20:42 GMT, Roger Riggs wrote: >> Also in that last example, it seems to suggest that the second octet string is nested within the first one since it >> sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they >> sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for >> separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the >> same indentation level as the initial indefinite length encoding? > >> Also in that last example, it seems to suggest that the second octet string is nested within the first one since it >> sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they >> sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for >> separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the >> same indentation level as the initial indefinite length encoding? > > Yes, all of the enclosed items should be at the same indent level. (A bug as it turns out). > I chose to indent the END-OF-CONTENT line at the same level to terminate the list of tag-values at that level > All of the items enclosed are at the same level. > > The updated output is: > 0000: 24 80 ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE] > 0002: 04 02 61 62 ; OCTET STRING [2] 'ab' > 0006: 04 02 63 64 ; OCTET STRING [2] 'cd' > 000a: 00 00 ; END-OF-CONTENT Regarding the end-of-content identifier, that looks good. Thanks for fixing the indentation for the right-side ASN.1 interpretation of the bytes. My only remaining question is whether the corresponding hex dumps on the left should match the indentation levels as well. I don't have a strong opinion either way on that one but if you're indenting for each element at the same nest level it seems like that could potentially chew up a lot of horizontal space. Was the extra indentation for the second octet string done for readability? ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From rriggs at openjdk.java.net Tue Sep 29 19:43:17 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Sep 2020 19:43:17 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: References: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> Message-ID: <4FF9K0RIVTb_RZYn3dOuuGchJeKY0Pgez8ZcILkc_YY=.0837a70f-0fa4-4a83-a755-517e7579757f@github.com> On Tue, 29 Sep 2020 19:35:42 GMT, Jamil Nimeh wrote: > Regarding the end-of-content identifier, that looks good. Thanks for fixing the indentation for the right-side ASN.1 > interpretation of the bytes. My only remaining question is whether the corresponding hex dumps on the left should match > the indentation levels as well. I don't have a strong opinion either way on that one but if you're indenting for each > element at the same nest level it seems like that could potentially chew up a lot of horizontal space. Was the extra > indentation for the second octet string done for readability? Max had requested the current offset of the byte values, so it was easy to see where each new value started and to keep the offsets on a modulo boundary. The formatter on the right is largely decoupled from the hex value tabular form on the left while keeping the correspondence between the formatted items and the bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From jnimeh at openjdk.java.net Tue Sep 29 19:47:00 2020 From: jnimeh at openjdk.java.net (Jamil Nimeh) Date: Tue, 29 Sep 2020 19:47:00 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2] In-Reply-To: <4FF9K0RIVTb_RZYn3dOuuGchJeKY0Pgez8ZcILkc_YY=.0837a70f-0fa4-4a83-a755-517e7579757f@github.com> References: <6CuxYxb4ZJwX_sW3lyJ8dTFWvn8Aydb6JRCOh9KLGWU=.a06d3e9b-e5e2-4def-ab0a-22695681ce71@github.com> <4FF9K0RIVTb_RZYn3dOuuGchJeKY0Pgez8ZcILkc_YY=.0837a70f-0fa4-4a83-a755-517e7579757f@github.com> Message-ID: <03h_NA3QgxQ5sUC6MuB5NBe6QLG7hWRtW1sR7U5Bib8=.9bb280e8-997f-4899-a14d-bd60ea3ce8e8@github.com> On Tue, 29 Sep 2020 19:40:46 GMT, Roger Riggs wrote: > > > > Regarding the end-of-content identifier, that looks good. Thanks for fixing the indentation for the right-side ASN.1 > > interpretation of the bytes. My only remaining question is whether the corresponding hex dumps on the left should match > > the indentation levels as well. I don't have a strong opinion either way on that one but if you're indenting for each > > element at the same nest level it seems like that could potentially chew up a lot of horizontal space. Was the extra > > indentation for the second octet string done for readability? > > Max had requested the current offset of the byte values, so it was easy to see where each new value started and to keep > the offsets on a modulo boundary. The formatter on the right is largely decoupled from the hex value tabular form on > the left while keeping the correspondence between the formatted items and the bytes. If you and Max find that better from a visual perspective then that works for me. Thanks for clarifying that. ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From weijun at openjdk.java.net Tue Sep 29 19:53:54 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 29 Sep 2020 19:53:54 GMT Subject: RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v5] In-Reply-To: <3Kr8YyqwdaS2mhqkGNNEdNV5a0TXdDvDmtHrhIJ-0nc=.a4346874-bfe3-450e-94c3-1f61f82f6369@github.com> References: <3Kr8YyqwdaS2mhqkGNNEdNV5a0TXdDvDmtHrhIJ-0nc=.a4346874-bfe3-450e-94c3-1f61f82f6369@github.com> Message-ID: On Tue, 29 Sep 2020 17:52:11 GMT, Roger Riggs wrote: >> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter >> >> Debugging functions that utilize ASN.1, DER, and BER encoded streams is >> difficult without test utilities to show the contents. >> The ASN.1 formatter reads a stream and produces annotated output of the >> tags, values, and structures. >> When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized >> with the hex formatted output. >> >> Small changes to HexPrinter are included to improve the output readability. >> >> >> Example decoding of a .pem certificate: >> SEQUENCE [910] >> SEQUENCE [630] >> CONTEXT cons 0 [3] >> BYTE 2, >> BYTE 3, >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> SEQUENCE [76] >> SET [11] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.4.6 (CountryName) >> 'IN' >> ... >> SET [16] >> SEQUENCE [14] >> OBJECT ID [3] 2.5.4.3 (CommonName) >> Client1 >> SEQUENCE [30] >> UTCTIME [13] '150526221718Z' >> UTCTIME [13] '250523221718Z' >> ... >> SEQUENCE [290] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> NULL >> BIT STRING [271] >> CONTEXT cons 3 [123] >> SEQUENCE [121] >> SEQUENCE [9] >> OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> OCTET STRING [2] >> SEQUENCE [44] >> OBJECT ID [9] 2.16.840.1.113730.1.13 >> OCTET STRING [31] '..OpenSSL Generated Certificate' >> SEQUENCE [29] >> OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> OCTET STRING [22] >> SEQUENCE [31] >> OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> OCTET STRING [24] >> SEQUENCE [13] >> OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> NULL >> BIT STRING [257] >> When used with the HexPrinter test utility, the formatting of the >> hexadecimal values is selected with the parameters to HexPrinter. >> >> 0000: 30 82 03 8e ; SEQUENCE [910] >> 0004: 30 82 02 76 ; SEQUENCE [630] >> 0008: a0 03 ; CONTEXT cons 0 [3] >> 000a: 02 01 02 ; BYTE 2, >> 000d: 02 01 03 ; BYTE 3, >> 0010: 30 0d ; SEQUENCE [13] >> 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 001d: 05 00 ; NULL >> 001f: 30 ; SEQUENCE [76] >> 0020: 4c ; >> 0021: 31 0b ; SET [11] >> 0023: 30 09 ; SEQUENCE [9] >> 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) >> 002a: 13 02 49 4e ; 'IN' >> >> ... ... >> >> 005b: 31 10 ; SET [16] >> 005d: 30 0e ; SEQUENCE [14] >> 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) >> 0060: 03 55 04 03 ; >> 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 >> 006d: 30 1e ; SEQUENCE [30] >> 006f: 17 ; UTCTIME [13] '150526221718Z' >> 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; >> 007e: 17 0d ; UTCTIME [13] '250523221718Z' >> 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; >> >> ... ... >> >> 00db: 30 82 01 22 ; SEQUENCE [290] >> 00df: 30 ; SEQUENCE [13] >> 00e0: 0d ; >> 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) >> 00ec: 05 00 ; NULL >> 00ee: 03 82 ; BIT STRING [271] >> 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; >> >> ... >> >> 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; >> 0200: 01 ; >> 0201: a3 7b ; CONTEXT cons 3 [123] >> 0203: 30 79 ; SEQUENCE [121] >> 0205: 30 09 ; SEQUENCE [9] >> 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) >> 020c: 04 02 30 00 ; OCTET STRING [2] >> 0210: 30 2c ; SEQUENCE [44] >> 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 >> 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated >> Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; >> 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; >> 023e: 30 1d ; SEQUENCE [29] >> 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) >> 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] >> 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; >> 025d: 30 1f ; SEQUENCE [31] >> 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) >> 0260: 03 55 1d 23 ; >> 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] >> 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; >> 027e: 30 0d ; SEQUENCE [13] >> 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) >> 028b: 05 00 ; NULL >> 028d: 03 82 01 ; BIT STRING [257] >> 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; >> >> ... >> >> 0390: 6d 94 ; > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Corrected reading of extended length bytes, depth of indefinite length tag-values, added test for indefinite length LGTM. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/268 From valeriep at openjdk.java.net Tue Sep 29 22:25:24 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 22:25:24 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 09:22:25 GMT, Andrew Haley wrote: >> Acked-by: Ard Biesheuvel > >> If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following >> test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java >> 15 #-----testresult----- >> 16 >> description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java >> 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 >> 19 environment=regtest >> 20 execStatus=Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Option 'UseSHA3Intrinsics' is >> expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default >> Any suggestions for this? > > I don't understand your question. There should be two acceptable results, either "Pass" or "Not supported". What else > is possible? I have looked at the java security changes, i.e. src/java.base/share/classes/sun/security/provider/SHA3.java. It looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From jkoskeladev at gmail.com Tue Sep 29 23:46:17 2020 From: jkoskeladev at gmail.com (Jade Koskela) Date: Tue, 29 Sep 2020 16:46:17 -0700 Subject: SSPI Bridge Bug Message-ID: Hi, New contributor here. I have found a bug in sspi_bridge that requires a small change to fix. This causes failures to connect with Postgres JDBC using sspi_bridge. This line in sspi_bridge should be: < || l2 < l1 && l2 != l1) { --- > || l2 < l1 && l2 != r1) { Thanks, Jade -------------- next part -------------- An HTML attachment was scrubbed... URL: From WEIJUN.WANG at ORACLE.COM Wed Sep 30 01:06:33 2020 From: WEIJUN.WANG at ORACLE.COM (Weijun Wang) Date: Tue, 29 Sep 2020 21:06:33 -0400 Subject: SSPI Bridge Bug In-Reply-To: References: Message-ID: Ah, yes. Will fix it soon. Thanks, Max > On Sep 29, 2020, at 7:46 PM, Jade Koskela wrote: > > Hi, > > New contributor here. I have found a bug in sspi_bridge that requires a small change to fix. > This causes failures to connect with Postgres JDBC using sspi_bridge. > > This line in sspi_bridge should be: > > < || l2 < l1 && l2 != l1) { > --- > > || l2 < l1 && l2 != r1) { > > Thanks, > Jade From weijun at openjdk.java.net Wed Sep 30 03:06:56 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 30 Sep 2020 03:06:56 GMT Subject: RFR: 8253829: Wrong length compared in SSPI bridge Message-ID: For two principals to be the same, they are either all "user at R", or one is "user" and the other is "user at R". The check here wants to fail early if the length are different. "l" is the whole length and "r" is the length of the name (without realm). The comparison should be reflective but there is a typo. For example, for "user at R" and "user", l1 = 6, l2 = 4, r1 = 4, r2 = 4, the check will succeed and the names are treated as different. This is not the expected behavior. No regression test because we don't support SSPI testing in the OpenJDK repo now. ------------- Commit messages: - 8253829: Wrong length compared in SSPI bridge Changes: https://git.openjdk.java.net/jdk/pull/419/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=419&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253829 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/419.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/419/head:pull/419 PR: https://git.openjdk.java.net/jdk/pull/419 From valeriep at openjdk.java.net Wed Sep 30 03:31:08 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Sep 2020 03:31:08 GMT Subject: RFR: 8199697: FIPS 186-4 RSA Key Generation Message-ID: Could someone please help review this RFE? Update existing RSA key pair generation code following the guidelines from FIPS 186-4 and FIPS 186-5 (draft). Current proposed changes updates the prime generation code (for P, Q) based on FIPS 186-4 B.3.3 when keysize and public exponent met the requirements set in FIPS 186-4/5. Thanks, Valerie ------------- Commit messages: - 8199697: FIPS 186-4 RSA Key Generation Changes: https://git.openjdk.java.net/jdk/pull/420/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=420&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8199697 Stats: 162 lines in 2 files changed: 93 ins; 15 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/420.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/420/head:pull/420 PR: https://git.openjdk.java.net/jdk/pull/420 From xuelei.fan at oracle.com Wed Sep 30 04:25:41 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 29 Sep 2020 21:25:41 -0700 Subject: Request for comment, a new idea about distributed TLS sessions Message-ID: <06f7e4af-ccea-7539-9b08-fa9813898255@oracle.com> Hi, I was wondering to improve the scalability of the TLS implementation in JDK. TLS session resumption is much faster than full handshaking. It may be a good to support efficiently distributing and resuming TLS sessions across clusters of computers, by using stateless TLS session tickets. The following is a list of the goals: 1. Use session tickets to distribute and resume sessions. 2. Implement a protection scheme for session tickets. 3. Deprecate or modify Java SE APIs that negatively impact distributed session resumption. 4. Ensure that the session tickets generated and protected in one server node can be used for session resumption in other nodes in the distributed system. 5. Ensure that the secret keys used to protect the session ticket can be rotated and synchronized effectively. 6. Ensure that a new server node inserted into the distributed system can be automatically synchronized, thus making it possible to plugin new server nodes as needed. For more details, please refer to the draft JEP. https://bugs.openjdk.java.net/browse/JDK-8245551 Does it sound like a good idea? Did you run into scalability problems for TLS/HTTPS connections? Any suggestions? Any comments are welcome. Thanks & Regards, Xuelei From eric.c.liu at arm.com Wed Sep 30 07:30:49 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 30 Sep 2020 07:30:49 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> , Message-ID: Hi Kim, Thanks for your review. I tried to solve the problem with your suggestion, and have just one question. > On 29 September 2020 18:51 PM, Kim Barrett wrote: > I don't think using memory functions in place of string functions for string > manipulation is really an improvement. Yes, the original code has no problem basically but as you said asan seems incompatible with -Wstringop-truncation. Using 'memcpy' just a workaround. > I did a bit of experimenting. > > With gcc10.2, and using the --enable-asan configure option, we get a > -Wstringop-truncation warning in CompilerCounters::set_current_method, even > after careful adjustment of the code to use the documented idiom for > avoiding that warning. > > I initially wondered whether this might be only in fastdebug builds, where > we also define _FORTIFY_SOURCE=2.? The asan faq > https://github.com/google/sanitizers/wiki/AddressSanitizer#faq > says asan doesn't work well with _FORTIFY_SOURCE. > > But the same warning occurs in a release build, where we aren't defining > _FORTIFY_SOURCE. > At this point all I can conclude is that --enable-asan (i.e. > -fsanitize=address) is simply incompatible with -Wstringop-truncation, at > least through gcc10.? That seems like a bug that someone should report. > (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) > > We don't normally build with -fsanitize=address; that's something that > someone might want to turn on sometimes for testing or debugging, but I > don't think we're planning to have it always on, even in debug builds. > Since it seems to be incompatible with various other options that we *do* > normally use, I think the way to allow --enable-asan to be (possibly) usable > is in the build system at configure time. That is, the --enable-asan > configure option should, in addition to adding -fsanitize=address, also (1) > disable -Wstringop-truncation and (2) disable the defining of > _FORTIFY_SOURCE in fastdebug builds.? It looks like making those changes > involves conditionalizing their addition/removal using ${ASAN_ENABLED}. Disable -Wstringop-truncation seems more reasonable. Is that necessary to disable _FORTIFY_SOURCE in fastdebug? With gcc10.1, disable -Wstringop-truncation seems enough. I didn't test with fastdebug mode before, and now it has been tested in our internal both with release and fastdebug mode. Thanks, Eric From felix.yang at huawei.com Wed Sep 30 08:25:54 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 30 Sep 2020 08:25:54 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > retn at openjdk.java.net] On Behalf Of Andrew Haley > Sent: Tuesday, September 29, 2020 5:25 PM > To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On Thu, 17 Sep 2020 06:03:57 GMT, Ard Biesheuvel > wrote: > > >> @ardbiesheuvel : Ard, could you please ack this patch? Thanks. > > > > Acked-by: Ard Biesheuvel > > > If this feature is not auto-enabled when the SHA3 hardware feature is > > there, we will have one failure for the following > > test: > > test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOp > > tionOnSupportedCPU.java > > 15 #-----testresult----- > > 16 > > description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/ > > intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > > 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > > 19 environment=regtest > > 20 execStatus=Failed. Execution failed: `main' threw exception: > > java.lang.AssertionError: Option 'UseSHA3Intrinsics' is expected to > > have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? > > I don't understand your question. There should be two acceptable results, > either "Pass" or "Not supported". What else is possible? This new test is similar to existing test cases in the same directory like: TestUseSHA256IntrinsicsOptionOnSupportedCPU.java Currently, we ran this new test using QEMU which supports the aarch64 SHA3 feature. This new test is expecting option 'UseSHA3Intrinsics' to be auto-enabled by the JVM when it detects the availability of SHA3 feature. But that was not satisfied since we explicitly disable this option even when SHA3 feature is available. + if (UseSHA && (_features & CPU_SHA3)) { + // Do not auto-enable UseSHA3Intrinsics until it has been fully tested on hardware + // if (FLAG_IS_DEFAULT(UseSHA3Intrinsics)) { + // FLAG_SET_DEFAULT(UseSHA3Intrinsics, true); + // } So I could thought of several choices: 1. Do not add this new test for now; 2. Keep this new test and add on extra requirement for it: @requires os.arch!="aarch64"; (We could remove this when UseSHA3Intrinsics has been fully tested on real hardware and thus could be auto-enabled.) 3. Auto-enable UseSHA3Intrinsics when SHA3 feature is available for now; Is there a better way? Thanks, Felix From felix.yang at huawei.com Wed Sep 30 08:28:13 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 30 Sep 2020 08:28:13 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-retn at openjdk.java.net] On Behalf > Of Valerie Peng > Sent: Wednesday, September 30, 2020 6:25 AM > To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On Tue, 29 Sep 2020 09:22:25 GMT, Andrew Haley > wrote: > > >> Acked-by: Ard Biesheuvel > > > >> If this feature is not auto-enabled when the SHA3 hardware feature is > >> there, we will have one failure for the following > >> test: > >> test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsO > >> ptionOnSupportedCPU.java > >> 15 #-----testresult----- > >> 16 > >> description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler > >> /intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > >> 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > >> 19 environment=regtest > >> 20 execStatus=Failed. Execution failed: `main' threw exception: > >> java.lang.AssertionError: Option 'UseSHA3Intrinsics' is expected to > >> have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? > > > > I don't understand your question. There should be two acceptable > > results, either "Pass" or "Not supported". What else is possible? > > I have looked at the java security changes, i.e. > src/java.base/share/classes/sun/security/provider/SHA3.java. It looks fine. Thanks for reviewing this part. Best Regards, Felix From kim.barrett at oracle.com Wed Sep 30 10:23:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2020 06:23:50 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: > On Sep 30, 2020, at 3:30 AM, Eric Liu wrote: > > Hi Kim, > > Thanks for your review. > I tried to solve the problem with your suggestion, and have just one question. > >> On 29 September 2020 18:51 PM, Kim Barrett wrote: >> With gcc10.2, and using the --enable-asan configure option, we get a >> -Wstringop-truncation warning in CompilerCounters::set_current_method, even >> after careful adjustment of the code to use the documented idiom for >> avoiding that warning. >> >> I initially wondered whether this might be only in fastdebug builds, where >> we also define _FORTIFY_SOURCE=2. The asan faq >> https://urldefense.com/v3/__https://github.com/google/sanitizers/wiki/AddressSanitizer*faq__;Iw!!GqivPVa7Brio!IFzpRJ6UwKlp2que6K1FLh9xe_Oe3s-shyGmlz3pzFTlEyZwdqk7yjfH_uovCn8U$ >> says asan doesn't work well with _FORTIFY_SOURCE. >> >> But the same warning occurs in a release build, where we aren't defining >> _FORTIFY_SOURCE. > >> At this point all I can conclude is that --enable-asan (i.e. >> -fsanitize=address) is simply incompatible with -Wstringop-truncation, at >> least through gcc10. That seems like a bug that someone should report. >> (Might be same as or related to https://urldefense.com/v3/__https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650__;!!GqivPVa7Brio!IFzpRJ6UwKlp2que6K1FLh9xe_Oe3s-shyGmlz3pzFTlEyZwdqk7yjfH_sMh77QA$ ) >> >> We don't normally build with -fsanitize=address; that's something that >> someone might want to turn on sometimes for testing or debugging, but I >> don't think we're planning to have it always on, even in debug builds. > >> Since it seems to be incompatible with various other options that we *do* >> normally use, I think the way to allow --enable-asan to be (possibly) usable >> is in the build system at configure time. That is, the --enable-asan >> configure option should, in addition to adding -fsanitize=address, also (1) >> disable -Wstringop-truncation and (2) disable the defining of >> _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes >> involves conditionalizing their addition/removal using ${ASAN_ENABLED}. > > Disable -Wstringop-truncation seems more reasonable. > Is that necessary to disable _FORTIFY_SOURCE in fastdebug? With gcc10.1, > disable -Wstringop-truncation seems enough. > > I didn't test with fastdebug mode before, and now it has been tested in our internal > both with release and fastdebug mode. My suggestiion that _FORTIFY_SOURCE should be disabled too is based on what the ASan FAQ and various bug reports and related threads say, which seems to be that combining ASan and _FORTIFY_SOURCE can cause problems to be missed and can lead to very strange fortify warnings. I found a couple of threads from a few years ago suggesting that maybe ASan should have interceptors for the fortify functions, but didn?t find any indication that?s actually happened. If it has, then the combination is presumably no longer problematic. From magnus.ihse.bursie at oracle.com Wed Sep 30 11:09:20 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Sep 2020 13:09:20 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> Message-ID: <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> On 2020-09-29 13:17, Kim Barrett wrote: >> On Sep 29, 2020, at 6:51 AM, Kim Barrett wrote: >> >>> On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: >>> >>> Hi, >>> >>> Thanks for looking at this. >>> >>> For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). >>> I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' >>> to replace 'strncpy'. >>> >>> >>> Thanks, >>> Eric >> [?] >> At this point all I can conclude is that --enable-asan (i.e. >> -fsanitize=address) is simply incompatible with -Wstringop-truncation, at >> least through gcc10. That seems like a bug that someone should report. >> (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) >> >> [?] >> >> Since it seems to be incompatible with various other options that we *do* >> normally use, I think the way to allow --enable-asan to be (possibly) usable >> is in the build system at configure time. That is, the --enable-asan >> configure option should, in addition to adding -fsanitize=address, also (1) >> disable -Wstringop-truncation and (2) disable the defining of >> _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes >> involves conditionalizing their addition/removal using ${ASAN_ENABLED}. >> >> Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. > Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 > Will that really help? If a os::strncpy_s method is added to hotspot, how should NetworkInterface.c in libnet be able to use it? /Magnus From kim.barrett at oracle.com Wed Sep 30 12:19:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2020 08:19:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> Message-ID: <4FD74735-D627-4587-8CC0-CFF21F4FF71C@oracle.com> > On Sep 30, 2020, at 7:09 AM, Magnus Ihse Bursie wrote: > > > > On 2020-09-29 13:17, Kim Barrett wrote: >> Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 >> > Will that really help? If a os::strncpy_s method is added to hotspot, how should NetworkInterface.c in libnet be able to use it? > > /Magnus That?s already mentioned in the comments for that bug. A real solution needs to figure out a solution to that part too. So not an easy solve. Also as mentioned in the comments, strncpy_s might not be the right API to provide. strscpy might be better. It might be that bug report should be retitled and the description rewritten. From valeriep at openjdk.java.net Wed Sep 30 17:11:54 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Sep 2020 17:11:54 GMT Subject: RFR: 8253829: Wrong length compared in SSPI bridge In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 02:59:40 GMT, Weijun Wang wrote: > For two principals to be the same, they are either all "user at R", or one is "user" and the other is "user at R". The check > here wants to fail early if the length are different. "l" is the whole length and "r" is the length of the name > (without realm). The comparison should be reflective but there is a typo. For example, for "user at R" and "user", l1 = > 6, l2 = 4, r1 = 4, r2 = 4, the check will succeed and the names are treated as different. This is not the expected > behavior. No regression test because we don't support SSPI testing in the OpenJDK repo now. Looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/419 From weijun at openjdk.java.net Wed Sep 30 17:16:28 2020 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 30 Sep 2020 17:16:28 GMT Subject: Integrated: 8253829: Wrong length compared in SSPI bridge In-Reply-To: References: Message-ID: <_hXrpFCaBKbVc1qGMB22JBG30gq128hvlOFVH8F8JV4=.e3c50b09-54d4-45a8-a28e-796085410529@github.com> On Wed, 30 Sep 2020 02:59:40 GMT, Weijun Wang wrote: > For two principals to be the same, they are either all "user at R", or one is "user" and the other is "user at R". The check > here wants to fail early if the length are different. "l" is the whole length and "r" is the length of the name > (without realm). The comparison should be reflective but there is a typo. For example, for "user at R" and "user", l1 = > 6, l2 = 4, r1 = 4, r2 = 4, the check will succeed and the names are treated as different. This is not the expected > behavior. No regression test because we don't support SSPI testing in the OpenJDK repo now. This pull request has now been integrated. Changeset: e5ba020e Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/e5ba020e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253829: Wrong length compared in SSPI bridge Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/419 From valeriep at openjdk.java.net Wed Sep 30 17:16:28 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Sep 2020 17:16:28 GMT Subject: RFR: 8253829: Wrong length compared in SSPI bridge In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 02:59:40 GMT, Weijun Wang wrote: > For two principals to be the same, they are either all "user at R", or one is "user" and the other is "user at R". The check > here wants to fail early if the length are different. "l" is the whole length and "r" is the length of the name > (without realm). The comparison should be reflective but there is a typo. For example, for "user at R" and "user", l1 = > 6, l2 = 4, r1 = 4, r2 = 4, the check will succeed and the names are treated as different. This is not the expected > behavior. No regression test because we don't support SSPI testing in the OpenJDK repo now. Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/419 From bchristi at openjdk.java.net Wed Sep 30 17:36:10 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 30 Sep 2020 17:36:10 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Tue, 29 Sep 2020 11:39:20 GMT, Jaikiran Pai wrote: >> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882? >> >> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds >> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`. This >> is due to the: if (len != -1 && len <= 65535) block which evaluates to `true` when the size of the manifest entry is >> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the >> `NegativeArraySizeException`. The commit in this PR fixes that issue by changing those `if/else` blocks to prevent >> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the >> necessary checks to throw the expected `OutOfMemoryError`. This commit also includes a jtreg test case which >> reproduces the issue and verifies the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Address the review comments and introduce an array size check in JarFile.getBytes() method itself If there is only modest improvement in test duration, we may want to add a jtreg timeout tag. Also, given the long duration but relative low priority of testing this, it perhaps should be moved out of Tier 1. I will look into those things after your next update. src/java.base/share/classes/java/util/jar/JarFile.java line 161: > 159: * OutOfMemoryError: Required array size too large > 160: */ > 161: private static final int MAX_BUFFER_SIZE = Integer.MAX_VALUE - 8; "/**" comments are generally only used for public documentation. For use here, probably a single line // comment would be sufficient to explain what this value is. This constant is also named, "MAX_ARRAY_SIZE" in various places, which seems more applicable to this case. src/java.base/share/classes/java/util/jar/JarFile.java line 801: > 799: if (len > MAX_BUFFER_SIZE) { > 800: throw new OutOfMemoryError("Required array size too large"); > 801: } I would just add a new `long zeSize` to read and check `ze.getSize()`, and then (int) cast it into `len`, as before. Then I think no changes would be needed past L802, `int bytesRead;` test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 45: > 43: public class LargeManifestOOMTest { > 44: > 45: Unneeded blank lines test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 83: > 81: } > 82: } > 83: Extra line test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 78: > 76: bw.write("OOM-Test: "); > 77: for (long i = 0; i < 2147483648L; i++) { > 78: bw.write("a"); As you probably noticed, this test takes a little while to run. One way to speed it up a little would be to write more characters at a time. While we're at it, we may as well make the Manifest well-formed by breaking it into 72-byte lines. See "Line length" under: https://docs.oracle.com/en/java/javase/15/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files Just write enough lines to exceed Integer.MAX_VALUE bytes. ------------- Changes requested by bchristi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/323 From bchristi at openjdk.java.net Wed Sep 30 17:36:10 2020 From: bchristi at openjdk.java.net (Brent Christian) Date: Wed, 30 Sep 2020 17:36:10 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 23 Sep 2020 15:09:44 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Address the review comments and introduce an array size check in JarFile.getBytes() method itself > > test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 60: > >> 58: final OutOfMemoryError oome = Assert.expectThrows(OutOfMemoryError.class, () -> jar.getManifest()); >> 59: // additionally verify that the OOM was for the right/expected reason >> 60: if (!"Required array size too large".equals(oome.getMessage())) { > > I wasn't too sure if I should add this additional check on the message of the `OutOfMemoryError`, but decided to do it > anyway, given that from what I remember there were some discussions in the `core-libs-dev` list a while back on the > exact messages that such OOMs should throw. So I guessed that it might be OK to rely on those messages in the tests > within this project. However, I am open to removing specific check if it's considered unnecessary. I think it's fine either way. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From lancea at openjdk.java.net Wed Sep 30 18:41:17 2020 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 30 Sep 2020 18:41:17 GMT Subject: RFR: 8242882: opening jar file with large manifest might throw NegativeArraySizeException [v2] In-Reply-To: References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com> Message-ID: On Wed, 30 Sep 2020 17:26:18 GMT, Brent Christian wrote: >> test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 60: >> >>> 58: final OutOfMemoryError oome = Assert.expectThrows(OutOfMemoryError.class, () -> jar.getManifest()); >>> 59: // additionally verify that the OOM was for the right/expected reason >>> 60: if (!"Required array size too large".equals(oome.getMessage())) { >> >> I wasn't too sure if I should add this additional check on the message of the `OutOfMemoryError`, but decided to do it >> anyway, given that from what I remember there were some discussions in the `core-libs-dev` list a while back on the >> exact messages that such OOMs should throw. So I guessed that it might be OK to rely on those messages in the tests >> within this project. However, I am open to removing specific check if it's considered unnecessary. > > I think it's fine either way. If you are going to validate the message, which I probably would not, it would be important to make sure it document if the message is changed in JarFile::getBytes, that the test needs updated. Otherwise it will be easy to miss. ------------- PR: https://git.openjdk.java.net/jdk/pull/323 From kvn at openjdk.java.net Wed Sep 30 20:05:42 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 30 Sep 2020 20:05:42 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 28 Sep 2020 19:08:04 GMT, Philippe Marschall wrote: >> @marschall I will sponsor it after you integrate the latest update. > > @vnkozlov done, I hope I now made it correctly with a merge commit for the latest merge conflict hs-tier1, hs-tier3-graal testing passed ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From github.com+471021+marschall at openjdk.java.net Wed Sep 30 20:07:31 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 30 Sep 2020 20:07:31 GMT Subject: Integrated: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. This pull request has now been integrated. Changeset: 2a406f3c Author: Philippe Marschall Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/2a406f3c Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package Reviewed-by: dholmes, alanb, psandoz, kvn, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From rriggs at openjdk.java.net Wed Sep 30 20:45:39 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 30 Sep 2020 20:45:39 GMT Subject: Integrated: 8252523: Add ASN.1 Formatter to work with test utility HexPrinter In-Reply-To: References: Message-ID: On Sun, 20 Sep 2020 13:54:02 GMT, Roger Riggs wrote: > # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter > > Debugging functions that utilize ASN.1, DER, and BER encoded streams is > difficult without test utilities to show the contents. > The ASN.1 formatter reads a stream and produces annotated output of the > tags, values, and structures. > When used with the test library jdk.test.lib.hexdump.HexPrinter the annotations are synchronized > with the hex formatted output. > > Small changes to HexPrinter are included to improve the output readability. > > > Example decoding of a .pem certificate: > SEQUENCE [910] > SEQUENCE [630] > CONTEXT cons 0 [3] > BYTE 2, > BYTE 3, > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > SEQUENCE [76] > SET [11] > SEQUENCE [9] > OBJECT ID [3] 2.5.4.6 (CountryName) > 'IN' > ... > SET [16] > SEQUENCE [14] > OBJECT ID [3] 2.5.4.3 (CommonName) > Client1 > SEQUENCE [30] > UTCTIME [13] '150526221718Z' > UTCTIME [13] '250523221718Z' > ... > SEQUENCE [290] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > NULL > BIT STRING [271] > CONTEXT cons 3 [123] > SEQUENCE [121] > SEQUENCE [9] > OBJECT ID [3] 2.5.29.19 (BasicConstraints) > OCTET STRING [2] > SEQUENCE [44] > OBJECT ID [9] 2.16.840.1.113730.1.13 > OCTET STRING [31] '..OpenSSL Generated Certificate' > SEQUENCE [29] > OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > OCTET STRING [22] > SEQUENCE [31] > OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > OCTET STRING [24] > SEQUENCE [13] > OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > NULL > BIT STRING [257] > When used with the HexPrinter test utility, the formatting of the > hexadecimal values is selected with the parameters to HexPrinter. > > 0000: 30 82 03 8e ; SEQUENCE [910] > 0004: 30 82 02 76 ; SEQUENCE [630] > 0008: a0 03 ; CONTEXT cons 0 [3] > 000a: 02 01 02 ; BYTE 2, > 000d: 02 01 03 ; BYTE 3, > 0010: 30 0d ; SEQUENCE [13] > 0012: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 001d: 05 00 ; NULL > 001f: 30 ; SEQUENCE [76] > 0020: 4c ; > 0021: 31 0b ; SET [11] > 0023: 30 09 ; SEQUENCE [9] > 0025: 06 03 55 04 06 ; OBJECT ID [3] 2.5.4.6 (CountryName) > 002a: 13 02 49 4e ; 'IN' > > ... ... > > 005b: 31 10 ; SET [16] > 005d: 30 0e ; SEQUENCE [14] > 005f: 06 ; OBJECT ID [3] 2.5.4.3 (CommonName) > 0060: 03 55 04 03 ; > 0064: 0c 07 43 6c 69 65 6e 74 31 ; Client1 > 006d: 30 1e ; SEQUENCE [30] > 006f: 17 ; UTCTIME [13] '150526221718Z' > 0070: 0d 31 35 30 35 32 36 32 32 31 37 31 38 5a ; > 007e: 17 0d ; UTCTIME [13] '250523221718Z' > 0080: 32 35 30 35 32 33 32 32 31 37 31 38 5a ; > > ... ... > > 00db: 30 82 01 22 ; SEQUENCE [290] > 00df: 30 ; SEQUENCE [13] > 00e0: 0d ; > 00e1: 06 09 2a 86 48 86 f7 0d 01 01 01 ; OBJECT ID [9] 1.2.840.113549.1.1.1 (RSA) > 00ec: 05 00 ; NULL > 00ee: 03 82 ; BIT STRING [271] > 00f0: 01 0f 00 30 82 01 0a 02 82 01 01 00 d8 70 03 54 ; > > ... > > 01f0: 0a 2d f5 de 59 3e d9 5e 74 93 d2 45 02 03 01 00 ; > 0200: 01 ; > 0201: a3 7b ; CONTEXT cons 3 [123] > 0203: 30 79 ; SEQUENCE [121] > 0205: 30 09 ; SEQUENCE [9] > 0207: 06 03 55 1d 13 ; OBJECT ID [3] 2.5.29.19 (BasicConstraints) > 020c: 04 02 30 00 ; OCTET STRING [2] > 0210: 30 2c ; SEQUENCE [44] > 0212: 06 09 60 86 48 01 86 f8 42 01 0d ; OBJECT ID [9] 2.16.840.1.113730.1.13 > 021d: 04 1f 16 ; OCTET STRING [31] '..OpenSSL Generated > Certificate' 0220: 1d 4f 70 65 6e 53 53 4c 20 47 65 6e 65 72 61 74 ; > 0230: 65 64 20 43 65 72 74 69 66 69 63 61 74 65 ; > 023e: 30 1d ; SEQUENCE [29] > 0240: 06 03 55 1d 0e ; OBJECT ID [3] 2.5.29.14 (SubjectKeyID) > 0245: 04 16 04 14 87 13 66 bc 7a 4d 8e ; OCTET STRING [22] > 0250: 98 e7 97 fb cc 56 41 27 c8 5e 4c b2 4d ; > 025d: 30 1f ; SEQUENCE [31] > 025f: 06 ; OBJECT ID [3] 2.5.29.35 (AuthorityKeyID) > 0260: 03 55 1d 23 ; > 0264: 04 18 30 16 80 14 1f 21 4f db 10 31 ; OCTET STRING [24] > 0270: d0 67 83 09 03 d3 cd fc 46 ec cf 1d 8b b4 ; > 027e: 30 0d ; SEQUENCE [13] > 0280: 06 09 2a 86 48 86 f7 0d 01 01 0b ; OBJECT ID [9] 1.2.840.113549.1.1.11 (SHA256withRSA) > 028b: 05 00 ; NULL > 028d: 03 82 01 ; BIT STRING [257] > 0290: 01 00 3e 2b 5f 32 aa f0 f7 52 2b ba f3 bb 07 ee ; > > ... > > 0390: 6d 94 ; This pull request has now been integrated. Changeset: 092c2277 Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/092c2277 Stats: 776 lines in 5 files changed: 766 ins; 1 del; 9 mod 8252523: Add ASN.1 Formatter to work with test utility HexPrinter Reviewed-by: weijun ------------- PR: https://git.openjdk.java.net/jdk/pull/268 From valeriep at openjdk.java.net Wed Sep 30 22:58:34 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Sep 2020 22:58:34 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v3] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 15:20:24 GMT, Weijun Wang wrote: >> This code change rewrites DerValue into a mostly immutable class and simplifies DerInputStream as a wrapper for a >> series of DerValues objects. DerInputBuffer is removed. >> All existing methods of DerValue and DerInputStream should still work with the exact same behavior, except for a few >> places where bugs are fixed. For example, Indefinite length must be used with a constructed tag. >> Except for the ObjectIdentifier class where DerInputBuffer is directly referenced, no other code is touched. > > Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since > the last revision: > - 8249783: Simplify DerValue and DerInputStream > - Merge remote-tracking branch 'origin/master' into 8249783 > - Enhance DerValue::getOctetString to be able to read multi-level constructed value. > - 8249783: Simplify DerValue and DerInputStream src/java.base/share/classes/sun/security/util/DerInputStream.java line 242: > 240: if ((tmp & 0x080) == 0x00) { // short form, 1 byte datum > 241: value = tmp; > 242: } else { // long form or indefinite Can't be indefinite here given the new check (line 233-235 above?) Move the indefinite comment upward? ------------- PR: https://git.openjdk.java.net/jdk/pull/232 From valeriep at openjdk.java.net Wed Sep 30 23:14:00 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 30 Sep 2020 23:14:00 GMT Subject: RFR: 8249783: Simplify DerValue and DerInputStream [v2] In-Reply-To: References: <6ZLh1tWMUIUWpC3F2gKz5zd6i31EBTmBps9vp4tWmfY=.371e92b0-9176-4512-9023-d3b5f8ca5d14@github.com> Message-ID: <1n6Otzkm4J_oWs33vCq-r-CI7N_AriCttdo006DTxm4=.6975a934-bc11-421e-810b-e55a79d49ea6@github.com> On Tue, 29 Sep 2020 03:09:54 GMT, Weijun Wang wrote: >> I just wonder why the different handling. Do you know why? Is it really used/needed, just curious? > > I don't know. Both methods are called, and `DerValue::getOctetString` is actual used in reality when reading content > data embedded inside PKCS #7 (which is not uncommon). All I can do now is to make them unchanged. Ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/232