From karl.scheibelhofer at gmx.net Fri Dec 1 10:46:32 2023 From: karl.scheibelhofer at gmx.net (Karl Scheibelhofer) Date: Fri, 1 Dec 2023 11:46:32 +0100 Subject: [External] : Re: PEM KeyStore Implementation In-Reply-To: References: <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com> <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com> <359C6447-EC6E-450E-8019-C592C0FADE57@oracle.com> Message-ID: Hi Tony, here is some thoughts about the PEM API Draft https://openjdk.org/jeps/8300911 considdering its use for implementing a PEM KeyStore: * Decoder reads from a Reader. Encoder should also support writing to a Writer for consistency. * Consider supporting byte[] or InputStream/OutputStream to hold the PEM encoded content. PEM is ASCII only anyway. There may be no need to go through characters and strings in some cases. Some applications may implement some kind of trial-and-error in detecting the encoding of keys or certificates. In this case, an application typically has byte[]/InputStream /OutputStream instead of String. * Encoded/Decoder may support Stream. * PEMEncoder and PEMDecoder may have an additional constructor taking an OutputStream/Writer or InputStream/Reader respectively, and an encode(SecurityObject) and decode() method as complement. Separate PEMStreamEncoder and PEMStreamDecoder classes may be even cleaner. Because in this case, these classes hold the Reader/Writer/ InputStream/OutputStream which is some kind of state. * A decoding operation reading from Reader/InputStream should read any explanatory text lines and provide means for an application to get them. Metadata in these lines may be necessary. The PEM keystore implementation (KarlScheibelhofer/java-crypto-tools: PEM KeyStore implementation with a JCA Provider. (github.com) ) uses such explanatory text lines to hold the alias name of the keystore entries. There is no other place in PEM to store this information. Transporting this metadata, one option could be separate methods, e.g. "Stream/List readPrefix(Reader/String/InputStream)" providing these lines in addition or empty, the decoder stopping at the "-----BEGIN" line. Applications can call readPrefix() and decode() alternately, or just decode() subsequently, if the lines are of no relevance. If the PEMDecoder does not provide means for transporting explanatory text lines, the application may need to extract them itself between "-----END" and "-----BEGIN" lines. To enable this, the decoder must not read a single character outside the "----" boundary lines. best regards, Karl Am Mi., 29. Nov. 2023 um 16:23 Uhr schrieb Karl Scheibelhofer < karl.scheibelhofer.75 at gmail.com>: > Hi Tony! > > I read the darft https://openjdk.org/jeps/8300911. It looks quite good to > me. > > To get a beffer feeling, I would like to use it. Is there a draft > implememtation of this API? > > I could give it a go with the draft version of PEM Keystore I did in KarlScheibelhofer/jdk > at pem-keystore (github.com) > > > regards, Karl > > GitHub - KarlScheibelhofer/jdk at pem-keystore > > JDK main-line development https://openjdk.org/projects/jdk - GitHub - > KarlScheibelhofer/jdk at pem-keystore > github.com > > ------------------------------ > *Von:* Anthony Scarpino > *Gesendet:* Freitag, 17. November 2023 20:52 > *An:* Karl Scheibelhofer > *Cc:* security-dev at openjdk.org > *Betreff:* Re: [External] : Re: PEM KeyStore Implementation > > As you may have seen, the PEM API draft is out: > https://openjdk.org/jeps/8300911 > > Tony > > > > On 10/18/23 3:00 AM, Karl Scheibelhofer wrote: > > Hi Sean, > > > > Yes, I can help with this new PEM API. > > > > Let me know, when there is something to review. > > > > Best regards, > > > > Karl > > > > > > On Tue, Oct 17, 2023, 19:12 Sean Mullan > >> wrote: > > > > Hi Karl, > > > > I discussed your proposal with some other colleagues. > > > > We generally feel a PEM KeyStore would be a useful addition to the > > JDK. This would alleviate usability issues that many users encounter > > when configuring and deploying applications that store keys or > > certificates in PEM files. > > > > However, we would like to first make sure that your PEM KeyStore > > implementation will work well with the PEM API that we will be > > proposing soon. We think this is a perfect opportunity to ensure > > they work well together and would appreciate your help in reviewing > > and validating the API - would you be interested in helping out? > > > > Once that is done, we can discuss next steps. > > > > Thanks, > > Sean > > > > > >> On Oct 5, 2023, at 9:41 AM, Sean Mullan >> >> wrote: > >> > >> > >> > >>> On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer > >>> >> > >>> wrote: > >>> > >>> Hi Sean, > >>> > >>> Yes, I had a look at the Contributing docs at the OpenJDK site > >>> before. I also signed the OCA. > >> > >> Great, thanks. > >> > >>> > >>> Honestly, I thought there would be some more reaction on the > >>> suggested PEM KeyStore. It would really be good to discuss the > >>> topic with others. Is there anything we can do to get others in > >>> sharing their thoughts on this? > >> > >> I think there is a fair amount of interest in it, but reviewing > >> something significant like this takes a bit of time, as I > >> mentioned in my prior email. Also, if we do decide to accept the > >> contribution, we want to make sure it works well with the PEM API > >> that we are working on - we hope to have a draft of a JEP for that > >> out in the next few weeks. So I think we probably need a few weeks > >> to review your contribution. > >> > >>> > >>> There is already a fair amount of documentation und unit tests. > >>> See https://github.com/KarlScheibelhofer/java-crypto-tools/ > >>> < > https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools/__;!!ACWV5N9M2RV99hQ!L4Oy66pyQcMu7F5jKCD98FvyWZGBlrWmmpnxhOkj2bAffn_KyL69pJh6Y36l9xIk-U4itzwJyPjubZxjk-SP2qN2C39SWwY$> > . > >> > >> Ok. > >> > >> ?Sean > >> > >>> > >>> Best regards, > >>> Karl > >>> > >>> On Wed, Oct 4, 2023, 13:58 Sean Mullan >>> >> wrote: > >>> > >>> Hi Karl, > >>> > >>> The OpenJDK Developer?s Guide includes a helpful section on > >>> Contributing to an OpenJDK Project [1]. I suggest you read > >>> through that if you have not already. In particular, have you > >>> signed the OCA? I don?t want to review your code/contribution > >>> until that is done. > >>> > >>> For this particular contribution, I don?t think there has > >>> been enough discussion and evaluation from members of the > >>> Security project. This would be a fairly major contribution. > >>> Keep in mind that a contribution doesn?t mean the work ends > >>> there. There would need to be documentation, tests, and > >>> ongoing support for the foreseeable future. We need to think > >>> about these aspects every time we add a new feature, so there > >>> needs to be a strong motivation for doing it. > >>> > >>> Thanks, > >>> Sean > >>> > >>> [1] > >>> https://openjdk.org/guide/#contributing-to-an-openjdk-project > >>> > > >>> > >>> > On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer > >>> >>> >> wrote: > >>> > > >>> > Hi All, > >>> > > >>> > I would like to contribute my PEM KeyStore implementation > >>> to the > >>> > OpenJDK, including integration in the OpenJDK source and > >>> creating a > >>> > pull request. > >>> > What is the recommended way to do this? > >>> > Who can create a suitable ticket in OpenJDK to document the > >>> > enhancement and to track the progress? > >>> > > >>> > What are the requirements for a pull request to get merged? > >>> > > >>> > Best regards > >>> > > >>> > Karl > >>> > > >>> > Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl > Scheibelhofer > >>> > >>> >>: > >>> >> > >>> >> Hi Tony! > >>> >> > >>> >> When the PEM API implementation becomes available it would > >>> make sense > >>> >> to use it inside the PEM Keystore implementation. It will > >>> reduce the > >>> >> code (the internal classes PemReader und PemWriter may > become > >>> >> obsolete), but it does not affect the functionality of the > PEM > >>> >> keystore. Users of the PEM Keystore won't experience a > >>> difference. > >>> >> > >>> >> Let me know when there is something for the PEM API and I > >>> will see if > >>> >> I can assist. > >>> >> > >>> >> I would suggest starting with PEM Keystore now and not > >>> wait for the > >>> >> PEM API, because the time schedule for it seems vague. I > >>> would try to > >>> >> refactor my current PEM Keystore implementation to > >>> integrate in the > >>> >> OpenJDK sun.security.provider package. I do not expect any > >>> API changes > >>> >> or other compatibility issues with existing code. Then > >>> consult this > >>> >> group for feedback before creating a pull request. > >>> >> > >>> >> When the PEM API becomes available, rework the PEM Keystore > >>> >> implementation to use it internally. > >>> >> > >>> >> What do you think? > >>> >> > >>> >> Best regards > >>> >> > >>> >> Karl Scheibelhofer > >>> >> > >>> >> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony Scarpino > >>> >> >>> >>: > >>> >>> > >>> >>> There are no doc links yet. > >>> >>> > >>> >>> Tony > >>> >>> > >>> >>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote: > >>> >>>> Hi Tony, > >>> >>>> > >>> >>>> The motivation was mostly about reading PEM keys and > >>> certificates > >>> >>>> generated somewhere else. This is common practice in > >>> enterprise > >>> >>>> environments I work in. Because corporate key material > >>> is subject to > >>> >>>> centralized key management, including generation, backup > >>> and rollover. > >>> >>>> PEM is the format most software products can handle. For > >>> Java > >>> >>>> applications, having a PEM KeyStore would reduce the > >>> often required > >>> >>>> additional step of converting PEM key and certificate in > >>> a Java > >>> >>>> Keystore/PKCS#12. > >>> >>>> Even truststores handling is easier with individual PEM > >>> certificates > >>> >>>> instead of a single PKCS#12 Truststore. Adding or > >>> deleting a single > >>> >>>> file instead of replacing the complete PKCS#12 store is > >>> less error > >>> >>>> prone and cleaner to track in version control. The > >>> additional benefit > >>> >>>> of a MAC in PKCS#12 adds little to no security in most > >>> cases. > >>> >>>> And being text based, PEM is more version control > >>> friendly than binary PKCS#12. > >>> >>>> > >>> >>>> But to enable sound support of PEM, I also implemented > >>> writing PEM > >>> >>>> keys and certificates. This way, one can use the JDK > >>> keytool to > >>> >>>> generate key and certificate signing requests in PEM > >>> format. Getting > >>> >>>> the certificate from the CA in PEM, one can use PEM > >>> throughout the > >>> >>>> process. > >>> >>>> > >>> >>>> Do you have any links or documentation on the PEM API > >>> JEP that you mentioned? > >>> >>>> > >>> >>>> Thank you for your feedback and best regards > >>> >>>> > >>> >>>> Karl > >>> >>>> > >>> >>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony > Scarpino > >>> >>>> >>> >>: > >>> >>>>> > >>> >>>>> Hi Karl > >>> >>>>> > >>> >>>>> The keystore is interesting and may have some value. > >>> Was your use case > >>> >>>>> mostly reading PEM keys and certificates generated > >>> elsewhere for use > >>> >>>>> with a particular application, maybe webservers? Did > >>> you see value in > >>> >>>>> writing to this keystore from Java? > >>> >>>>> > >>> >>>>> On the topic of PEM, I hope before the end of the year > >>> to have a PEM API > >>> >>>>> JEP. I would be interested in your API feedback from > >>> your keystore > >>> >>>>> experiences. I think if this keystore contribution was > >>> accepted, it > >>> >>>>> should wait so it can use that API. > >>> >>>>> > >>> >>>>> thanks > >>> >>>>> > >>> >>>>> Tony > >>> >>>>> > >>> >>>>> > >>> >>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote: > >>> >>>>>> Hi, > >>> >>>>>> > >>> >>>>>> Working with Java and the JCA KeyStore for decades, I > >>> came across > >>> >>>>>> many situations where I thought it would be convenient > >>> to be > >>> >>>>>> able to load private keys and certificates in PEM > >>> format directly > >>> >>>>>> using the KeyStore API. Without the need to convert > >>> them to PKCS#12/JKS. > >>> >>>>>> > >>> >>>>>> You can find my implementation of a PEM KeyStore in > >>> >>>>>> > >>> > https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ > < > https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$> > . > >>> >>>>>> > >>> >>>>>> I wondered if it would make sense to integrate such an > >>> implementation > >>> >>>>>> in one of the standard providers of OpenJDK - like the > >>> SUN provider. > >>> >>>>>> What do you think? > >>> >>>>>> > >>> >>>>>> Best regards > >>> >>>>>> > >>> >>>>>> Karl > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ascarpino at openjdk.org Fri Dec 1 22:42:47 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 1 Dec 2023 22:42:47 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v2] In-Reply-To: References: Message-ID: > Hi, > > I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. > > The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. > > The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: comments update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16487/files - new: https://git.openjdk.org/jdk/pull/16487/files/cf9784c9..80bf02b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=00-01 Stats: 126 lines in 13 files changed: 21 ins; 42 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/16487.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16487/head:pull/16487 PR: https://git.openjdk.org/jdk/pull/16487 From ascarpino at openjdk.org Fri Dec 1 22:42:49 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 1 Dec 2023 22:42:49 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v2] In-Reply-To: <1UBq7CzhzKPLUPMakJ_ZnqQ_crpIyvfFoY9l1muFwS0=.ae895afb-e618-4c24-9001-68b0a01043a7@github.com> References: <1UBq7CzhzKPLUPMakJ_ZnqQ_crpIyvfFoY9l1muFwS0=.ae895afb-e618-4c24-9001-68b0a01043a7@github.com> Message-ID: On Tue, 28 Nov 2023 08:34:21 GMT, Daniel Jeli?ski wrote: >> The second sentence says what the optimizations is. > > well I was under the impression that the bulk of the optimization comes from using modified `engineGetOutputSize` that does not allocate when isUpdate== true and decrypting. That's not documented anywhere. It used the `engineGetOutputSize` from ChaCha20Cipher before the change. The biggest gain no doing unnecessary copying for direct bytebuffers. For a decrypt op, it would copy the bytebuffer into and array, then copy the array into the internal buffer. I try to minimize that by doing only one copy, bytebuffer -> internal buffer. >> I don't see a testing issue there, but that's better memory usage. I probably copied this code over from AES/GCM where it's blocksized data and `in` and `out` could have been different sizes. But CC20 can use this optimization because it's a streaming cipher. > > I was talking about the second line: > > doUpdate(in, 0, in.length, out, out.length); > > this tells the doUpdate operation to start writing to `out` at `out.length`; that should have triggered an exception in testing. Ah yes.. that's a mistake ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1412631516 PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1412493845 From abakhtin at openjdk.org Fri Dec 1 23:39:55 2023 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Fri, 1 Dec 2023 23:39:55 GMT Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v2] In-Reply-To: References: Message-ID: > Please review the proposed fix. > > The patch loads system root certificates from the MacOS Keychain with TrustSettings. > It allows to build a trusted certificate path using the MacOS Keychain store only. Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Mark trust anchor certificates readonly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16722/files - new: https://git.openjdk.org/jdk/pull/16722/files/b0d91794..db98b7c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16722&range=00-01 Stats: 33 lines in 2 files changed: 21 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/16722.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16722/head:pull/16722 PR: https://git.openjdk.org/jdk/pull/16722 From duke at openjdk.org Sat Dec 2 01:06:42 2023 From: duke at openjdk.org (1keep2keepFaith) Date: Sat, 2 Dec 2023 01:06:42 GMT Subject: RFR: 8320362: Load anchor certificates from Keychain keystore [v2] In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 23:39:55 GMT, Alexey Bakhtin wrote: >> Please review the proposed fix. >> >> The patch loads system root certificates from the MacOS Keychain with TrustSettings. >> It allows to build a trusted certificate path using the MacOS Keychain store only. > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > Mark trust anchor certificates readonly Marked as reviewed by 1keep2keepFaith at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/16722#pullrequestreview-1760742271 From duke at openjdk.org Sat Dec 2 18:23:44 2023 From: duke at openjdk.org (Gregor Purdy) Date: Sat, 2 Dec 2023 18:23:44 GMT Subject: RFR: 8318983: Fix comment typo in PKCS12Passwd.java Message-ID: 8318983: Fix comment typo in PKCS12Passwd.java ------------- Commit messages: - Fix comment typo in PKCS12Passwd.java Changes: https://git.openjdk.org/jdk/pull/14762/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14762&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318983 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14762.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14762/head:pull/14762 PR: https://git.openjdk.org/jdk/pull/14762 From duke at openjdk.org Sat Dec 2 18:23:45 2023 From: duke at openjdk.org (Gregor Purdy) Date: Sat, 2 Dec 2023 18:23:45 GMT Subject: RFR: 8318983: Fix comment typo in PKCS12Passwd.java In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 20:12:47 GMT, Gregor Purdy wrote: > 8318983: Fix comment typo in PKCS12Passwd.java I tried filing an issue to reference but could not. Could someone please help get this PR merged? Could someone with the ability to file an issue or bypass that requirement please help? @mdinacci @hns @landonf @joebowbeer Fixed the title of the PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/14762#issuecomment-1705541337 PR Comment: https://git.openjdk.org/jdk/pull/14762#issuecomment-1744087229 PR Comment: https://git.openjdk.org/jdk/pull/14762#issuecomment-1837220861 From weijun at openjdk.org Sat Dec 2 18:23:46 2023 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 2 Dec 2023 18:23:46 GMT Subject: RFR: 8318983: Fix comment typo in PKCS12Passwd.java In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 20:12:47 GMT, Gregor Purdy wrote: > 8318983: Fix comment typo in PKCS12Passwd.java Sorry about not noticing this earlier. I've filed https://bugs.openjdk.org/browse/JDK-8318983. Please update the PR title. Thanks for coming back! The jcheck failure ~above~below suggests you rewrite the title to something like "8318983: Fix comment typo in PKCS12Passwd.java". You can also read the title of other PRs as examples. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14762#issuecomment-1782974811 PR Comment: https://git.openjdk.org/jdk/pull/14762#issuecomment-1783344025 From duke at openjdk.org Sat Dec 2 18:23:47 2023 From: duke at openjdk.org (Gregor Purdy) Date: Sat, 2 Dec 2023 18:23:47 GMT Subject: RFR: 8318983: Fix comment typo in PKCS12Passwd.java In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 14:04:02 GMT, Weijun Wang wrote: > Sorry about not noticing this earlier. I've filed https://bugs.openjdk.org/browse/JDK-8318983. Please update the PR title. Thanks @wangweij! I added a suffix "; FIXES: JDK-8318983" to the title. Hope that helps. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14762#issuecomment-1783261279 From weijun at openjdk.org Sat Dec 2 19:26:41 2023 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 2 Dec 2023 19:26:41 GMT Subject: RFR: 8318983: Fix comment typo in PKCS12Passwd.java In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 20:12:47 GMT, Gregor Purdy wrote: > 8318983: Fix comment typo in PKCS12Passwd.java The change looks good. You can type the `/integrate` command now. ------------- Marked as reviewed by weijun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/14762#pullrequestreview-1760944598 From duke at openjdk.org Sat Dec 2 20:11:37 2023 From: duke at openjdk.org (Gregor Purdy) Date: Sat, 2 Dec 2023 20:11:37 GMT Subject: RFR: 8318983: Fix comment typo in PKCS12Passwd.java In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 18:33:23 GMT, Weijun Wang wrote: >> 8318983: Fix comment typo in PKCS12Passwd.java > > Thanks for coming back! The jcheck failure ~above~below suggests you rewrite the title to something like "8318983: Fix comment typo in PKCS12Passwd.java". You can also read the title of other PRs as examples. Thanks @wangweij could you please sponsor? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14762#issuecomment-1837242721 From duke at openjdk.org Sat Dec 2 21:16:50 2023 From: duke at openjdk.org (Gregor Purdy) Date: Sat, 2 Dec 2023 21:16:50 GMT Subject: Integrated: 8318983: Fix comment typo in PKCS12Passwd.java In-Reply-To: References: Message-ID: On Mon, 3 Jul 2023 20:12:47 GMT, Gregor Purdy wrote: > 8318983: Fix comment typo in PKCS12Passwd.java This pull request has now been integrated. Changeset: 94984698 Author: Gregor Purdy Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/949846986f572dfb82912e7d71e7bfd37a90871e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8318983: Fix comment typo in PKCS12Passwd.java Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/14762 From jwaters at openjdk.org Sun Dec 3 10:34:36 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 3 Dec 2023 10:34:36 GMT Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi [v3] In-Reply-To: References: Message-ID: On Thu, 16 Nov 2023 04:40:53 GMT, Julian Waters wrote: >> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > NULL to nullptr in sspi.cpp Anyone? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1837437283 From djelinski at openjdk.org Mon Dec 4 08:52:41 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 4 Dec 2023 08:52:41 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v2] In-Reply-To: References: Message-ID: On Fri, 1 Dec 2023 22:42:47 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. >> >> The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. >> >> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > comments update src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 80: > 78: return; > 79: } > 80: if (buf == null) { leftover from previous implementation; buf is never null. src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java line 707: > 705: } catch (AEADBadTagException e) { > 706: // exception is never thrown by update ops > 707: return 0; Suggestion: throw new AssertionError(e); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1413444768 PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1413463109 From djelinski at openjdk.org Mon Dec 4 08:52:43 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 4 Dec 2023 08:52:43 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v2] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 00:49:49 GMT, Anthony Scarpino wrote: >> src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 94: >> >>> 92: } else { >>> 93: if (buf.length < (count + len)) { >>> 94: buf = Arrays.copyOf(buf, count + len); >> >> this will copy a lot if the user performs many small writes, for example when decrypting with CipherInputStream; see `AESGCMCipherOutputStream` benchmark. > > As I understand the `ByteArrayOutputStream` code, the `ArraysSupport.newLength()` will double the allocation each time. So if the buffer is 1k size and it wants to add one more byte, the method will allocate 2k. > I agree that in my change, if you send one byte at a time, it will be doing a lot of allocating. But I don't believe that is the general case. If you have examples of apps doing small allocations, let me know and I can come up with a different scheme. But at this point I thought it was a bitter risk more allocations in the less-likely situation, than unused allocation in what I see as a more common case. Well, as stated above, any application using CipherInputStream will do O(N) reallocations here, bringing back [JDK-8298249](https://bugs.openjdk.org/browse/JDK-8298249); you might want to check with the reporter if this actually affects any real applications. For reference, the results with this patch: Benchmark (dataSize) (keyLength) (provider) Mode Cnt Score Error Units AESGCMCipherOutputStream.decrypt 16384 128 thrpt 40 30325.669 ? 1616.428 ops/s AESGCMCipherOutputStream.decrypt 1048576 128 thrpt 40 7.034 ? 0.479 ops/s Baseline: Benchmark (dataSize) (keyLength) (provider) Mode Cnt Score Error Units AESGCMCipherOutputStream.decrypt 16384 128 thrpt 40 52171.497 ? 6229.841 ops/s AESGCMCipherOutputStream.decrypt 1048576 128 thrpt 40 470.844 ? 179.817 ops/s i.e. with the patch, decryption is 40% slower for 16KB stream, 98% (or 50x) slower for 1MB stream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1413461835 From jwaters at openjdk.org Mon Dec 4 09:26:57 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 4 Dec 2023 09:26:57 GMT Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi [v4] In-Reply-To: References: Message-ID: > I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels Julian Waters 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: - Merge branch 'openjdk:master' into patch-9 - NULL to nullptr in sspi.cpp - Missed labels in sspi.cpp - Actually resolve issues with goto labels in sspi ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16682/files - new: https://git.openjdk.org/jdk/pull/16682/files/1e33e810..f4108192 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16682&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16682&range=02-03 Stats: 75439 lines in 2183 files changed: 42985 ins; 22345 del; 10109 mod Patch: https://git.openjdk.org/jdk/pull/16682.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16682/head:pull/16682 PR: https://git.openjdk.org/jdk/pull/16682 From weijun at openjdk.org Mon Dec 4 14:51:42 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 4 Dec 2023 14:51:42 GMT Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi [v4] In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 09:26:57 GMT, Julian Waters wrote: >> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels > > Julian Waters 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: > > - Merge branch 'openjdk:master' into patch-9 > - NULL to nullptr in sspi.cpp > - Missed labels in sspi.cpp > - Actually resolve issues with goto labels in sspi I don't like all those duplicated lines. Why do you think the previous fix is a hack? I would guess the C++ designers are also not happy of this restriction so they provide us a way to avoid it. Maybe they will enhance it again sometime in the future? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1838804739 From weijun at openjdk.org Mon Dec 4 15:04:04 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 4 Dec 2023 15:04:04 GMT Subject: RFR: 8306688: Support Windows serialized keystores (SST files) In-Reply-To: References: Message-ID: On Thu, 1 Jun 2023 17:11:01 GMT, Mat Carter wrote: >> Added ability to load keystores from SST files on Windows. Example usage: >> >> KeyStore keyStore = KeyStore.getInstance("Windows-SST"); >> try (FileInputStream fis = new FileInputStream("mykeystore.sst")) { >> keyStore.load(fis, null); >> } >> >> Note that its not limited to file streams, it can be any stream. >> >> The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional >> >> tier1 tests for linux/macos/Windows for x86_64 > > Thanks for the explanation, I understand your point now. I'll make changes to support writing to the SST @macarte Please remove the Fix Version/s field of this bug now that it will not go into jdk22. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1838828661 From duke at openjdk.org Mon Dec 4 16:45:06 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Mon, 4 Dec 2023 16:45:06 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes Message-ID: Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`. This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly. While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. As a note to reviewers, this PR includes the following intended updates: - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes` - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected` - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs` - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected` - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected` - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method - Updated copyright in all affected files If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: make test TEST="test/jdk/java/util/jar" make test TEST="test/jdk/java/util/zip" ------------- Commit messages: - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes Changes: https://git.openjdk.org/jdk/pull/16952/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16952&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321274 Stats: 34 lines in 11 files changed: 0 ins; 0 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/16952.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16952/head:pull/16952 PR: https://git.openjdk.org/jdk/pull/16952 From macarte at openjdk.org Mon Dec 4 17:07:58 2023 From: macarte at openjdk.org (Mat Carter) Date: Mon, 4 Dec 2023 17:07:58 GMT Subject: RFR: 8306688: Support Windows serialized keystores (SST files) In-Reply-To: References: Message-ID: On Fri, 26 May 2023 21:09:35 GMT, Mat Carter wrote: > Added ability to load keystores from SST files on Windows. Example usage: > > KeyStore keyStore = KeyStore.getInstance("Windows-SST"); > try (FileInputStream fis = new FileInputStream("mykeystore.sst")) { > keyStore.load(fis, null); > } > > Note that its not limited to file streams, it can be any stream. > > The feature is behind a runtime flag ("sun.security.mscapi.keyStoreSSTSupport") as the KeyStore must have an input stream, but the JCK tests assume an input stream is optional > > tier1 tests for linux/macos/Windows for x86_64 Removed From: Weijun Wang ***@***.***> Date: Monday, December 4, 2023 at 7:01 AM To: openjdk/jdk ***@***.***> Cc: Mat Carter ***@***.***>, Mention ***@***.***> Subject: Re: [openjdk/jdk] 8306688: Support Windows serialized keystores (SST files) (PR #14187) @macarte Please remove the Fix Version/s field of this bug now that it will not go into jdk22. ? Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***> ------------- PR Comment: https://git.openjdk.org/jdk/pull/14187#issuecomment-1839088753 From lancea at openjdk.org Mon Dec 4 18:12:37 2023 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 4 Dec 2023 18:12:37 GMT Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bjorsnos wrote: > Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalAttributes`. > > This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT` > > The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does. > > To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalAttributes` and update related methods, parameters and comments accordingly. > > While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. > > As a note to reviewers, this PR includes the following intended updates: > > - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalAttributes` > - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalAttributes` and `getExternalAttributes` > - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalAttrsDetected` > - Rename a local variable in `JarSigner.writeEntry` to `externalAttrs` > - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalAttrsDetected` > - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.attributes.detected` > - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalAttrs`, also updated two references to 'extra attributes' in this method > - Updated copyright in all affected files > > If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files. > > I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean: > > > make test TEST="test/jdk/java/util/jar" > make test TEST="test/jdk/java/util/zip" Thank you for the contribution Eirik. I will take a peek at this once we are able to push changes for JDK 23 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-1839198963 From duke at openjdk.org Mon Dec 4 21:00:47 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 4 Dec 2023 21:00:47 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v5] In-Reply-To: References: Message-ID: <85BDN48baBNhFSFWGC7S43dfTsONDvvx6xFckPOK7fA=.8ad2e0ef-125b-47fd-8806-619b18b9bd9b@github.com> > Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: > - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: Standardized serial number print format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16834/files - new: https://git.openjdk.org/jdk/pull/16834/files/a5a733bb..3a94220e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=03-04 Stats: 25 lines in 11 files changed: 4 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/16834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16834/head:pull/16834 PR: https://git.openjdk.org/jdk/pull/16834 From duke at openjdk.org Tue Dec 5 00:18:47 2023 From: duke at openjdk.org (duke) Date: Tue, 5 Dec 2023 00:18:47 GMT Subject: Withdrawn: 6478546: FileInputStream.read() throws OutOfMemoryError when there is plenty available In-Reply-To: References: Message-ID: On Fri, 21 Jul 2023 22:40:00 GMT, Brian Burkhalter wrote: > Limit native memory allocation and move write loop from the native layer into Java. This change should make the OOME reported in the issue much less likely. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14981 From jwaters at openjdk.org Tue Dec 5 07:03:34 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 5 Dec 2023 07:03:34 GMT Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi [v4] In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 14:49:24 GMT, Weijun Wang wrote: > I don't like all those duplicated lines. Why do you think the previous fix is a hack? I would guess the C++ designers are also not happy of this restriction so they provide us a way to avoid it. Maybe they will enhance it again sometime in the future? The previous fix of splitting it into a declaration and assignment is not any safer than just one single definition when it comes to being jumped over by gotos, so it is simply a no-op to silence well intentioned compiler warnings, and also has the added downside of not being obvious why it is structured like that, and can be easily undone by future changes not realizing this will break compilation. Unfortunately the only true way to fix this is to remove the gotos that are affected, and making the control flow explicit, though there might be a better solution that I haven't thought of yet. Maybe moving the labels into a common place where it doesn't jump over locals might just work ------------- PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1840120553 From coffeys at openjdk.org Tue Dec 5 10:45:35 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 5 Dec 2023 10:45:35 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v5] In-Reply-To: <85BDN48baBNhFSFWGC7S43dfTsONDvvx6xFckPOK7fA=.8ad2e0ef-125b-47fd-8806-619b18b9bd9b@github.com> References: <85BDN48baBNhFSFWGC7S43dfTsONDvvx6xFckPOK7fA=.8ad2e0ef-125b-47fd-8806-619b18b9bd9b@github.com> Message-ID: On Mon, 4 Dec 2023 21:00:47 GMT, Ben Perez wrote: >> Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: >> - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` >> - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` >> - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > Standardized serial number print format Edits are heading in the right direction. How about refactoring the Debug utility methods ? `toString(byte[]) `might be better as `toHexString(byte[])` you could also introduce a `toHexString(BigInteger)` method in Debug. That will save you the extra `toByteArray()` call you're making in the various call sites. It should be possible to extend code coverage in an existing x509 test also to ensure the serial number `toString `output is as expected and to ensure we don't regress in this area in the future etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16834#issuecomment-1840491001 From weijun at openjdk.org Tue Dec 5 15:09:40 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 5 Dec 2023 15:09:40 GMT Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi [v4] In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 09:26:57 GMT, Julian Waters wrote: >> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels > > Julian Waters 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: > > - Merge branch 'openjdk:master' into patch-9 > - NULL to nullptr in sspi.cpp > - Missed labels in sspi.cpp > - Actually resolve issues with goto labels in sspi I still don't like this solution: 1. Duplicated lines. 2. There are other `goto`s in this file. I know they happen to be unaffected, but if `goto` is not recommended in C++ it looks unfair to remove some and keep some. Can we throw and catch exceptions? Or, how difficult is it to rewrite to simply C? Just substitute `new` and `delete` with `malloc` and `free`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1840980100 From duke at openjdk.org Tue Dec 5 18:37:48 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 5 Dec 2023 18:37:48 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v6] In-Reply-To: References: Message-ID: <30aYPErUg1gV6aOfs1fj2GiDOv49_RwdiABFBODCs-4=.501d12a8-7e4e-4376-8dd5-e503701198a9@github.com> > Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: > - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: refactored serial number printing into a new toString method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16834/files - new: https://git.openjdk.org/jdk/pull/16834/files/3a94220e..bd2a3403 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=04-05 Stats: 27 lines in 15 files changed: 4 ins; 1 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/16834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16834/head:pull/16834 PR: https://git.openjdk.org/jdk/pull/16834 From anthony.scarpino at oracle.com Tue Dec 5 22:35:47 2023 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 5 Dec 2023 14:35:47 -0800 Subject: [External] : Re: PEM KeyStore Implementation In-Reply-To: References: <3b644da6-a6b9-7a0e-67c3-9ced4e39e6d8@oracle.com> <7d4fb455-d637-ecc3-7e2a-8f1b8dc6ef36@oracle.com> <359C6447-EC6E-450E-8019-C592C0FADE57@oracle.com> Message-ID: <4cb7c64c-e6fe-48ce-8542-039d29fed505@oracle.com> On 12/1/23 2:46 AM, Karl Scheibelhofer wrote: > Hi Tony, > > here is some thoughts about the PEM API Draft > https://openjdk.org/jeps/8300911 > considdering its use for implementing a PEM KeyStore: > > * Decoder reads from a Reader. Encoder should also support writing to > a Writer for consistency. At one point Writer was part of the API. But after seeing that Writer already has a write(String) method, there was no additional functionality the PEM API could offer that the user couldn't code themselves. Writer.write(PEMEncoder.encode(data)); vs PEMEncoder.encodeToWriter(data, Writer); > > * Consider supporting byte[] or InputStream/OutputStream to hold the > PEM encoded content. PEM is ASCII only anyway. There may be no need > to go through characters and strings in some cases. Some applications > may implement some kind of trial-and-error in detecting the encoding > of keys or certificates. In this case, an application typically has > byte[]/InputStream /OutputStream instead of String. I had thought about byte[] and opted against it for similar reasons as above. The PEMDecoder method that took a byte[] would just do a new String(byte[]). I also felt there was potential confusion with data formats in a byte[]. I felt byte[] is more likely to be in a binary format (PKCS8 or X509) and PEM as a String. That the reason EncodedKeySpec is accepted as a input type instead of byte[]. That forces the developer to know what data they are passing into the API. Any of the Input/OutputStream classes, I figured the use can pass their IO object into InputStreamReader. > > * Encoded/Decoder may support Stream. > > * PEMEncoder and PEMDecoder may have an additional constructor taking > an OutputStream/Writer or InputStream/Reader respectively, and an > encode(SecurityObject) and decode() method as complement. Separate > PEMStreamEncoder and PEMStreamDecoder classes may be even cleaner. > Because in this case, these classes hold the Reader/Writer/ > InputStream/OutputStream which is some kind of state. I had looked at Stream, but hadn't found a strong situation to use it. It sounds interesting in practice, and I can see it being useful for a Keystore. But I'm not sure much beyond that. I'd have to think about it and if it belonged in the same class or a new one. > > * A decoding operation reading from Reader/InputStream should read > any explanatory text lines and provide means for an application to > get them. Metadata in these lines may be necessary. The PEM keystore > implementation (KarlScheibelhofer/java-crypto-tools: PEM KeyStore > implementation with a JCA Provider. (github.com) > ) uses such > explanatory text lines to hold the alias name of the keystore > entries. There is no other place in PEM to store this information. > Transporting this metadata, one option could be separate methods, > e.g. "Stream/List > readPrefix(Reader/String/InputStream)" providing these lines in > addition or empty, the decoder stopping at the "-----BEGIN" line. > Applications can call readPrefix() and decode() alternately, or just > decode() subsequently, if the lines are of no relevance. If the > PEMDecoder does not provide means for transporting explanatory text > lines, the application may need to extract them itself between > "-----END" and "-----BEGIN" lines. To enable this, the decoder must > not read a single character outside the "----" boundary lines. This topic has come up a few times. I do not feel it is the responsibility of the PEM API to read and write other data. I have tried to keep the API simple and focused on only encoding and decoding PEM data. I view the metadata as the responsibility of the application, for it knows more about the non-PEM data than the PEM API would. Making the PEM API responsible for returning the non-PEM data leaves too many unknowns. Does the API return data line-by-line, per byte, all in one byte[], or does it return it as a List? In the end, the application still must parse this metadata, as you know with your KeyStore. All that being said, I have no problem with a future PEMReader or PEMWriter class that combines the PEM API with a Reader/Writer and/or Input/OutputStream. As part of the contribution of the PEM Keystore, we could work on an IO class that could eventually be part of the public API. It's better to have a use case to better understand the problems. As far as viewing to the API code. It's mostly ready, but not ready for public release just yet. Maybe after the first of the year. Thanks Tony > > best regards, Karl > > Am Mi., 29. Nov. 2023 um 16:23 Uhr schrieb Karl Scheibelhofer > >: > > Hi Tony! > > I read the darft https://openjdk.org/jeps/8300911 > . It looks quite good to me. > > To get a beffer feeling, I would like to use it. Is there a draft > implememtation of this API? > > I could give it a go with the draft version of PEM Keystore I did in > KarlScheibelhofer/jdk at pem-keystore (github.com) > > > regards, Karl > > > GitHub - KarlScheibelhofer/jdk at pem-keystore > > > JDK main-line development https://openjdk.org/projects/jdk > - GitHub - KarlScheibelhofer/jdk > at pem-keystore github.com > > > > > ------------------------------------------------------------------------ > > *Von:* Anthony Scarpino > *Gesendet:* Freitag, 17. > November 2023 20:52 *An:* Karl Scheibelhofer > > > *Cc:* security-dev at openjdk.org > > > *Betreff:* Re: [External] : Re: PEM KeyStore Implementation As you > may have seen, the PEM API draft is out: > https://openjdk.org/jeps/8300911 > > Tony > > > > On 10/18/23 3:00 AM, Karl Scheibelhofer wrote: >> Hi Sean, >> >> Yes, I can help with this new PEM API. >> >> Let me know, when there is something to review. >> >> Best regards, >> >> Karl >> >> >> On Tue, Oct 17, 2023, 19:12 Sean Mullan > > >> wrote: >> >> Hi Karl, >> >> I discussed your proposal with some other colleagues. >> >> We generally feel a PEM KeyStore would be a useful addition to the >> JDK. This would alleviate usability issues that many users >> encounter when configuring and deploying applications that store >> keys or certificates in PEM files. >> >> However, we would like to first make sure that your PEM KeyStore >> implementation will work well with the PEM API that we will be >> proposing soon. We think this is a perfect opportunity to ensure >> they work well together and would appreciate your help in >> reviewing and validating the API - would you be interested in >> helping out? >> >> Once that is done, we can discuss next steps. >> >> Thanks, Sean >> >> >>> On Oct 5, 2023, at 9:41 AM, Sean Mullan >> >> >> wrote: >>> >>> >>> >>>> On Oct 5, 2023, at 2:48 AM, Karl Scheibelhofer >>>> >>> > >> >>>> wrote: >>>> >>>> Hi Sean, >>>> >>>> Yes, I had a look at the Contributing docs at the OpenJDK site >>>> before. I also signed the OCA. >>> >>> Great, thanks. >>> >>>> >>>> Honestly, I thought there would be some more reaction on the >>>> suggested PEM KeyStore. It would really be good to discuss the >>>> topic with others. Is there anything we can do to get others >>>> in sharing their thoughts on this? >>> >>> I think there is a fair amount of interest in it, but reviewing >>> something significant like this takes a bit of time, as I >>> mentioned in my prior email. Also, if we do decide to accept the >>> contribution, we want to make sure it works well with the PEM >>> API that we are working on - we hope to have a draft of a JEP for >>> that out in the next few weeks. So I think we probably need a few >>> weeks to review your contribution. >>> >>>> >>>> There is already a fair amount of documentation und unit >>>> tests. See >>>> https://github.com/KarlScheibelhofer/java-crypto-tools/ > > > >>> >> > >>> . >>> >>> Ok. >>> >>> ?Sean >>> >>>> >>>> Best regards, Karl >>>> >>>> On Wed, Oct 4, 2023, 13:58 Sean Mullan >>> >>> >> wrote: >>>> >>>> Hi Karl, >>>> >>>> The OpenJDK Developer?s Guide includes a helpful section on >>>> Contributing to an OpenJDK Project [1]. I suggest you read >>>> through that if you have not already. In particular, have you >>>> signed the OCA? I don?t want to review your code/contribution >>>> until that is done. >>>> >>>> For this particular contribution, I don?t think there has been >>>> enough discussion and evaluation from members of the Security >>>> project. This would be a fairly major contribution. Keep in >>>> mind that a contribution doesn?t mean the work ends there. >>>> There would need to be documentation, tests, and ongoing >>>> support for the foreseeable future. We need to think about >>>> these aspects every time we add a new feature, so there needs >>>> to be a strong motivation for doing it. >>>> >>>> Thanks, Sean >>>> >>>> [1] >>>> https://openjdk.org/guide/#contributing-to-an-openjdk-project > >>>> > >>>> >>>>> On Oct 4, 2023, at 4:21 AM, Karl Scheibelhofer >>>> >>> >>>> >> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> I would like to contribute my PEM KeyStore implementation >>>> to the >>>>> OpenJDK, including integration in the OpenJDK source and >>>> creating a >>>>> pull request. What is the recommended way to do this? Who can >>>>> create a suitable ticket in OpenJDK to document the >>>>> enhancement and to track the progress? >>>>> >>>>> What are the requirements for a pull request to get merged? >>>>> >>>>> Best regards >>>>> >>>>> Karl >>>>> >>>>> Am Mi., 20. Sept. 2023 um 11:26 Uhr schrieb Karl >>>>> Scheibelhofer >>>> >>>> >>> >>: >>>>>> >>>>>> Hi Tony! >>>>>> >>>>>> When the PEM API implementation becomes available it would >>>> make sense >>>>>> to use it inside the PEM Keystore implementation. It will >>>> reduce the >>>>>> code (the internal classes PemReader und PemWriter may >>>>>> become obsolete), but it does not affect the functionality >>>>>> of the PEM keystore. Users of the PEM Keystore won't >>>>>> experience a >>>> difference. >>>>>> >>>>>> Let me know when there is something for the PEM API and I >>>> will see if >>>>>> I can assist. >>>>>> >>>>>> I would suggest starting with PEM Keystore now and not >>>> wait for the >>>>>> PEM API, because the time schedule for it seems vague. I >>>> would try to >>>>>> refactor my current PEM Keystore implementation to >>>> integrate in the >>>>>> OpenJDK sun.security.provider package. I do not expect any >>>> API changes >>>>>> or other compatibility issues with existing code. Then >>>> consult this >>>>>> group for feedback before creating a pull request. >>>>>> >>>>>> When the PEM API becomes available, rework the PEM >>>>>> Keystore implementation to use it internally. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Best regards >>>>>> >>>>>> Karl Scheibelhofer >>>>>> >>>>>> Am Di., 19. Sept. 2023 um 22:31 Uhr schrieb Anthony >>>>>> Scarpino >>>>> >>>> >>: >>>>>>> >>>>>>> There are no doc links yet. >>>>>>> >>>>>>> Tony >>>>>>> >>>>>>> On 9/10/23 1:04 AM, Karl Scheibelhofer wrote: >>>>>>>> Hi Tony, >>>>>>>> >>>>>>>> The motivation was mostly about reading PEM keys and >>>> certificates >>>>>>>> generated somewhere else. This is common practice in >>>> enterprise >>>>>>>> environments I work in. Because corporate key material >>>> is subject to >>>>>>>> centralized key management, including generation, >>>>>>>> backup >>>> and rollover. >>>>>>>> PEM is the format most software products can handle. >>>>>>>> For >>>> Java >>>>>>>> applications, having a PEM KeyStore would reduce the >>>> often required >>>>>>>> additional step of converting PEM key and certificate >>>>>>>> in >>>> a Java >>>>>>>> Keystore/PKCS#12. Even truststores handling is easier >>>>>>>> with individual PEM >>>> certificates >>>>>>>> instead of a single PKCS#12 Truststore. Adding or >>>> deleting a single >>>>>>>> file instead of replacing the complete PKCS#12 store >>>>>>>> is >>>> less error >>>>>>>> prone and cleaner to track in version control. The >>>> additional benefit >>>>>>>> of a MAC in PKCS#12 adds little to no security in most >>>> cases. >>>>>>>> And being text based, PEM is more version control >>>> friendly than binary PKCS#12. >>>>>>>> >>>>>>>> But to enable sound support of PEM, I also implemented >>>> writing PEM >>>>>>>> keys and certificates. This way, one can use the JDK >>>> keytool to >>>>>>>> generate key and certificate signing requests in PEM >>>> format. Getting >>>>>>>> the certificate from the CA in PEM, one can use PEM >>>> throughout the >>>>>>>> process. >>>>>>>> >>>>>>>> Do you have any links or documentation on the PEM API >>>> JEP that you mentioned? >>>>>>>> >>>>>>>> Thank you for your feedback and best regards >>>>>>>> >>>>>>>> Karl >>>>>>>> >>>>>>>> Am Fr., 8. Sept. 2023 um 21:17 Uhr schrieb Anthony >>>>>>>> Scarpino >>>>>>> >>>> >>: >>>>>>>>> >>>>>>>>> Hi Karl >>>>>>>>> >>>>>>>>> The keystore is interesting and may have some value. >>>>>>>>> >>>> Was your use case >>>>>>>>> mostly reading PEM keys and certificates generated >>>> elsewhere for use >>>>>>>>> with a particular application, maybe webservers? >>>>>>>>> Did >>>> you see value in >>>>>>>>> writing to this keystore from Java? >>>>>>>>> >>>>>>>>> On the topic of PEM, I hope before the end of the >>>>>>>>> year >>>> to have a PEM API >>>>>>>>> JEP. I would be interested in your API feedback >>>>>>>>> from >>>> your keystore >>>>>>>>> experiences. I think if this keystore contribution >>>>>>>>> was >>>> accepted, it >>>>>>>>> should wait so it can use that API. >>>>>>>>> >>>>>>>>> thanks >>>>>>>>> >>>>>>>>> Tony >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/1/23 12:15 PM, Karl Scheibelhofer wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Working with Java and the JCA KeyStore for decades, >>>>>>>>>> I >>>> came across >>>>>>>>>> many situations where I thought it would be >>>>>>>>>> convenient >>>> to be >>>>>>>>>> able to load private keys and certificates in PEM >>>> format directly >>>>>>>>>> using the KeyStore API. Without the need to >>>>>>>>>> convert >>>> them to PKCS#12/JKS. >>>>>>>>>> >>>>>>>>>> You can find my implementation of a PEM KeyStore >>>>>>>>>> in >>>>>>>>>> >>>> https://urldefense.com/v3/__https://github.com/KarlScheibelhofer/java-crypto-tools__;!!ACWV5N9M2RV99hQ!Oty2x6ce8fseqwbwEZ1eFN9xJCtVxU8aUXn1GXt81SA1JkTeB9GSykdwShzJKOFYUAA1oUtLGaX1kmZV984WRsO-8KQq5dw$ >>>> >>>> >>> > >>>> . >>>>>>>>>> >>>>>>>>>> I wondered if it would make sense to integrate such >>>>>>>>>> an >>>> implementation >>>>>>>>>> in one of the standard providers of OpenJDK - like >>>>>>>>>> the >>>> SUN provider. >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> >>>>>>>>>> Karl >>>> >>> >> > From ascarpino at openjdk.org Wed Dec 6 02:38:57 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 02:38:57 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v3] In-Reply-To: References: Message-ID: > Hi, > > I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. > > The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. > > The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: Better aeadbuffer memory increments for CipherOutputStream Changed aeadbuffer usage away from byte[].length to aeadbuffer.size() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16487/files - new: https://git.openjdk.org/jdk/pull/16487/files/80bf02b4..f7388e7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=01-02 Stats: 102 lines in 3 files changed: 31 ins; 36 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/16487.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16487/head:pull/16487 PR: https://git.openjdk.org/jdk/pull/16487 From ascarpino at openjdk.org Wed Dec 6 02:45:34 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 02:45:34 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v3] In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 07:27:14 GMT, Daniel Jeli?ski wrote: >> As I understand the `ByteArrayOutputStream` code, the `ArraysSupport.newLength()` will double the allocation each time. So if the buffer is 1k size and it wants to add one more byte, the method will allocate 2k. >> I agree that in my change, if you send one byte at a time, it will be doing a lot of allocating. But I don't believe that is the general case. If you have examples of apps doing small allocations, let me know and I can come up with a different scheme. But at this point I thought it was a bitter risk more allocations in the less-likely situation, than unused allocation in what I see as a more common case. > > Well, as stated above, any application using CipherInputStream will do O(N) reallocations here, bringing back [JDK-8298249](https://bugs.openjdk.org/browse/JDK-8298249); you might want to check with the reporter if this actually affects any real applications. > > For reference, the results with this patch: > > Benchmark (dataSize) (keyLength) (provider) Mode Cnt Score Error Units > AESGCMCipherOutputStream.decrypt 16384 128 thrpt 40 30325.669 ? 1616.428 ops/s > AESGCMCipherOutputStream.decrypt 1048576 128 thrpt 40 7.034 ? 0.479 ops/s > > Baseline: > > Benchmark (dataSize) (keyLength) (provider) Mode Cnt Score Error Units > AESGCMCipherOutputStream.decrypt 16384 128 thrpt 40 52171.497 ? 6229.841 ops/s > AESGCMCipherOutputStream.decrypt 1048576 128 thrpt 40 470.844 ? 179.817 ops/s > > i.e. with the patch, decryption is 40% slower for 16KB stream, 98% (or 50x) slower for 1MB stream. Ok.. I updated the code to handle it more like it did. With one update(), the memory usage is still how I intended. So keeping the CipherOutputStream case, where it's multiple update() calls, it's a problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1416585796 From ascarpino at openjdk.org Wed Dec 6 02:52:36 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 02:52:36 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v3] In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 20:30:22 GMT, Anthony Scarpino wrote: >> test/micro/org/openjdk/bench/javax/crypto/full/BenchBase.java line 122: >> >>> 120: public void decrypt() throws Exception { >>> 121: decryptCipher.init(Cipher.DECRYPT_MODE, ks, >>> 122: encryptCipher.getParameters(). >> >> Consider using a different method to obtain parameter spec here; the flamegraph suggests that `getParameters` is responsible for up to 20% of the time spent in these benchmarks > > Thanks for point that out. I have decided to leave this as is. There are optimizations that can be made to `getParameters` that I would like the benchmark to measure. There was no optimization available for `getParameters` so I saved the parameters from the encryption op and it greatly improved the test performance ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1416590644 From ascarpino at openjdk.org Wed Dec 6 02:57:33 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 02:57:33 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v3] In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 02:43:06 GMT, Anthony Scarpino wrote: >> Well, as stated above, any application using CipherInputStream will do O(N) reallocations here, bringing back [JDK-8298249](https://bugs.openjdk.org/browse/JDK-8298249); you might want to check with the reporter if this actually affects any real applications. >> >> For reference, the results with this patch: >> >> Benchmark (dataSize) (keyLength) (provider) Mode Cnt Score Error Units >> AESGCMCipherOutputStream.decrypt 16384 128 thrpt 40 30325.669 ? 1616.428 ops/s >> AESGCMCipherOutputStream.decrypt 1048576 128 thrpt 40 7.034 ? 0.479 ops/s >> >> Baseline: >> >> Benchmark (dataSize) (keyLength) (provider) Mode Cnt Score Error Units >> AESGCMCipherOutputStream.decrypt 16384 128 thrpt 40 52171.497 ? 6229.841 ops/s >> AESGCMCipherOutputStream.decrypt 1048576 128 thrpt 40 470.844 ? 179.817 ops/s >> >> i.e. with the patch, decryption is 40% slower for 16KB stream, 98% (or 50x) slower for 1MB stream. > > Ok.. I updated the code to handle it more like it did. With one update(), the memory usage is still how I intended. So keeping the CipherOutputStream case, where it's multiple update() calls, it's a problem. After my change, that perf test showed a 30% for 16k and 15% for 1M perf increase ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1416593043 From ascarpino at openjdk.org Wed Dec 6 03:07:54 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 03:07:54 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v4] In-Reply-To: References: Message-ID: > Hi, > > I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. > > The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. > > The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16487/files - new: https://git.openjdk.org/jdk/pull/16487/files/f7388e7c..38928807 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16487.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16487/head:pull/16487 PR: https://git.openjdk.org/jdk/pull/16487 From ascarpino at openjdk.org Wed Dec 6 03:07:57 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 03:07:57 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v2] In-Reply-To: References: Message-ID: On Mon, 4 Dec 2023 07:08:57 GMT, Daniel Jeli?ski wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> comments update > > src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 80: > >> 78: return; >> 79: } >> 80: if (buf == null) { > > leftover from previous implementation; buf is never null. I redid a lot of this code in this update ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1416598378 From djelinski at openjdk.org Wed Dec 6 07:45:38 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Dec 2023 07:45:38 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v4] In-Reply-To: References: Message-ID: <-C27nUbaRzxyYmjkFSHvcN7S4eRUESjfpvH6TpaoemY=.ee3ea359-435c-48e5-ad5e-6e448ca5b818@github.com> On Wed, 6 Dec 2023 03:07:54 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. >> >> The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. >> >> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > update src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 60: > 58: * returning byte[] maybe larger. > 59: * > 60: * @return internal or new byte array of non-blocksize data. Please update the doc - the method always returns the internal array. I would create a new method to retrieve the internal buffer instead of overriding `toByteArray`; it would be less surprising to the future code editors. src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 76: > 74: // Create a new larger buffer and append the new data > 75: if (blen < count + len) { > 76: buf = Arrays.copyOf(buf, ArraysSupport.newLength(blen, blen + len, Suggestion: buf = Arrays.copyOf(buf, ArraysSupport.newLength(blen, count + len - blen, the second parameter is minGrowth; `count+len-blen` would be more appropriate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1416796431 PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1416785537 From ascarpino at openjdk.org Wed Dec 6 16:34:00 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 16:34:00 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v5] In-Reply-To: References: Message-ID: > Hi, > > I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. > > The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. > > The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16487/files - new: https://git.openjdk.org/jdk/pull/16487/files/38928807..b383888c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=03-04 Stats: 18 lines in 3 files changed: 0 ins; 3 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/16487.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16487/head:pull/16487 PR: https://git.openjdk.org/jdk/pull/16487 From ascarpino at openjdk.org Wed Dec 6 16:34:03 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 16:34:03 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v4] In-Reply-To: <-C27nUbaRzxyYmjkFSHvcN7S4eRUESjfpvH6TpaoemY=.ee3ea359-435c-48e5-ad5e-6e448ca5b818@github.com> References: <-C27nUbaRzxyYmjkFSHvcN7S4eRUESjfpvH6TpaoemY=.ee3ea359-435c-48e5-ad5e-6e448ca5b818@github.com> Message-ID: On Wed, 6 Dec 2023 07:24:08 GMT, Daniel Jeli?ski wrote: >> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 60: > >> 58: * returning byte[] maybe larger. >> 59: * >> 60: * @return internal or new byte array of non-blocksize data. > > Please update the doc - the method always returns the internal array. > > I would create a new method to retrieve the internal buffer instead of overriding `toByteArray`; it would be less surprising to the future code editors. ok > src/java.base/share/classes/com/sun/crypto/provider/AEADBufferedStream.java line 76: > >> 74: // Create a new larger buffer and append the new data >> 75: if (blen < count + len) { >> 76: buf = Arrays.copyOf(buf, ArraysSupport.newLength(blen, blen + len, > > Suggestion: > > buf = Arrays.copyOf(buf, ArraysSupport.newLength(blen, count + len - blen, > > the second parameter is minGrowth; `count+len-blen` would be more appropriate. Actually it should be `len`. That is the minGrowth as that is the size being added to the buffer, and `Math.max(len, blen)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1417619875 PR Review Comment: https://git.openjdk.org/jdk/pull/16487#discussion_r1417619918 From ascarpino at openjdk.org Wed Dec 6 16:48:57 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 16:48:57 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v6] In-Reply-To: References: Message-ID: <34QhidwHR1vaS4jDL47lZwlaL00FnowEMezQF4w7e6I=.9bae3cd0-ac83-4f66-a80f-6dc176e6bc77@github.com> > Hi, > > I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. > > The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. > > The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry > > thanks > > Tony Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16487/files - new: https://git.openjdk.org/jdk/pull/16487/files/b383888c..c1b28bf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16487&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16487.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16487/head:pull/16487 PR: https://git.openjdk.org/jdk/pull/16487 From djelinski at openjdk.org Wed Dec 6 16:52:41 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 6 Dec 2023 16:52:41 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v6] In-Reply-To: <34QhidwHR1vaS4jDL47lZwlaL00FnowEMezQF4w7e6I=.9bae3cd0-ac83-4f66-a80f-6dc176e6bc77@github.com> References: <34QhidwHR1vaS4jDL47lZwlaL00FnowEMezQF4w7e6I=.9bae3cd0-ac83-4f66-a80f-6dc176e6bc77@github.com> Message-ID: On Wed, 6 Dec 2023 16:48:57 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. >> >> The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. >> >> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > update LGTM. Thank you! ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16487#pullrequestreview-1768110166 From ascarpino at openjdk.org Wed Dec 6 18:11:53 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 6 Dec 2023 18:11:53 GMT Subject: Integrated: 8318756 Create better internal buffer for AEADs In-Reply-To: References: Message-ID: <6dHYRlB2JPdCaVhPhEejRi_p-nW3eDWi0hK0EJ3xxLE=.f13c9a9e-6967-484e-b5e8-1acf24762eac@github.com> On Fri, 3 Nov 2023 04:08:27 GMT, Anthony Scarpino wrote: > Hi, > > I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. > > The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. > > The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry > > thanks > > Tony This pull request has now been integrated. Changeset: dc9c77be Author: Anthony Scarpino URL: https://git.openjdk.org/jdk/commit/dc9c77bebe28570096345d3d22fd3ed10280acad Stats: 2915 lines in 15 files changed: 1789 ins; 1061 del; 65 mod 8318756: Create better internal buffer for AEADs Reviewed-by: djelinski ------------- PR: https://git.openjdk.org/jdk/pull/16487 From weijun at openjdk.org Wed Dec 6 19:35:50 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 6 Dec 2023 19:35:50 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly Message-ID: Add a fallback if an RSA signature was generated without the NULL params in its encoded hash. ------------- Commit messages: - chmod - the fix Changes: https://git.openjdk.org/jdk/pull/17002/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17002&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320597 Stats: 88 lines in 3 files changed: 65 ins; 13 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/17002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17002/head:pull/17002 PR: https://git.openjdk.org/jdk/pull/17002 From mullan at openjdk.org Thu Dec 7 14:26:31 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 7 Dec 2023 14:26:31 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly In-Reply-To: References: Message-ID: <5rd4TRBm2AiSvwq6-OcQ8HWPmcop7jK4pqbXrEWU4Ps=.5c0d7c98-f270-424c-9351-2b4370a09d45@github.com> On Wed, 6 Dec 2023 19:27:22 GMT, Weijun Wang wrote: > Add a fallback if an RSA signature was generated without the NULL params in its encoded hash. src/java.base/share/classes/sun/security/rsa/RSAUtil.java line 186: > 184: * This is only used by SunRsaSign. > 185: */ > 186: public static byte[] encodeSignatureWithoutNULL(ObjectIdentifier oid, byte[] digest) { Could make this method package-private. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17002#discussion_r1419041625 From weijun at openjdk.org Thu Dec 7 14:47:18 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 7 Dec 2023 14:47:18 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly [v2] In-Reply-To: References: Message-ID: <9QQwQvepWaRA3UNUtShjrXW_z57dQKLZKmp8TxsZ-lI=.4e4d8783-bfbd-4763-9837-810b0fbcab27@github.com> > Add a fallback if an RSA signature was generated without the NULL params in its encoded hash. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: change method to package private ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17002/files - new: https://git.openjdk.org/jdk/pull/17002/files/5ad4f69f..da9f909e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17002&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17002&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17002/head:pull/17002 PR: https://git.openjdk.org/jdk/pull/17002 From weijun at openjdk.org Thu Dec 7 14:47:21 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 7 Dec 2023 14:47:21 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly [v2] In-Reply-To: <5rd4TRBm2AiSvwq6-OcQ8HWPmcop7jK4pqbXrEWU4Ps=.5c0d7c98-f270-424c-9351-2b4370a09d45@github.com> References: <5rd4TRBm2AiSvwq6-OcQ8HWPmcop7jK4pqbXrEWU4Ps=.5c0d7c98-f270-424c-9351-2b4370a09d45@github.com> Message-ID: On Thu, 7 Dec 2023 14:22:00 GMT, Sean Mullan wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> change method to package private > > src/java.base/share/classes/sun/security/rsa/RSAUtil.java line 186: > >> 184: * This is only used by SunRsaSign. >> 185: */ >> 186: public static byte[] encodeSignatureWithoutNULL(ObjectIdentifier oid, byte[] digest) { > > Could make this method package-private. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17002#discussion_r1419073702 From valeriep at openjdk.org Thu Dec 7 19:13:40 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 7 Dec 2023 19:13:40 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly [v2] In-Reply-To: <9QQwQvepWaRA3UNUtShjrXW_z57dQKLZKmp8TxsZ-lI=.4e4d8783-bfbd-4763-9837-810b0fbcab27@github.com> References: <9QQwQvepWaRA3UNUtShjrXW_z57dQKLZKmp8TxsZ-lI=.4e4d8783-bfbd-4763-9837-810b0fbcab27@github.com> Message-ID: On Thu, 7 Dec 2023 14:47:18 GMT, Weijun Wang wrote: >> Add a fallback if an RSA signature was generated without the NULL params in its encoded hash. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > change method to package private test/jdk/sun/security/rsa/WithoutNULL.java line 27: > 25: * @test > 26: * @bug 8320597 > 27: * @summary RSA signature verification fails on signed data that does not encode params correctly The summary seems to contradict the check on line 52? Maybe: Verify RSA signature with omitted digest params (should be encoded as NULL) for backward compatibility? Rest looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17002#discussion_r1419490574 From fferrari at openjdk.org Thu Dec 7 19:46:45 2023 From: fferrari at openjdk.org (Francisco Ferrari Bihurriet) Date: Thu, 7 Dec 2023 19:46:45 GMT Subject: RFR: 8319332: Security properties files inclusion [v4] In-Reply-To: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com> References: <1TNdbyAaoBjjq97F2iwKG6L5UQP2iN6T-IjFPtWFCsE=.f8144c85-399c-4932-b4c7-2e8458cd5c25@github.com> Message-ID: > The implementation of this proposal is based on the requirements, specification and design choices described in the [JDK-8319332] ticket and its respective CSR [JDK-8319333]. What follows are implementation notes organized per functional component, with the purpose of assisting to navigate the code changes in this pull-request. > > ## Security properties loading (overview) > > A new static class named `SecPropLoader` (nested within `java.security.Security`) is introduced to handle the loading of all security properties. Its method `loadAll` is the first one to be called, at `java.security.Security` static class initialization. The master security properties file is then loaded by `loadMaster`. When additional security properties files are allowed (the security property `security.overridePropertiesFile` is set to `true`) and the `java.security.properties` system property is passed, the method `loadExtra` handles the extra load. > > The master properties file is loaded in `OVERRIDE` mode, meaning that the map of properties is originally empty. Any failure occurred while loading these properties is considered fatal. The extra properties file (`java.security.properties`) may be loaded in `OVERRIDE` or `APPEND` mode. Any failure in this case is ignored. This behavior maintains compatibility with the previous implementation. > > While the `java.security.properties` system property is documented to accept an URL type of value, filesystem path values are supported in the same way that they were prior to this enhancement. Values are then interpreted as paths and, only if that fails, are considered URLs. In the latter case, there is one more attempt after opening the stream to check if there is a local file path underneath (e.g. the URL has the form of `file:///path/to/a/local/file`). The reason for preferring paths over URLs is to support relative path file inclusion in properties files. > > ## Loading security properties from paths (`loadFromPath` method) > > When loading a properties file from a path, the normalized file location is stored in the static field `currentPath`. This value is the current base to resolve any relative path encountered while handling an _include_ definition. Normalized paths are also saved in the `activePaths` set to detect recursive cycles. As we move down or up in the _includes_ stack, `currentPath` and `activePaths` values are updated. > > ## Loading security properties from URLs (`loadFromUrl` method) > > The extra properties file can be loaded from a URL. ... Francisco Ferrari Bihurriet has updated the pull request incrementally with one additional commit since the last revision: 8319332: Fix corner-case regression with bash pipe Extra properties files provided through bash pipes used to work before this enhancement, restore their behaviour. Also take advantage to use Files::isRegularFile, Files::isDirectory and Files::exists APIs instead of converting from Path to File. Linux reproducers (sub-shell, stdin, and combination of both): java -XshowSettings:security:properties \ -Djava.security.properties==<(echo name=value) \ -Djava.security.debug=properties -version echo name=value | java -XshowSettings:security:properties \ -Djava.security.properties==/dev/stdin \ -Djava.security.debug=properties -version echo name=value | java -XshowSettings:security:properties \ -Djava.security.properties==<(echo include /dev/stdin) \ -Djava.security.debug=properties -version Co-authored-by: Martin Balao Co-authored-by: Francisco Ferrari Bihurriet ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16483/files - new: https://git.openjdk.org/jdk/pull/16483/files/faf7b7fd..90df17c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16483&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16483&range=02-03 Stats: 12 lines in 2 files changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/16483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16483/head:pull/16483 PR: https://git.openjdk.org/jdk/pull/16483 From weijun at openjdk.org Thu Dec 7 20:58:17 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 7 Dec 2023 20:58:17 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly [v2] In-Reply-To: References: <9QQwQvepWaRA3UNUtShjrXW_z57dQKLZKmp8TxsZ-lI=.4e4d8783-bfbd-4763-9837-810b0fbcab27@github.com> Message-ID: On Thu, 7 Dec 2023 19:11:23 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> change method to package private > > test/jdk/sun/security/rsa/WithoutNULL.java line 27: > >> 25: * @test >> 26: * @bug 8320597 >> 27: * @summary RSA signature verification fails on signed data that does not encode params correctly > > The summary seems to contradict the check on line 52? Maybe: Verify RSA signature with omitted digest params (should be encoded as NULL) for backward compatibility? > Rest looks good. Oh, this is the title of the bug which described what was wrong, and I often simply copy this as the summary of a bug. You mean here I should emphasis what is corrected and the updated behavior? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17002#discussion_r1419653540 From weijun at openjdk.org Thu Dec 7 21:08:00 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 7 Dec 2023 21:08:00 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly [v3] In-Reply-To: References: Message-ID: <-66-snBfz4BZQPe7g1q-B96tpHXtiOp0iIMNxBKqtQ0=.3e87d35a-a31f-4802-bfcf-862c2fd1496c@github.com> > Add a fallback if an RSA signature was generated without the NULL params in its encoded hash. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: rewrite test summary ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17002/files - new: https://git.openjdk.org/jdk/pull/17002/files/da9f909e..3ee6d1c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17002&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17002&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17002/head:pull/17002 PR: https://git.openjdk.org/jdk/pull/17002 From weijun at openjdk.org Thu Dec 7 21:08:01 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 7 Dec 2023 21:08:01 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly [v2] In-Reply-To: References: <9QQwQvepWaRA3UNUtShjrXW_z57dQKLZKmp8TxsZ-lI=.4e4d8783-bfbd-4763-9837-810b0fbcab27@github.com> Message-ID: On Thu, 7 Dec 2023 20:55:22 GMT, Weijun Wang wrote: >> test/jdk/sun/security/rsa/WithoutNULL.java line 27: >> >>> 25: * @test >>> 26: * @bug 8320597 >>> 27: * @summary RSA signature verification fails on signed data that does not encode params correctly >> >> The summary seems to contradict the check on line 52? Maybe: Verify RSA signature with omitted digest params (should be encoded as NULL) for backward compatibility? >> Rest looks good. > > Oh, this is the title of the bug which described what was wrong, and I often simply copy this as the summary of a bug. You mean here I should emphasis what is corrected and the updated behavior? You are right. According to the [jtreg FAQ](https://openjdk.org/jtreg/faq.html): > The @summary tag describes the condition that is checked by the test... Note that a test summary is generally not the same thing as a Bugtraq synopsis, since the latter describes the bug rather than the condition that the bug violates. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17002#discussion_r1419659148 From mullan at openjdk.org Thu Dec 7 21:22:16 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 7 Dec 2023 21:22:16 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly [v3] In-Reply-To: <-66-snBfz4BZQPe7g1q-B96tpHXtiOp0iIMNxBKqtQ0=.3e87d35a-a31f-4802-bfcf-862c2fd1496c@github.com> References: <-66-snBfz4BZQPe7g1q-B96tpHXtiOp0iIMNxBKqtQ0=.3e87d35a-a31f-4802-bfcf-862c2fd1496c@github.com> Message-ID: On Thu, 7 Dec 2023 21:08:00 GMT, Weijun Wang wrote: >> Add a fallback if an RSA signature was generated without the NULL params in its encoded hash. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > rewrite test summary Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17002#pullrequestreview-1771148786 From valeriep at openjdk.org Thu Dec 7 22:02:14 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 7 Dec 2023 22:02:14 GMT Subject: RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly [v3] In-Reply-To: <-66-snBfz4BZQPe7g1q-B96tpHXtiOp0iIMNxBKqtQ0=.3e87d35a-a31f-4802-bfcf-862c2fd1496c@github.com> References: <-66-snBfz4BZQPe7g1q-B96tpHXtiOp0iIMNxBKqtQ0=.3e87d35a-a31f-4802-bfcf-862c2fd1496c@github.com> Message-ID: On Thu, 7 Dec 2023 21:08:00 GMT, Weijun Wang wrote: >> Add a fallback if an RSA signature was generated without the NULL params in its encoded hash. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > rewrite test summary Changes look good. Thanks~ ------------- Marked as reviewed by valeriep (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17002#pullrequestreview-1771203726 From weijun at openjdk.org Thu Dec 7 23:29:29 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 7 Dec 2023 23:29:29 GMT Subject: Integrated: 8320597: RSA signature verification fails on signed data that does not encode params correctly In-Reply-To: References: Message-ID: On Wed, 6 Dec 2023 19:27:22 GMT, Weijun Wang wrote: > Add a fallback if an RSA signature was generated without the NULL params in its encoded hash. This pull request has now been integrated. Changeset: 11e4a925 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/11e4a925bec3c1f79e03045d48def53188b655e6 Stats: 89 lines in 3 files changed: 66 ins; 13 del; 10 mod 8320597: RSA signature verification fails on signed data that does not encode params correctly Reviewed-by: mullan, valeriep ------------- PR: https://git.openjdk.org/jdk/pull/17002 From weijun at openjdk.org Thu Dec 7 23:36:50 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 7 Dec 2023 23:36:50 GMT Subject: [jdk22] RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly Message-ID: 8320597: RSA signature verification fails on signed data that does not encode params correctly ------------- Commit messages: - Backport 11e4a925bec3c1f79e03045d48def53188b655e6 Changes: https://git.openjdk.org/jdk22/pull/1/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=1&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320597 Stats: 89 lines in 3 files changed: 66 ins; 13 del; 10 mod Patch: https://git.openjdk.org/jdk22/pull/1.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/1/head:pull/1 PR: https://git.openjdk.org/jdk22/pull/1 From valeriep at openjdk.org Fri Dec 8 00:25:37 2023 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 8 Dec 2023 00:25:37 GMT Subject: [jdk22] RFR: 8320597: RSA signature verification fails on signed data that does not encode params correctly In-Reply-To: References: Message-ID: On Thu, 7 Dec 2023 23:29:17 GMT, Weijun Wang wrote: > 8320597: RSA signature verification fails on signed data that does not encode params correctly Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk22/pull/1#pullrequestreview-1771330385 From weijun at openjdk.org Fri Dec 8 03:04:38 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 8 Dec 2023 03:04:38 GMT Subject: [jdk22] Integrated: 8320597: RSA signature verification fails on signed data that does not encode params correctly In-Reply-To: References: Message-ID: On Thu, 7 Dec 2023 23:29:17 GMT, Weijun Wang wrote: > 8320597: RSA signature verification fails on signed data that does not encode params correctly This pull request has now been integrated. Changeset: 7de0fb36 Author: Weijun Wang URL: https://git.openjdk.org/jdk22/commit/7de0fb36132fa2faee17c547bf02dca9c048c82d Stats: 89 lines in 3 files changed: 66 ins; 13 del; 10 mod 8320597: RSA signature verification fails on signed data that does not encode params correctly Reviewed-by: valeriep Backport-of: 11e4a925bec3c1f79e03045d48def53188b655e6 ------------- PR: https://git.openjdk.org/jdk22/pull/1 From duke at openjdk.org Fri Dec 8 19:07:27 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 8 Dec 2023 19:07:27 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v7] In-Reply-To: References: Message-ID: > Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: > - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: added format check to X509CertSelectorTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16834/files - new: https://git.openjdk.org/jdk/pull/16834/files/bd2a3403..2b6b2c9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=05-06 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16834/head:pull/16834 PR: https://git.openjdk.org/jdk/pull/16834 From weijun at openjdk.org Fri Dec 8 19:18:29 2023 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 8 Dec 2023 19:18:29 GMT Subject: RFR: 8187634: keystore.getCertificateAlias(cert) returns original alias, inconsistent with fix of JDK-6483657 Message-ID: The alias in the keystore is `mapEntry.getKey()`. `entry.getAlias()` is the original friendly name, which is still useful when overwriting or removing an entry. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/17037/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17037&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8187634 Stats: 99 lines in 2 files changed: 97 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17037.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17037/head:pull/17037 PR: https://git.openjdk.org/jdk/pull/17037 From mullan at openjdk.org Fri Dec 8 20:14:17 2023 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 8 Dec 2023 20:14:17 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v7] In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 19:07:27 GMT, Ben Perez wrote: >> Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: >> - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` >> - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` >> - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > added format check to X509CertSelectorTest One comment on the test, but looks good otherwise. src/java.base/share/classes/sun/security/util/Debug.java line 336: > 334: } > 335: > 336: public static String toString(BigInteger b) { It would be nice if the `toString` method had `Hex` in the name to make it more obvious this is returning hex format, but then it would conflict with the existing `toHexString(BigInteger)` method, so it's probably fine to leave as-is for now. test/jdk/java/security/cert/X509CertSelectorTest.java line 197: > 195: > 196: // check serial number format > 197: String serialNum = Debug.toString(selector.getSerialNumber()); You should add 8296787 to the @bug line as this test is now also testing the fix for this issue. ------------- Marked as reviewed by mullan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16834#pullrequestreview-1773107424 PR Review Comment: https://git.openjdk.org/jdk/pull/16834#discussion_r1420984128 PR Review Comment: https://git.openjdk.org/jdk/pull/16834#discussion_r1420986535 From duke at openjdk.org Fri Dec 8 21:36:30 2023 From: duke at openjdk.org (Eirik Bjorsnos) Date: Fri, 8 Dec 2023 21:36:30 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs In-Reply-To: References: Message-ID: On Thu, 23 Nov 2023 01:04:15 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. >> >> The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. >> >> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry >> >> thanks >> >> Tony > > Noteworthy perf data (ops/sec) > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:////Users/ascarpin/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip.htm"> > href="file:////Users/ascarpin/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip_filelist.xml"> > > > > > > > > > Benchmark | dataMethod | dataSize | AEADBuffer | jdk-dev | ?Diff > -- | -- | -- | -- | -- | -- > CC20P1305ByteBuffer.decrypt | direct | 1024 | 577804.81 | 549630.383 | 105.13% > CC20P1305ByteBuffer.decrypt | direct | 1500 | 424441.663 | 401452.037 | 105.73% > CC20P1305ByteBuffer.decrypt | direct | 4096 | 186333.196 | 152909.993 | 121.86% > CC20P1305ByteBuffer.decrypt | direct | 16384 | 49698.562 | 41966.387 | 118.42% > CC20P1305ByteBuffer.decrypt | heap | 1024 | 586145.31 | 514277.384 | 113.97% > CC20P1305ByteBuffer.decrypt | heap | 1500 | 429055.718 | 380859.773 | 112.65% > CC20P1305ByteBuffer.decrypt | heap | 4096 | 179807.069 | 179241.327 | 100.32% > CC20P1305ByteBuffer.decrypt | heap | 16384 | 51096.478 | 51097.68 | 100.00% > CC20P1305ByteBuffer.decryptMultiPart | direct | 1024 | 553804.884 | 506750.657 | 109.29% > CC20P1305ByteBuffer.decryptMultiPart | direct | 1500 | 399307.809 | 365691.011 | 109.19% > CC20P1305ByteBuffer.decryptMultiPart | direct | 4096 | 180940.646 | 165152.892 | 109.56% > CC20P1305ByteBuffer.decryptMultiPart | direct | 16384 | 49117.754 | 40808.57 | 120.36% > CC20P1305ByteBuffer.decryptMultiPart | heap | 1024 | 567976.828 | 539087.765 | 105.36% > CC20P1305ByteBuffer.decryptMultiPart | heap | 1500 | 415070.529 | 400061.343 | 103.75% > CC20P1305ByteBuffer.decryptMultiPart | heap | 4096 | 180878.684 | 178758.204 | 101.19% > CC20P1305ByteBuffer.decryptMultiPart | heap | 16384 | 48541.737 | 46645.72 | 104.06% > AESGCMByteBuffer.decrypt | heap | 1024 | 1826361.53 | 1796033.97 | 101.69% > AESGCMByteBuffer.decrypt | heap | 1500 | 1245406.42 | 1109318.44 | 112.27% > AESGCMByteBuffer.decrypt | heap | 4096 | 641359.437 | 617315.646 | 103.89% > AESGCMByteBuffer.decrypt | heap | 16384 | 247719.061 | 238448.044 | 103.89% > AESGCMByteBuffer.decryptMultiPart | direct | 1024 | 1574668.85 | 1483599.15 | 106.14% > AESGCMByteBuffer.decryptMultiPart | d... @ascarpino I'm seeing GHA test failures on `linux-x86` for `AEADBufferTest.java` after the integration of this change [1] build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/com/sun/crypto/provider/Cipher/AEAD/AEADBufferTest/hs_err_pid4225.log: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00000000, pid=4225, tid=10054 # # JRE version: OpenJDK Runtime Environment (23.0) (build 23-internal-eirbjo-f6a00f0cfe870a555c559063d7eab53366fa6d70) # Java VM: OpenJDK Server VM (23-internal-eirbjo-f6a00f0cfe870a555c559063d7eab53366fa6d70, mixed mode, tiered, g1 gc, linux-x86) # Problematic frame: # J 6617 c2 com.sun.crypto.provider.ChaCha20Cipher.chaCha20Transform([BII[BI)V java.base at 23-internal (193 bytes) @ 0xef6677bd [0xef667440+0x0000037d] # # CreateCoredumpOnCrash turned off, no core file dumped # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -Xmx768m -XX:MaxRAMPercentage=12.5 -Dtest.boot.jdk=/home/runner/work/jdk/jdk/bootjdk/jdk -Djava.io.tmpdir=/home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/tmp -ea -esa -XX:-CreateCoredumpOnCrash -Djava.library.path=/home/runner/work/jdk/jdk/bundles/tests/jdk/jtreg/native --patch-module=java.base=/home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/patches/java.base -Djava.security.policy=file:/home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/jtreg.policy com.sun.javatest.regtest.agent.AgentServer -id 7 -logfile /home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/jtData/agentServer.7.trace -allowSetSecurityManager -port 35137 -timeoutFactor 4.0 Host: AMD EPYC 7763 64-Core Processor, 4 cores, 15G, Ubuntu 22.04.3 LTS Time: Fri Dec 8 21:03:25 2023 UTC elapsed time: 82.102203 seconds (0d 0h 1m 22s) --------------- T H R E A D --------------- Current thread (0xb3ff0ea0): JavaThread "AgentVMThread" [_thread_in_Java, id=10054, stack(0xb50b0000,0xb5100000) (320K)] Stack: [0xb50b0000,0xb5100000], sp=0xb50fe910, free space=314k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 6617 c2 com.sun.crypto.provider.ChaCha20Cipher.chaCha20Transform([BII[BI)V java.base at 23-internal (193 bytes) @ 0xef6677bd [0xef667440+0x0000037d] J 6559 c1 com.sun.crypto.provider.ChaCha20Cipher$EngineAEADEnc.doUpdate([BII[BI)I java.base at 23-internal (148 bytes) @ 0xe82a5d64 [0xe82a5a40+0x00000324] J 6598 c1 com.sun.crypto.provider.ChaCha20Cipher$EngineAEADEnc.doFinal([BII[BI)I java.base at 23-internal (64 bytes) @ 0xe82b55c0 [0xe82b54e0+0x000000e0] J 6601 c1 com.sun.crypto.provider.ChaCha20Cipher.engineDoFinal([BII[BI)I java.base at 23-internal (52 bytes) @ 0xe82b6a98 [0xe82b6980+0x00000118] J 6252 c1 javax.crypto.Cipher.doFinal([BII[BI)I java.base at 23-internal (59 bytes) @ 0xe8208878 [0xe8208600+0x00000278] J 6218 c1 AEADBufferTest.crypto(ZLAEADBufferTest$Data;[B[B)V (1208 bytes) @ 0xe81eee40 [0xe81ebac0+0x00003380] J 6277 c1 AEADBufferTest.encrypt(LAEADBufferTest$Data;)V (119 bytes) @ 0xe821a01c [0xe8218be0+0x0000143c] j AEADBufferTest.test()V+181 j AEADBufferTest.main([Ljava/lang/String;)V+1458 j java.lang.invoke.LambdaForm$DMH+0xb4402a58.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V+10 java.base at 23-internal j java.lang.invoke.LambdaForm$MH+0xb0672280.invoke(Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;+33 java.base at 23-internal J 4739 c2 jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base at 23-internal (92 bytes) @ 0xef4d8dbc [0xef4d8ae0+0x000002dc] J 2103 c1 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base at 23-internal (108 bytes) @ 0xe796bb34 [0xe796b740+0x000003f4] j com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run()V+10 j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base at 23-internal j java.lang.Thread.run()V+19 java.base at 23-internal v ~StubRoutines::call_stub 0xeebe1c7c V [libjvm.so+0x6e58d2] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x232 (javaCalls.cpp:415) V [libjvm.so+0x6e64e5] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x195 (javaCalls.cpp:329) V [libjvm.so+0x7c5e7b] thread_entry(JavaThread*, JavaThread*)+0x8b (jvm.cpp:2937) V [libjvm.so+0x6ff668] JavaThread::thread_main_inner() [clone .part.0]+0xb8 (javaThread.cpp:720) V [libjvm.so+0xc487e3] Thread::call_run()+0xa3 (thread.cpp:220) V [libjvm.so+0xa34859] thread_native_entry(Thread*)+0xf9 (os_linux.cpp:789) C [libc.so.6+0x86071] [1] https://github.com/eirbjo/jdk/actions/runs/7145974602#user-content-com_sun_crypto_provider_cipher_aead_aeadbuffertest ------------- PR Comment: https://git.openjdk.org/jdk/pull/16487#issuecomment-1847867767 From ascarpino at openjdk.org Sat Dec 9 01:57:27 2023 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Sat, 9 Dec 2023 01:57:27 GMT Subject: RFR: 8318756 Create better internal buffer for AEADs [v6] In-Reply-To: <34QhidwHR1vaS4jDL47lZwlaL00FnowEMezQF4w7e6I=.9bae3cd0-ac83-4f66-a80f-6dc176e6bc77@github.com> References: <34QhidwHR1vaS4jDL47lZwlaL00FnowEMezQF4w7e6I=.9bae3cd0-ac83-4f66-a80f-6dc176e6bc77@github.com> Message-ID: On Wed, 6 Dec 2023 16:48:57 GMT, Anthony Scarpino wrote: >> Hi, >> >> I need a review for a new internal buffer class called AEADBufferStream. AEADBufferStream extends ByteArrayOutputStream, but eliminates some data checking and copying that are not necessary for what GaloisCounterMode.java and ChaCha20Cipher.java need. >> >> The changes greatest benefit is with decryption operations. ChaCha20-Poly1305 had larger performance gains by adopting similar techniques that AES/GCM already uses. >> >> The new buffer shows up to 21% bytes/sec performance increase for decryption for ChaCha20-Poly1305 and 12% for AES/GCM. 16K data sizes saw a memory usage reduction of 46% with and 83% with ChaCha20-Poly1305. These results come from the JMH tests updated in this request and memory usage using the JMH gc profile gc.alloc.rate.norm entry >> >> thanks >> >> Tony > > Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision: > > update This change did not introduce the problem. The test just exposed the problem that has existed since https://bugs.openjdk.org/browse/JDK-8247645 was integrated in JDK 20. A bug was filed: https://bugs.openjdk.org/browse/JDK-8321542 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16487#issuecomment-1848083450 From stefank at openjdk.org Mon Dec 11 09:21:21 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 11 Dec 2023 09:21:21 GMT Subject: RFR: 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder Message-ID: [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes. We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't. With these functions it is common to see the following pattern in tests: ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...); OutputAnalyzer output = executeProcess(pb); We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner: OutputAnalyzer output = ProcessTools.executeTestJvm(); I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function. ------------- Commit messages: - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder Changes: https://git.openjdk.org/jdk/pull/17049/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321713 Stats: 217 lines in 88 files changed: 28 ins; 1 del; 188 mod Patch: https://git.openjdk.org/jdk/pull/17049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049 PR: https://git.openjdk.org/jdk/pull/17049 From jwaters at openjdk.org Mon Dec 11 12:59:15 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 11 Dec 2023 12:59:15 GMT Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi [v4] In-Reply-To: References: Message-ID: On Tue, 5 Dec 2023 15:07:15 GMT, Weijun Wang wrote: > I still don't like this solution: > > 1. Duplicated lines. > 2. There are other `goto`s in this file. I know they happen to be unaffected, but if `goto` is not recommended in C++ it looks unfair to remove some and keep some. > > Can we throw and catch exceptions? Or, how difficult is it to rewrite to simply C? Just substitute `new` and `delete` with `malloc` and `free`? I'm afraid the same is also strictly an error in C as well, though the compiler sometimes doesn't error on these constructs (non-conforming behaviour). I can see how the solution leaves a lot to be desired, I wonder if I could move the gotos to a common place where they don't intersect local definitions instead? As for exceptions, I don't know if it can be done, since the existing code seems to suggest that they are not desired ------------- PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1850028813 From stefank at openjdk.org Mon Dec 11 14:03:36 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 11 Dec 2023 14:03:36 GMT Subject: RFR: 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder [v2] In-Reply-To: References: Message-ID: > [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes. > > We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't. > > With these functions it is common to see the following pattern in tests: > > ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...); > OutputAnalyzer output = executeProcess(pb); > > > We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner: > > OutputAnalyzer output = ProcessTools.executeTestJvm(); > > > I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Fix impl and add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17049/files - new: https://git.openjdk.org/jdk/pull/17049/files/080caef5..ad072e06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=00-01 Stats: 54 lines in 2 files changed: 52 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049 PR: https://git.openjdk.org/jdk/pull/17049 From stefank at openjdk.org Mon Dec 11 14:06:43 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 11 Dec 2023 14:06:43 GMT Subject: RFR: 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: > [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes. > > We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't. > > With these functions it is common to see the following pattern in tests: > > ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...); > OutputAnalyzer output = executeProcess(pb); > > > We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner: > > OutputAnalyzer output = ProcessTools.executeTestJvm(); > > > I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Test cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17049/files - new: https://git.openjdk.org/jdk/pull/17049/files/ad072e06..5d488f42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17049&range=01-02 Stats: 10 lines in 1 file changed: 1 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17049.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049 PR: https://git.openjdk.org/jdk/pull/17049 From lkorinth at openjdk.org Mon Dec 11 14:23:19 2023 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 11 Dec 2023 14:23:19 GMT Subject: RFR: 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson wrote: >> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes. >> >> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't. >> >> With these functions it is common to see the following pattern in tests: >> >> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...); >> OutputAnalyzer output = executeProcess(pb); >> >> >> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner: >> >> OutputAnalyzer output = ProcessTools.executeTestJvm(); >> >> >> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Test cleanup Looks good to me. ------------- Marked as reviewed by lkorinth (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17049#pullrequestreview-1775250269 From weijun at openjdk.org Mon Dec 11 15:31:18 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 11 Dec 2023 15:31:18 GMT Subject: RFR: 8320219: Actually resolve issues with goto labels in sspi [v4] In-Reply-To: References: Message-ID: <1d3bNLwlfZY9gAlSZgKsbrwZYomBWrwJBkxvdNUbrJw=.198d43c2-a00a-447c-9e82-e89bcf9c22f9@github.com> On Mon, 4 Dec 2023 09:26:57 GMT, Julian Waters wrote: >> I regret not actually addressing the issues with the goto labels in https://github.com/openjdk/jdk/pull/15996, where initialization of locals in sspi were jumped over by gotos to a certain label. I changed the initializations into split declarations and assignments in https://github.com/openjdk/jdk/pull/15996, but this is simply a hack and does not address the real issue of gotos jumping over locals. I've as such fixed the issues with them properly this time, by simply deleting the labels and duplicating the code where they're used. As mentioned, this unfortunately does increase duplicate code, but is the cleanest solution I could come up with for the labels > > Julian Waters 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: > > - Merge branch 'openjdk:master' into patch-9 > - NULL to nullptr in sspi.cpp > - Missed labels in sspi.cpp > - Actually resolve issues with goto labels in sspi Maybe put the definition lines at the beginning of a function and initialize them to NULLs? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16682#issuecomment-1850309723 From coffeys at openjdk.org Mon Dec 11 15:49:17 2023 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 11 Dec 2023 15:49:17 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v7] In-Reply-To: References: Message-ID: <-l_DhwfN4gOEgKHO4c4mGDx7guYDpvq3Kb6HTd773D4=.8c233edd-ad7b-4026-9a2b-28b1002e4708@github.com> On Fri, 8 Dec 2023 19:07:27 GMT, Ben Perez wrote: >> Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: >> - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` >> - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` >> - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > > Ben Perez has updated the pull request incrementally with one additional commit since the last revision: > > added format check to X509CertSelectorTest Looks good to me. Please ensure you run a wide selection of tests before integration. It should include JFR testing to exercise the X509 JFR event testing we have there. ------------- Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16834#pullrequestreview-1775475863 From weijun at openjdk.org Mon Dec 11 16:20:31 2023 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 11 Dec 2023 16:20:31 GMT Subject: RFR: 8202598: [linux] keytool -certreq inconsistent with platform line.separator Message-ID: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> Always use CRLF in PEM output. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/17060/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17060&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8202598 Stats: 109 lines in 3 files changed: 97 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/17060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17060/head:pull/17060 PR: https://git.openjdk.org/jdk/pull/17060 From duke at openjdk.org Mon Dec 11 17:08:29 2023 From: duke at openjdk.org (Ben Perez) Date: Mon, 11 Dec 2023 17:08:29 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v8] In-Reply-To: References: Message-ID: > Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: > - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: added bug number to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16834/files - new: https://git.openjdk.org/jdk/pull/16834/files/2b6b2c9f..e6951349 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16834/head:pull/16834 PR: https://git.openjdk.org/jdk/pull/16834 From duke at openjdk.org Tue Dec 12 00:11:01 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 12 Dec 2023 00:11:01 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v9] In-Reply-To: References: Message-ID: > Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: > - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: updated test certs to use new serial number format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16834/files - new: https://git.openjdk.org/jdk/pull/16834/files/e6951349..1b8de7f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=07-08 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/16834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16834/head:pull/16834 PR: https://git.openjdk.org/jdk/pull/16834 From chagedorn at openjdk.org Tue Dec 12 08:58:24 2023 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 12 Dec 2023 08:58:24 GMT Subject: RFR: 8321542: C2: Missing ChaCha20 stub for x86_32 leads to crashes In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 01:02:59 GMT, Jamil Nimeh wrote: > This fix corrects an oversight in the ChaCha20 intrinsics delivered by JDK-8247645. An ifdef guard is now part of the x86 ChaCha20 intrinsics code which disables them by default on 32-bit platforms, as this architecture was not part of the feature delivery. Marked as reviewed by chagedorn (Reviewer). src/hotspot/cpu/x86/vm_version_x86.cpp line 1152: > 1150: // No support currently for ChaCha20 intrinsics on 32-bit platforms > 1151: if (UseChaCha20Intrinsics) { > 1152: warning("Support for ChaCha20 intrinsics not available on this CPU."); Maybe we can adapt the message to follow the convention of the other warning messages for intrinsics like AES https://github.com/openjdk/jdk/blob/2611a49ea13ee7a07f22692c3a4b32856ec5898f/src/hotspot/cpu/x86/vm_version_x86.cpp#L1062-L1065 or CRC32C https://github.com/openjdk/jdk/blob/2611a49ea13ee7a07f22692c3a4b32856ec5898f/src/hotspot/cpu/x86/vm_version_x86.cpp#L1116-L1118 Suggestion: warning("ChaCha20 intrinsics are not available on this CPU."); Though I see that not all existing warning messages are consistent. Anyway, the bailout looks good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/17072#pullrequestreview-1776952817 PR Review Comment: https://git.openjdk.org/jdk/pull/17072#discussion_r1423662348 From shade at openjdk.org Tue Dec 12 09:28:34 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 12 Dec 2023 09:28:34 GMT Subject: RFR: 8321542: C2: Missing ChaCha20 stub for x86_32 leads to crashes In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 01:02:59 GMT, Jamil Nimeh wrote: > This fix corrects an oversight in the ChaCha20 intrinsics delivered by JDK-8247645. An ifdef guard is now part of the x86 ChaCha20 intrinsics code which disables them by default on 32-bit platforms, as this architecture was not part of the feature delivery. Agreed with message suggestion, otherwise good. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17072#pullrequestreview-1777014512 From shade at openjdk.org Tue Dec 12 09:28:35 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 12 Dec 2023 09:28:35 GMT Subject: RFR: 8321542: C2: Missing ChaCha20 stub for x86_32 leads to crashes In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 08:53:35 GMT, Christian Hagedorn wrote: >> This fix corrects an oversight in the ChaCha20 intrinsics delivered by JDK-8247645. An ifdef guard is now part of the x86 ChaCha20 intrinsics code which disables them by default on 32-bit platforms, as this architecture was not part of the feature delivery. > > src/hotspot/cpu/x86/vm_version_x86.cpp line 1152: > >> 1150: // No support currently for ChaCha20 intrinsics on 32-bit platforms >> 1151: if (UseChaCha20Intrinsics) { >> 1152: warning("Support for ChaCha20 intrinsics not available on this CPU."); > > Maybe we can adapt the message to follow the convention of the other warning messages for intrinsics like AES > https://github.com/openjdk/jdk/blob/2611a49ea13ee7a07f22692c3a4b32856ec5898f/src/hotspot/cpu/x86/vm_version_x86.cpp#L1062-L1065 > or CRC32C > https://github.com/openjdk/jdk/blob/2611a49ea13ee7a07f22692c3a4b32856ec5898f/src/hotspot/cpu/x86/vm_version_x86.cpp#L1116-L1118 > > Suggestion: > > warning("ChaCha20 intrinsics are not available on this CPU."); > > > Though I see that not all existing warning messages are consistent. > > Anyway, the bailout looks good to me. +1 on changing the message to "ChaCha20 intrinsics are not available on this CPU." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17072#discussion_r1423706642 From hannesw at openjdk.org Tue Dec 12 09:53:40 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Dec 2023 09:53:40 GMT Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested) type Message-ID: Please review a change to fix JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc (with the correct link being created). With [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors. ------------- Commit messages: - JDK-8321889: JavaDoc method references with wrong (nested) type Changes: https://git.openjdk.org/jdk/pull/17078/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321889 Stats: 6 lines in 3 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17078.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17078/head:pull/17078 PR: https://git.openjdk.org/jdk/pull/17078 From hannesw at openjdk.org Tue Dec 12 10:42:32 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Dec 2023 10:42:32 GMT Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested) type [v2] In-Reply-To: References: Message-ID: > Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors. > > I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references). Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Restore explicit label and remove duplicate word ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17078/files - new: https://git.openjdk.org/jdk/pull/17078/files/53e9cfa0..c7a76b17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17078&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17078.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17078/head:pull/17078 PR: https://git.openjdk.org/jdk/pull/17078 From alanb at openjdk.org Tue Dec 12 11:07:22 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 12 Dec 2023 11:07:22 GMT Subject: RFR: JDK-8321889: JavaDoc method references with wrong (nested) type [v2] In-Reply-To: References: Message-ID: <4dIjqukV52060edEa6j0AiOv5psHgpEFYXOzYqLKNf4=.cede50ce-09da-484e-9b5d-fc185631e419@github.com> On Tue, 12 Dec 2023 10:42:32 GMT, Hannes Walln?fer wrote: >> Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors. >> >> I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references). >> >> Update: I also fixed two typos in `javax/smartcardio/CardTerminals.java` by removing the duplicate "call" in "... latest call to waitForChange() call". > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Restore explicit label and remove duplicate word Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17078#pullrequestreview-1777214660 From hannesw at openjdk.org Tue Dec 12 11:30:32 2023 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 12 Dec 2023 11:30:32 GMT Subject: Integrated: JDK-8321889: JavaDoc method references with wrong (nested) type In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 09:46:29 GMT, Hannes Walln?fer wrote: > Please review a doc-only change for JavaDoc references using a nested class instead of the enclosing class containing the target method. Until now this is accepted by JavaDoc, but with [JDK-8164094](https://bugs.openjdk.org/browse/JDK-8164094) these references are reported as errors. > > I made sure the rendered documentation is identical before and after the change (JavaDoc previously generated the correct links for these references). > > Update: I also fixed two typos in `javax/smartcardio/CardTerminals.java` by removing the duplicate "call" in "... latest call to waitForChange() call". This pull request has now been integrated. Changeset: c5168526 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/c51685267c7bd5a7cee27ebc2bf0d9899cda9d4c Stats: 7 lines in 3 files changed: 0 ins; 2 del; 5 mod 8321889: JavaDoc method references with wrong (nested) type Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17078 From jnimeh at openjdk.org Tue Dec 12 14:24:34 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 12 Dec 2023 14:24:34 GMT Subject: RFR: 8321542: C2: Missing ChaCha20 stub for x86_32 leads to crashes In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 09:24:48 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/x86/vm_version_x86.cpp line 1152: >> >>> 1150: // No support currently for ChaCha20 intrinsics on 32-bit platforms >>> 1151: if (UseChaCha20Intrinsics) { >>> 1152: warning("Support for ChaCha20 intrinsics not available on this CPU."); >> >> Maybe we can adapt the message to follow the convention of the other warning messages for intrinsics like AES >> https://github.com/openjdk/jdk/blob/2611a49ea13ee7a07f22692c3a4b32856ec5898f/src/hotspot/cpu/x86/vm_version_x86.cpp#L1062-L1065 >> or CRC32C >> https://github.com/openjdk/jdk/blob/2611a49ea13ee7a07f22692c3a4b32856ec5898f/src/hotspot/cpu/x86/vm_version_x86.cpp#L1116-L1118 >> >> Suggestion: >> >> warning("ChaCha20 intrinsics are not available on this CPU."); >> >> >> Though I see that not all existing warning messages are consistent. >> >> Anyway, the bailout looks good to me. > > +1 on changing the message to "ChaCha20 intrinsics are not available on this CPU." Makes sense to me. Will fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17072#discussion_r1424063190 From jnimeh at openjdk.org Tue Dec 12 14:41:07 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 12 Dec 2023 14:41:07 GMT Subject: RFR: 8321542: C2: Missing ChaCha20 stub for x86_32 leads to crashes [v2] In-Reply-To: References: Message-ID: > This fix corrects an oversight in the ChaCha20 intrinsics delivered by JDK-8247645. An ifdef guard is now part of the x86 ChaCha20 intrinsics code which disables them by default on 32-bit platforms, as this architecture was not part of the feature delivery. Jamil Nimeh has updated the pull request incrementally with one additional commit since the last revision: Modify warning message on 32-bit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17072/files - new: https://git.openjdk.org/jdk/pull/17072/files/fe0d4461..ff55249e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17072&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17072&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17072.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17072/head:pull/17072 PR: https://git.openjdk.org/jdk/pull/17072 From jnimeh at openjdk.org Tue Dec 12 14:41:09 2023 From: jnimeh at openjdk.org (Jamil Nimeh) Date: Tue, 12 Dec 2023 14:41:09 GMT Subject: Integrated: 8321542: C2: Missing ChaCha20 stub for x86_32 leads to crashes In-Reply-To: References: Message-ID: On Tue, 12 Dec 2023 01:02:59 GMT, Jamil Nimeh wrote: > This fix corrects an oversight in the ChaCha20 intrinsics delivered by JDK-8247645. An ifdef guard is now part of the x86 ChaCha20 intrinsics code which disables them by default on 32-bit platforms, as this architecture was not part of the feature delivery. This pull request has now been integrated. Changeset: 5718039a Author: Jamil Nimeh URL: https://git.openjdk.org/jdk/commit/5718039a46ae51fa9b7042fe7163e3637e981b05 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod 8321542: C2: Missing ChaCha20 stub for x86_32 leads to crashes Reviewed-by: chagedorn, shade ------------- PR: https://git.openjdk.org/jdk/pull/17072 From duke at openjdk.org Tue Dec 12 17:18:13 2023 From: duke at openjdk.org (Ben Perez) Date: Tue, 12 Dec 2023 17:18:13 GMT Subject: RFR: 8296787: Unify debug printing format of X.509 cert serial numbers [v10] In-Reply-To: References: Message-ID: <8DNjPU6nMxCb5LyrWptysxtA4KxQ0TkCEwbBbfbi4yY=.17c46144-aac1-45b2-b80f-1887a56f5422@github.com> > Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: > - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` Ben Perez has updated the pull request incrementally with one additional commit since the last revision: updated copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16834/files - new: https://git.openjdk.org/jdk/pull/16834/files/1b8de7f4..88e34e3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16834&range=08-09 Stats: 12 lines in 12 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/16834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16834/head:pull/16834 PR: https://git.openjdk.org/jdk/pull/16834 From hchao at openjdk.org Tue Dec 12 22:35:31 2023 From: hchao at openjdk.org (Hai-May Chao) Date: Tue, 12 Dec 2023 22:35:31 GMT Subject: RFR: 8202598: [linux] keytool -certreq inconsistent with platform line.separator In-Reply-To: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> References: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> Message-ID: On Mon, 11 Dec 2023 16:14:24 GMT, Weijun Wang wrote: > Always use CRLF in PEM output. Marked as reviewed by hchao (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17060#pullrequestreview-1778545710 From lmesnik at openjdk.org Tue Dec 12 22:55:22 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 12 Dec 2023 22:55:22 GMT Subject: RFR: 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder [v3] In-Reply-To: References: Message-ID: On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson wrote: >> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes. >> >> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't. >> >> With these functions it is common to see the following pattern in tests: >> >> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...); >> OutputAnalyzer output = executeProcess(pb); >> >> >> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner: >> >> OutputAnalyzer output = ProcessTools.executeTestJvm(); >> >> >> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Test cleanup Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17049#pullrequestreview-1778566038 From mullan at openjdk.org Wed Dec 13 14:28:38 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 13 Dec 2023 14:28:38 GMT Subject: RFR: 8202598: [linux] keytool -certreq inconsistent with platform line.separator In-Reply-To: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> References: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> Message-ID: On Mon, 11 Dec 2023 16:14:24 GMT, Weijun Wang wrote: > Always use CRLF in PEM output. Can you change the bug summary with a better description of the issue - the bug makes it sound like CRLF is the cause of the interop issues. The summary and OS also say "linux" but this is not linux-specific AFAICT. Also you should assign it to yourself now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17060#issuecomment-1854015367 From dholmes at openjdk.org Thu Dec 14 05:51:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 05:51:45 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 Message-ID: Updated the version to 23-ea and year to 2024. This initial generation also picks up the unpublished changes from: - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) In addition this includes the updates for - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23 Thanks ------------- Commit messages: - 8322065: Initial nroff manpage generation for JDK 23 - 8309981: Remove expired flags in JDK 23 Changes: https://git.openjdk.org/jdk/pull/17101/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322065 Stats: 216 lines in 29 files changed: 47 ins; 61 del; 108 mod Patch: https://git.openjdk.org/jdk/pull/17101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17101/head:pull/17101 PR: https://git.openjdk.org/jdk/pull/17101 From alanb at openjdk.org Thu Dec 14 09:03:38 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Dec 2023 09:03:38 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) > - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) > > > In addition this includes the updates for > > - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23 > > Thanks Initially I wondered if JDK-8309981 should be separated but include keeps things in sync so I think okay. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17101#pullrequestreview-1781343785 From prappo at openjdk.org Thu Dec 14 09:19:37 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 14 Dec 2023 09:19:37 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) > - [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) > > > In addition this includes the updates for > > - [JDK-8309981](https://bugs.openjdk.org/browse/8309981) Remove expired flags in JDK 23 > > Thanks > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > * [JDK-8321384](https://bugs.openjdk.org/browse/JDK-8321384) (javadoc) Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855467435 From prappo at openjdk.org Thu Dec 14 10:13:47 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 14 Dec 2023 10:13:47 GMT Subject: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v8] In-Reply-To: References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com> Message-ID: <0dzuLQWeoMxenO1b4D7H5eeAa3Q_o2ql6S3-MPc4iUM=.1305f9e3-12ea-45ab-ac8a-52f92be5ff29@github.com> On Tue, 7 Nov 2023 07:58:40 GMT, Pavel Rappo wrote: >> Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them. >> >> This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon. > > Pavel Rappo 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 15 additional commits since the last revision: > > - Merge branch 'master' into 8310813 > - Merge branch 'master' into 8310813 > - Fix bugs in Shared.createSingle > - Merge branch 'master' into 8310813 > - Group params coarser (suggested by @cl4es) > > - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge. > Every testXYZ method invokes M operations, where M is the maximum > number of elements in a group. Shorter groups are cyclically padded. > - Uses the org.openjdk.jmh.infra.Blackhole API and increases > benchmark time. > - Fixes a bug in Shared that precluded 0 from being in a pair. > - Use better overloads (suggested by @cl4es) > > - Uses simpler, more suitable overloads for the subrange > starting from 0 > - Improve benchmarks > - Merge branch 'master' into 8310813 > - Restore hash code values > > BigInteger is old and ubiquitous enough so that there might be > inadvertent dependencies on its hash code. > > This commit also includes a test, to make sure hash code is > unchanged. > - Merge branch 'master' into 8310813 > - ... and 5 more: https://git.openjdk.org/jdk/compare/5a26cc03...155fedba Dear reviewers, what do you think about that performance data I recently published? ------------- PR Comment: https://git.openjdk.org/jdk/pull/14630#issuecomment-1855554882 From prappo at openjdk.org Thu Dec 14 10:18:28 2023 From: prappo at openjdk.org (Pavel Rappo) Date: Thu, 14 Dec 2023 10:18:28 GMT Subject: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger [v9] In-Reply-To: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com> References: <-bypZB03AZE1K1vsfn_qFZ98tuqrll8smbCBMaXnNLs=.ea39341c-df39-4278-956c-ce9bbe0f6611@github.com> Message-ID: > Please review this PR to use modern APIs and language features to simplify equals, hashCode, and compareTo for BigInteger. If you have any performance concerns, please raise them. > > This PR is cherry-picked from a bigger, not-yet-published PR, to test the waters. That latter PR will be published soon. Pavel Rappo 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 16 additional commits since the last revision: - Merge branch 'master' into 8310813 - Merge branch 'master' into 8310813 - Merge branch 'master' into 8310813 - Fix bugs in Shared.createSingle - Merge branch 'master' into 8310813 - Group params coarser (suggested by @cl4es) - Splits 20 params into 3 groups: (S)mall, (M)edium and (L)arge. Every testXYZ method invokes M operations, where M is the maximum number of elements in a group. Shorter groups are cyclically padded. - Uses the org.openjdk.jmh.infra.Blackhole API and increases benchmark time. - Fixes a bug in Shared that precluded 0 from being in a pair. - Use better overloads (suggested by @cl4es) - Uses simpler, more suitable overloads for the subrange starting from 0 - Improve benchmarks - Merge branch 'master' into 8310813 - Restore hash code values BigInteger is old and ubiquitous enough so that there might be inadvertent dependencies on its hash code. This commit also includes a test, to make sure hash code is unchanged. - ... and 6 more: https://git.openjdk.org/jdk/compare/5f6cebff...ef8b0c46 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14630/files - new: https://git.openjdk.org/jdk/pull/14630/files/155fedba..ef8b0c46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14630&range=07-08 Stats: 782591 lines in 3816 files changed: 173277 ins; 536256 del; 73058 mod Patch: https://git.openjdk.org/jdk/pull/14630.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14630/head:pull/14630 PR: https://git.openjdk.org/jdk/pull/14630 From dholmes at openjdk.org Thu Dec 14 12:26:40 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 12:26:40 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 09:17:05 GMT, Pavel Rappo wrote: > Thanks for doing this, David. I only note that the changes for JDK-8321384 were published in [JDK-8308715](https://bugs.openjdk.org/browse/JDK-8308715), which was integrated in the mainline before JDK 22 RDP 1. So they are already present in the mainline. Ah I see. Thanks for correcting that, I will update the PR and JBS issue. And thanks for looking at this @pavelrappo . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855755042 From dholmes at openjdk.org Thu Dec 14 12:30:38 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 12:30:38 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 09:01:17 GMT, Alan Bateman wrote: > Initially I wondered if JDK-8309981 should be separated but include keeps things in sync so I think okay. Thanks for the review @AlanBateman . Yeah I was in two minds there myself. I started fixing [JDK-8309981](https://bugs.openjdk.org/browse/JDK-8309981) only to discover that the start of release updates had not been done as part of the start of release, so I figured I may as well fix it all together given I'd generated all the updated files anyway. But I'm still a little unsure ... in fact I think I will remove it in the morning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17101#issuecomment-1855761906 From dholmes at openjdk.org Thu Dec 14 12:35:52 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 12:35:52 GMT Subject: RFR: 8322065: Initial nroff manpage generation for JDK 23 [v2] In-Reply-To: References: Message-ID: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Revert "8309981: Remove expired flags in JDK 23" This reverts commit 0324a90e936ae01e42ae099e7235156326cc318a. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17101/files - new: https://git.openjdk.org/jdk/pull/17101/files/65a8c9ed..8b052141 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17101&range=00-01 Stats: 23 lines in 2 files changed: 10 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17101.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17101/head:pull/17101 PR: https://git.openjdk.org/jdk/pull/17101 From mullan at openjdk.org Thu Dec 14 14:31:39 2023 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 14 Dec 2023 14:31:39 GMT Subject: RFR: 8202598: keytool -certreq output contains inconsistent line separators In-Reply-To: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> References: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> Message-ID: <_p3dkCFDNjJnl8wNmZj2fgzBOpTHYuUHtlHyFfZkzhY=.15de04fd-efeb-425e-a060-6fc0f32837c1@github.com> On Mon, 11 Dec 2023 16:14:24 GMT, Weijun Wang wrote: > When keytool is dumping certificates, certificate requests, and CRLs using the `-rfc` option, the PEM output contains mixed line endings with LF after the header and footer and CRLF between the base64 text lines. This code change update all to CRLF. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17060#pullrequestreview-1781939450 From weijun at openjdk.org Thu Dec 14 14:39:47 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 14 Dec 2023 14:39:47 GMT Subject: Integrated: 8202598: keytool -certreq output contains inconsistent line separators In-Reply-To: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> References: <6q2NnZgYJznlQ19vbJxRXzbpU4ls0tez4_cU1t5DC68=.5b0e883c-c3cc-41ea-b890-c1003908f77b@github.com> Message-ID: On Mon, 11 Dec 2023 16:14:24 GMT, Weijun Wang wrote: > When keytool is dumping certificates, certificate requests, and CRLs using the `-rfc` option, the PEM output contains mixed line endings with LF after the header and footer and CRLF between the base64 text lines. This code change update all to CRLF. This pull request has now been integrated. Changeset: 45a9ade3 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/45a9ade3374e38205cdf3fd24282246830789d26 Stats: 109 lines in 3 files changed: 97 ins; 0 del; 12 mod 8202598: keytool -certreq output contains inconsistent line separators Reviewed-by: hchao, mullan ------------- PR: https://git.openjdk.org/jdk/pull/17060 From duke at openjdk.org Thu Dec 14 18:00:49 2023 From: duke at openjdk.org (Ben Perez) Date: Thu, 14 Dec 2023 18:00:49 GMT Subject: Integrated: 8296787: Unify debug printing format of X.509 cert serial numbers In-Reply-To: References: Message-ID: <7dxP0mzRMSGzoNzrIMJh17jDsJHWvfjNGL0ixiLLUHo=.f08c2716-e40c-438d-8aec-b65357fd329d@github.com> On Mon, 27 Nov 2023 21:45:23 GMT, Ben Perez wrote: > Updated `X509CertSelector.java`, `SerialNumber.java`, and `SSLLogger` to use same debug printing format for X.509 serial numbers. The changes are: > - `X509CertSelector` was `SN: 83be056904246b1a1756ac95991c74a` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SerialNumber` was `SerialNumber: [ 083be056 904246b1 a1756ac9 5991c74a]` and now is `Serial number: 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` > - `SSLLogger` was `"serial number" : "083BE056904246B1A1756AC95991C74A"` and now is `"serial number" : 08:3B:E0:56:90:42:46:B1:A1:75:6A:C9:59:91:C7:4A` This pull request has now been integrated. Changeset: c328f958 Author: Ben Perez Committer: Sean Mullan URL: https://git.openjdk.org/jdk/commit/c328f9589ddc3a981a2c63801bd991f8e593e69f Stats: 65 lines in 18 files changed: 19 ins; 3 del; 43 mod 8296787: Unify debug printing format of X.509 cert serial numbers Reviewed-by: mullan, coffeys ------------- PR: https://git.openjdk.org/jdk/pull/16834 From mdonovan at openjdk.org Thu Dec 14 19:08:20 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 14 Dec 2023 19:08:20 GMT Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 [v3] In-Reply-To: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> Message-ID: > In this PR, I included logic to skip tests on Oracle Linux prior to version 8. The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9. Matthew Donovan 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: - simplified logic for determining OL 7 - Merge branch 'master' into pkcs11-ol79 - cleaned up MultipleLogins.java a little and added copyright date - Merge branch 'master' into pkcs11-ol79 - Merge branch 'master' into pkcs11-ol79 - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16547/files - new: https://git.openjdk.org/jdk/pull/16547/files/b20b8e3a..28c42b1e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16547&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16547&range=01-02 Stats: 114898 lines in 2262 files changed: 62506 ins; 44008 del; 8384 mod Patch: https://git.openjdk.org/jdk/pull/16547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16547/head:pull/16547 PR: https://git.openjdk.org/jdk/pull/16547 From dholmes at openjdk.org Thu Dec 14 21:28:47 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Dec 2023 21:28:47 GMT Subject: Integrated: 8322065: Initial nroff manpage generation for JDK 23 In-Reply-To: References: Message-ID: On Thu, 14 Dec 2023 05:46:01 GMT, David Holmes wrote: > Updated the version to 23-ea and year to 2024. > > This initial generation also picks up the unpublished changes from: > > - [JDK-8302233](https://bugs.openjdk.org/browse/JDK-8302233) (keytool & jarsigner) > - [JDK-8290702](https://bugs.openjdk.org/browse/JDK-8290702) (javadoc) (JDK 23 backport) > > Thanks This pull request has now been integrated. Changeset: 692be577 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/692be577385844bf00a01ff10e390e014191569f Stats: 193 lines in 27 files changed: 36 ins; 51 del; 106 mod 8322065: Initial nroff manpage generation for JDK 23 Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/17101 From mbaesken at openjdk.org Fri Dec 15 08:08:47 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 15 Dec 2023 08:08:47 GMT Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 [v3] In-Reply-To: References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> Message-ID: On Thu, 14 Dec 2023 19:08:20 GMT, Matthew Donovan wrote: >> In this PR, I included logic to skip tests on Oracle Linux prior to version 8. The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9. > > Matthew Donovan 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: > > - simplified logic for determining OL 7 > - Merge branch 'master' into pkcs11-ol79 > - cleaned up MultipleLogins.java a little and added copyright date > - Merge branch 'master' into pkcs11-ol79 > - Merge branch 'master' into pkcs11-ol79 > - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/16547#pullrequestreview-1762659657 From mbaesken at openjdk.org Fri Dec 15 08:08:53 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 15 Dec 2023 08:08:53 GMT Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 [v2] In-Reply-To: References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> Message-ID: On Mon, 27 Nov 2023 14:47:29 GMT, Matthew Donovan wrote: >> In this PR, I included logic to skip tests on Oracle Linux prior to version 8. The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9. > > Matthew Donovan 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: > > - cleaned up MultipleLogins.java a little and added copyright date > - Merge branch 'master' into pkcs11-ol79 > - Merge branch 'master' into pkcs11-ol79 > - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 test/jdk/sun/security/pkcs11/PKCS11Test.java line 749: > 747: > 748: case "Linux-amd64-64": > 749: if (isOracleLinux7()) { Would it be the same for the older RedHat versions, I think they are rather close to Oracle Linux ? test/jdk/sun/security/pkcs11/PKCS11Test.java line 766: > 764: } > 765: > 766: private static boolean isOracleLinux7() { Why not move that into some central place, e.g. test/lib/Platform.java ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1414035362 PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1414032601 From mdonovan at openjdk.org Fri Dec 15 15:06:58 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 15 Dec 2023 15:06:58 GMT Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 [v4] In-Reply-To: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> Message-ID: <8kMOcCKjJT0G7Ea3jrz2xaY8W6ApEHTpjMhuFzXgqOU=.fe8d2243-b7af-485c-b55d-68922e548c1f@github.com> > In this PR, I included logic to skip tests on Oracle Linux prior to version 8. The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: moved isOracleLinux7() method to Platform class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16547/files - new: https://git.openjdk.org/jdk/pull/16547/files/28c42b1e..33a6c6b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16547&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16547&range=02-03 Stats: 32 lines in 2 files changed: 16 ins; 14 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16547/head:pull/16547 PR: https://git.openjdk.org/jdk/pull/16547 From mdonovan at openjdk.org Fri Dec 15 15:07:04 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 15 Dec 2023 15:07:04 GMT Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 [v2] In-Reply-To: References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> Message-ID: On Mon, 4 Dec 2023 15:03:03 GMT, Matthias Baesken wrote: >> Matthew Donovan 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: >> >> - cleaned up MultipleLogins.java a little and added copyright date >> - Merge branch 'master' into pkcs11-ol79 >> - Merge branch 'master' into pkcs11-ol79 >> - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 > > test/jdk/sun/security/pkcs11/PKCS11Test.java line 766: > >> 764: } >> 765: >> 766: private static boolean isOracleLinux7() { > > Why not move that into some central place, e.g. test/lib/Platform.java ? That's a good idea; I moved the method to the Platform class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1428075259 From mdonovan at openjdk.org Fri Dec 15 15:15:44 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 15 Dec 2023 15:15:44 GMT Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 [v2] In-Reply-To: References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> Message-ID: On Mon, 4 Dec 2023 15:05:08 GMT, Matthias Baesken wrote: >> Matthew Donovan 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: >> >> - cleaned up MultipleLogins.java a little and added copyright date >> - Merge branch 'master' into pkcs11-ol79 >> - Merge branch 'master' into pkcs11-ol79 >> - 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 > > test/jdk/sun/security/pkcs11/PKCS11Test.java line 749: > >> 747: >> 748: case "Linux-amd64-64": >> 749: if (isOracleLinux7()) { > > Would it be the same for the older RedHat versions, I think they are rather close to Oracle Linux ? Yes, I think the method would also return true for RH 7. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16547#discussion_r1428085637 From mdonovan at openjdk.org Fri Dec 15 17:33:04 2023 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 15 Dec 2023 17:33:04 GMT Subject: RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64 [v5] In-Reply-To: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> References: <9z7b46KuT1xCeD-5KgKjqKw2mJdIh_uwozEL5O8XMio=.7f7352b8-89b0-434e-b225-39b14426ba5d@github.com> Message-ID: > In this PR, I included logic to skip tests on Oracle Linux prior to version 8. The NSS binaries we are using for testing use a newer version of GLIBC than is included with OL 7.9. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: added isOracleLinux7() to IGNORED method group in TestMutuallyExclusivePlatformPredicates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/16547/files - new: https://git.openjdk.org/jdk/pull/16547/files/33a6c6b4..8f3f41a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16547&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16547&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16547/head:pull/16547 PR: https://git.openjdk.org/jdk/pull/16547 From rgiulietti at openjdk.org Fri Dec 15 17:39:52 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 15 Dec 2023 17:39:52 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations Message-ID: Adds serialization misdeclaration events to JFR. ------------- Commit messages: - Make use of EventNames. - Merge branch 'master' into 8275338 - 8275338: Add JFR events for notable serialization situations Changes: https://git.openjdk.org/jdk/pull/17129/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8275338 Stats: 769 lines in 10 files changed: 769 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From rgiulietti at openjdk.org Fri Dec 15 17:43:39 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 15 Dec 2023 17:43:39 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 17:34:53 GMT, Raffaello Giulietti wrote: > Adds serialization misdeclaration events to JFR. A serialization misdeclaration on one of the following fields or methods means that they are not declared according to the Java Object Serialization Specification (JOSS) or in the Java SE specification. Depending on the exact circumstances, a misdeclared member can be _ineffective_ for serialization, or can still be effective but does not adhere to the conventions stated in the specs. serialVersionUID serialPersistentFields writeObject() readObject() readObjectNoData() writeReplace() readResolve() This PR adds JFR events to detect such misdeclarations at runtime, when a serializable class is about to be used for serialization purposes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1858247455 From duke at openjdk.org Fri Dec 15 20:40:59 2023 From: duke at openjdk.org (Ben Perez) Date: Fri, 15 Dec 2023 20:40:59 GMT Subject: RFR: 8265372: Simplify PKCS9Attribute Message-ID: Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues. Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs. ------------- Commit messages: - refactored PKCSAttribute to use a hash map instead of multiple arrays Changes: https://git.openjdk.org/jdk/pull/17132/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17132&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8265372 Stats: 245 lines in 1 file changed: 39 ins; 110 del; 96 mod Patch: https://git.openjdk.org/jdk/pull/17132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17132/head:pull/17132 PR: https://git.openjdk.org/jdk/pull/17132 From rgiulietti at openjdk.org Fri Dec 15 22:26:04 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 15 Dec 2023 22:26:04 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v2] In-Reply-To: References: Message-ID: > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Restrict accessibility of nested classes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/f0b96e97..629e8f23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=00-01 Stats: 22 lines in 2 files changed: 3 ins; 2 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From egahlin at openjdk.org Sat Dec 16 01:30:38 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Sat, 16 Dec 2023 01:30:38 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v2] In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 22:26:04 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Restrict accessibility of nested classes. It seems correct to have the event disabled in both configurations. It's not hard to imagine pathological cases where millions of stream objects are created, which would create overhead and flood event buffers, making JFR not usable. That said, I wonder how many will actually use, or find out about the event, if they need to edit the .jfc file or specify -XX:StartFlightRecording:jdk.SerializationMisdeclaration#enabled=true on command line? How important is the stack trace when diagnosing serialization misdeclarations? We faced a similar situation with the Finalization event a couple of years ago, but we were able to make the event periodic and enabled by default with some VM magic. An event that is enabled by default will probably be seen by 10 000 times as many users, so it might be worth considering other approaches, even if they are harder to implement, or we lose some of the information. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1858665731 From rgiulietti at openjdk.org Mon Dec 18 14:34:37 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 18 Dec 2023 14:34:37 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v2] In-Reply-To: References: Message-ID: On Sat, 16 Dec 2023 01:27:17 GMT, Erik Gahlin wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Restrict accessibility of nested classes. > > It seems correct to have the event disabled in both configurations. It's not hard to imagine pathological cases where millions of stream objects are created, which would create overhead and flood event buffers, making JFR not usable. > > That said, I wonder how many will actually use, or find out about the event, if they need to edit the .jfc file or specify -XX:StartFlightRecording:jdk.SerializationMisdeclaration#enabled=true on command line? > > How important is the stack trace when diagnosing serialization misdeclarations? > > We faced a similar situation with the Finalization event a couple of years ago, but we were able to make the event periodic and enabled by default with some VM magic. An event that is enabled by default will probably be seen by 10 000 times as many users, so it might be worth considering other approaches, even if they are harder to implement, or we lose some of the information. @egahlin Yes, disabled by default means less overhead in the usual case. On the other hand, the checks and the events generation are done for serializable classes that actually actively participate in serialization, lazily, and just once per class, so maybe they are not as invasive and might be "always enabled". Pathological cases with millions of serializable classes might indeed lead to problems with "always enable", although they should be quite rare. I don't think that stack traces are that useful for this kind of event, since they are mostly related to the static class structure rather than to runtime characteristics. Looking at the event itself should help in locating the problem quickly: it reports the class, the member, and what's questionable with it. Or am I misunderstanding your points? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1860655448 From egahlin at openjdk.org Mon Dec 18 15:15:40 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 18 Dec 2023 15:15:40 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v2] In-Reply-To: References: Message-ID: On Sat, 16 Dec 2023 01:27:17 GMT, Erik Gahlin wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Restrict accessibility of nested classes. > > It seems correct to have the event disabled in both configurations. It's not hard to imagine pathological cases where millions of stream objects are created, which would create overhead and flood event buffers, making JFR not usable. > > That said, I wonder how many will actually use, or find out about the event, if they need to edit the .jfc file or specify -XX:StartFlightRecording:jdk.SerializationMisdeclaration#enabled=true on command line? > > How important is the stack trace when diagnosing serialization misdeclarations? > > We faced a similar situation with the Finalization event a couple of years ago, but we were able to make the event periodic and enabled by default with some VM magic. An event that is enabled by default will probably be seen by 10 000 times as many users, so it might be worth considering other approaches, even if they are harder to implement, or we lose some of the information. > @egahlin Yes, disabled by default means less overhead in the usual case. > > On the other hand, the checks and the events generation are done for serializable classes that actually actively participate in serialization, lazily, and just once per class, so maybe they are not as invasive and might be "always enabled". Pathological cases with millions of serializable classes might indeed lead to problems with "always enable", although they should be quite rare. > If it's once per class per JVM, I think it's fine to enable it in profile.jfc. It's meant to have low overhead (around 1%) for the typical application, but OK with higher in pathological cases. Loading/initiating a class has a cost, so it will likely dominate. > I don't think that stack traces are that useful for this kind of event, since they are mostly related to the static class structure rather than to runtime characteristics. Looking at the event itself should help in locating the problem quickly: it reports the class, the member, and what's questionable with it. > If we were to make the event periodic, it's hard to keep the stack trace around, at least in Java, so I wanted to know how important it is. Now if we can have it in profile.jfc, I think it's fine to keep it. If you think the stack trace has no use at all, then you could remove it and perhaps also the thread using the RemoveFields annotation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1860765344 From rgiulietti at openjdk.org Mon Dec 18 17:49:04 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 18 Dec 2023 17:49:04 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: References: Message-ID: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Event enabled on profile.jfc but disabled on default.jfc. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/629e8f23..8534d7af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=01-02 Stats: 37 lines in 5 files changed: 27 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From duke at openjdk.org Mon Dec 18 22:23:55 2023 From: duke at openjdk.org (duke) Date: Mon, 18 Dec 2023 22:23:55 GMT Subject: Withdrawn: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 15:25:08 GMT, Glavo wrote: > Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. > > Reasons: > > * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, creating a new shortcut can make writing shorter; > * Since all possible values of `byte` are legal Latin-1 characters, `newStringLatin1NoRepl` **will not throw `CharacterCodingException`**, so users can make the compiler happy without using useless try-catch statements. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/14655 From egahlin at openjdk.org Tue Dec 19 10:47:43 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Dec 2023 10:47:43 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> References: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> Message-ID: On Mon, 18 Dec 2023 17:49:04 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Event enabled on profile.jfc but disabled on default.jfc. src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 41: > 39: @Description("Methods and fields misdeclarations") > 40: @MirrorEvent(className = "jdk.internal.event.SerializationMisdeclarationEvent") > 41: @RemoveFields({"duration", "stackTrace", "thread"}) The field should be "eventThread" instead of "thread" src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 45: > 43: > 44: @Label("Class") > 45: public Class cls; We have often used a prefix, i.e. misdeclaredClass, to avoid using a reserved word. We try to stay out of abbreviations. src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 48: > 46: > 47: @Label("Kind") > 48: public int kind; What is the use case for error codes? Are they public or an implementation detail? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431226200 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431227843 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431229900 From duke at openjdk.org Tue Dec 19 11:54:36 2023 From: duke at openjdk.org (rebarbora-mckvak) Date: Tue, 19 Dec 2023 11:54:36 GMT Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com> References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com> Message-ID: On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak wrote: > This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367 > > If the process does not have write permissions, the store is opened as read-only (instead of failing). > > Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user. This is a very trivial change fixing rather annoying bug. Can someone review it and let it merge? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1862618406 From rgiulietti at openjdk.org Tue Dec 19 12:21:05 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 19 Dec 2023 12:21:05 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Better name for a label, corrected name of removed field. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/8534d7af..51507e4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From rgiulietti at openjdk.org Tue Dec 19 12:21:09 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 19 Dec 2023 12:21:09 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: References: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> Message-ID: On Tue, 19 Dec 2023 10:43:57 GMT, Erik Gahlin wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Event enabled on profile.jfc but disabled on default.jfc. > > src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 48: > >> 46: >> 47: @Label("Kind") >> 48: public int kind; > > What is the use case for error codes? Are they public or an implementation detail? The intent is that they are stable and for programmatic usage, whereas the message is more for human consumption. The codes are used in the test, for example, and are declared as public static in the event classes. Alternatively, one could parse the message, but that's less robust in face of changes, I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431329983 From weijun at openjdk.org Tue Dec 19 13:46:49 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 19 Dec 2023 13:46:49 GMT Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com> References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com> Message-ID: On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak wrote: > This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367 > > If the process does not have write permissions, the store is opened as read-only (instead of failing). > > Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user. @macarte, can you take a look at this fix? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1862784812 From jpai at openjdk.org Tue Dec 19 14:42:49 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 14:42:49 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. Hello Raffaello, > On the other hand, the checks and the events generation are done for serializable classes that actually actively participate in serialization, lazily, and just once per class Is it per class for each classloader that loads it? Or is it per class per JVM? It's more out of curiosity than anything else because I don't think it makes a big difference (I don't expect too many classloaders that would lead to the case of extremely large streams of events). ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1862882260 From jpai at openjdk.org Tue Dec 19 14:55:50 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 14:55:50 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 94: > 92: if (!isPrivate(f)) { > 93: commitEvent(SUID_PRIVATE, > 94: SUID_NAME + " should be declared private"); Rest of the event messages use "... to be effective", should this one too use a similar text? src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 108: > 106: SUID_NAME + " should be declared of type long"); > 107: } > 108: if (!isStatic(f)) { Nit - perhaps save the return value from the previous call to `isStatic(f)` a few lines above and reuse it here? src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 112: > 110: } > 111: f.setAccessible(true); > 112: if (getLong(f) == null) { Is this check and the `setAccessible()` needed if a few lines above, the call to `f.getType()` returns `Long.TYPE` (i.e. primitive type)? Perhaps we can conditionally do these additional checks and calls, only if `f.getType()` isn't a primitive? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431512491 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431506705 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431511005 From jpai at openjdk.org Tue Dec 19 15:04:51 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 15:04:51 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 185: > 183: commitEvent(PRIV_METH_NON_STATIC, > 184: m + " must be non-static to be effective"); > 185: } Should there also be a check to see if this `private` method is (misdeclared) as a `native` method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431524703 From jpai at openjdk.org Tue Dec 19 15:07:51 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 15:07:51 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 276: > 274: } > 275: > 276: private static Object getObject(Field f) { Should we call this method `getStaticFieldValue(...)`, because that's what the implementation is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431535049 From jpai at openjdk.org Tue Dec 19 15:13:50 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 15:13:50 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java line 94: > 92: > 93: /* > 94: * These constants are not final on purpose. Just curious - what's the purpose? I don't see them being changed/updated anywhere (not even in tests). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431551183 From jpai at openjdk.org Tue Dec 19 15:23:49 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 15:23:49 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: <6cwqiWvcFYeHEcIuNky7QpmSLqRruKRi-LRfM7xtpM4=.37176dc7-14fa-47e9-af9b-1dfb12f6bcce@github.com> On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 112: > 110: @MethodSource > 111: public void testGoodClass(Class cls) { > 112: assertEquals(0, getEventsFor(cls).size()); Can this and other assertions in this test be updated to include the class name which failed? You can still use `assertEquals(...)`, it takes an optional message as a third parameter which you could use to include the failing class name. It becomes a bit more easier to debug (unexpected) failures when the assertion includes these additional details. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431563775 From jpai at openjdk.org Tue Dec 19 15:28:48 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 15:28:48 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 144: > 142: } > 143: > 144: static { It's a bit odd for a test case to be doing this in a static block. Could this instead be done in a `org.junit.jupiter.api.BeforeAll` method: import org.junit.jupiter.api.BeforeAll; ... @BeforeAll static void recordEvents() { .... // that static block's code here } Any (unexpected) failures in that method will then be reported in a better way by the testing framework instead of an `ExceptionInInitializer` that would be reported from a failure in static block and the test class itself failing to load. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431571145 From jpai at openjdk.org Tue Dec 19 15:34:49 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 19 Dec 2023 15:34:49 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: <_O5pS8TSbnWoTnCwXIFWqHR9tMP_67ubEOqh6ZJP868=.7a3ad615-5bca-48d5-8a53-017f924e2f5c@github.com> On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50: > 48: * @requires vm.hasJFR > 49: * @library /test/lib > 50: * @run junit/othervm jdk.jfr.event.io.TestSerializationMisdeclarationEvent Is the use of "othervm" needed here because of the use of `jdk.jfr.consumer.RecordingStream`? Does `RecordingStream` do JVM wide state changes? I did a quick look at that class but couldn't come to a conclusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431578942 From rgiulietti at openjdk.org Tue Dec 19 16:03:55 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 19 Dec 2023 16:03:55 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 14:39:47 GMT, Jaikiran Pai wrote: > Is it per class for each classloader that loads it? Or is it per class per JVM? It's more out of curiosity than anything else because I don't think it makes a big difference (I don't expect too many classloaders that would lead to the case of extremely large streams of events). The checks are done on the `Class` instance, that is, per each defined (as per JVMS) and _used_ serializable class, on first usage in serialization. If enabled at all, they are invoked by the private `ObjectStreamClass` constructor. > src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 94: > >> 92: if (!isPrivate(f)) { >> 93: commitEvent(SUID_PRIVATE, >> 94: SUID_NAME + " should be declared private"); > > Rest of the event messages use "... to be effective", should this one too use a similar text? The field needs not be declared `private` to be effective, although it is recommended to do so. In this sense, "should" is just a recommendation, while "must" is really needed to make something effective. > src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 108: > >> 106: SUID_NAME + " should be declared of type long"); >> 107: } >> 108: if (!isStatic(f)) { > > Nit - perhaps save the return value from the previous call to `isStatic(f)` a few lines above and reuse it here? Assuming that most serializable classes are declared correctly, I don't think that caching the value of `isStatic()` makes a measurable difference. If at all, then I'd prefer to cache the modifiers and "inline" the masking logic of the individual is*() methods. > src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 112: > >> 110: } >> 111: f.setAccessible(true); >> 112: if (getLong(f) == null) { > > Is this check and the `setAccessible()` needed if a few lines above, the call to `f.getType()` returns `Long.TYPE` (i.e. primitive type)? Perhaps we can conditionally do these additional checks and calls, only if `f.getType()` isn't a primitive? Right, will be addressed in the next commit. > src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 185: > >> 183: commitEvent(PRIV_METH_NON_STATIC, >> 184: m + " must be non-static to be effective"); >> 185: } > > Should there also be a check to see if this `private` method is (misdeclared) as a `native` method? I'm not sure that a `native` method is not considered effective by serialization. I have to check. > src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 276: > >> 274: } >> 275: >> 276: private static Object getObject(Field f) { > > Should we call this method `getStaticFieldValue(...)`, because that's what the implementation is. Since the only parameter is `Field`, it has to be a static field almost for sure. Further, there's a `getLong()` method down below that operates on a static field as well and that one would also need a renaming. If I can come up with better names they will be in the next commit. > src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java line 94: > >> 92: >> 93: /* >> 94: * These constants are not final on purpose. > > Just curious - what's the purpose? I don't see them being changed/updated anywhere (not even in tests). Declaring a `public static int` field `final` means that the value is then stored in the client class. If a value is changed, then the client needs to be recompiled as well, but this is not enforced by the language, so it might lead to inconsistencies. The clean solution would be to use an enum class, but that's not supported by JFR. > test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50: > >> 48: * @requires vm.hasJFR >> 49: * @library /test/lib >> 50: * @run junit/othervm jdk.jfr.event.io.TestSerializationMisdeclarationEvent > > Is the use of "othervm" needed here because of the use of `jdk.jfr.consumer.RecordingStream`? Does `RecordingStream` do JVM wide state changes? I did a quick look at that class but couldn't come to a conclusion. Not sure, I have to check. > test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 112: > >> 110: @MethodSource >> 111: public void testGoodClass(Class cls) { >> 112: assertEquals(0, getEventsFor(cls).size()); > > Can this and other assertions in this test be updated to include the class name which failed? You can still use `assertEquals(...)`, it takes an optional message as a third parameter which you could use to include the failing class name. It becomes a bit more easier to debug (unexpected) failures when the assertion includes these additional details. Thanks for the suggestion, will take a look. > test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 144: > >> 142: } >> 143: >> 144: static { > > It's a bit odd for a test case to be doing this in a static block. Could this instead be done in a `org.junit.jupiter.api.BeforeAll` method: > > > import org.junit.jupiter.api.BeforeAll; > ... > @BeforeAll > static void recordEvents() { > .... // that static block's code here > } > > Any (unexpected) failures in that method will then be reported in a better way by the testing framework instead of an `ExceptionInInitializer` that would be reported from a failure in static block and the test class itself failing to load. Yes, yours is a cleaner way to go. Will do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863031458 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431613663 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431612831 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431613065 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431614036 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431615365 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431616847 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431618143 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431617706 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431617951 From rgiulietti at openjdk.org Tue Dec 19 16:30:47 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 19 Dec 2023 16:30:47 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 15:56:39 GMT, Raffaello Giulietti wrote: > > Is it per class for each classloader that loads it? Or is it per class per JVM? It's more out of curiosity than anything else because I don't think it makes a big difference (I don't expect too many classloaders that would lead to the case of extremely large streams of events). > > The checks are done on the `Class` instance, that is, per each defined (as per JVMS) and _used_ serializable class, on first usage in serialization. If enabled at all, they are invoked by the private `ObjectStreamClass` constructor. Well, in fact `ObjectStreamClass` maintains a cache of `Class` -> `ObjectStreamClass` to avoid creating a new instance of `ObjectStreamClass` each time a `Class` is looked up. It memoizes the association the first time. However, the cache can be emptied under high memory pressure, so the `ObjectStreamClass` instance might be recreated later, thus re-invoking the serialization checker once again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863090984 From rgiulietti at openjdk.org Tue Dec 19 16:45:04 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 19 Dec 2023 16:45:04 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: References: Message-ID: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Changes according to reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/51507e4e..fa04bf48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=03-04 Stats: 44 lines in 2 files changed: 15 ins; 14 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From egahlin at openjdk.org Tue Dec 19 17:18:41 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Dec 2023 17:18:41 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> Message-ID: On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Changes according to reviewer's comments. src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 39: > 37: import static java.lang.reflect.Modifier.*; > 38: > 39: final class SerializationMisdeclarationChecker { Is there a reason this event is placed in java.io package and not jdk.internal.event like other events? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431717967 From egahlin at openjdk.org Tue Dec 19 17:18:44 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Dec 2023 17:18:44 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: References: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> Message-ID: On Tue, 19 Dec 2023 12:17:38 GMT, Raffaello Giulietti wrote: >> src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 48: >> >>> 46: >>> 47: @Label("Kind") >>> 48: public int kind; >> >> What is the use case for error codes? Are they public or an implementation detail? > > The intent is that they are stable and for programmatic usage, whereas the message is more for human consumption. The codes are used in the test, for example, and are declared as public static in the event classes. > > Alternatively, one could parse the message, but that's less robust in face of changes, I think. Users (not OpenJDK developers) don't know what the error code means. I think it's better to not have them. This is how other events work. If you want to guard against changes, I would export the package to the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431716132 From egahlin at openjdk.org Tue Dec 19 17:27:54 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Dec 2023 17:27:54 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 16:00:59 GMT, Raffaello Giulietti wrote: >> test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 50: >> >>> 48: * @requires vm.hasJFR >>> 49: * @library /test/lib >>> 50: * @run junit/othervm jdk.jfr.event.io.TestSerializationMisdeclarationEvent >> >> Is the use of "othervm" needed here because of the use of `jdk.jfr.consumer.RecordingStream`? Does `RecordingStream` do JVM wide state changes? I did a quick look at that class but couldn't come to a conclusion. > > Not sure, I have to check. All the other events run in othervm. While it may be possible in some case to not do that, it's much easier to analyse issues, if we are sure the JVM is fresh. For example, JFR may not generate bytecode if an event is disabled. The JFR tests have been hardened to be able to run in parallel, so they run pretty fast. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431727571 From macarte at openjdk.org Tue Dec 19 17:38:50 2023 From: macarte at openjdk.org (Mat Carter) Date: Tue, 19 Dec 2023 17:38:50 GMT Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com> References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com> Message-ID: On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak wrote: > This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367 > > If the process does not have write permissions, the store is opened as read-only (instead of failing). > > Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user. Apologies I wasn't aware of the JBS issue until I saw this github notification. At a glance the fix seems trivial, but I'll need to test it. We were planning on looking at supporting the ability to open a keystore with READONLY access and I emailed security-dev to this effect in May Considering this change, I'd suggest that when the store is opened with read-only permissions that some warning is output (if this can't be detected then we may have to attempt to open with write-priviledges and the fall back to read-only (CERT_STORE_READONLY_FLAG). @rebarbora-mckvak - what testing was done with an elevated user opening a keystore with (CERT_STORE_MAXIMUM_ALLOWED_FLAG) and then attempting write-operations on the keystore? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1863211291 From egahlin at openjdk.org Tue Dec 19 17:44:49 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Dec 2023 17:44:49 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: <3W5zOlTu7-VH5IjzqDBjkB-B1aSzNBrqN85nIfo05Dk=.73042d7c-01bd-41ed-a0f1-8bc7d8625c97@github.com> On Tue, 19 Dec 2023 16:28:03 GMT, Raffaello Giulietti wrote: > However, the cache can be emptied under high memory pressure, so the `ObjectStreamClass` instance might be recreated later, thus re-invoking the serialization checker once again. I think it would be good to state in the description when checks occur, something like: Only the first time a class is serialized are the misdeclaration checks carried out, but may happen happen more frequently under high memory pressure. (Try to avoid using the word "event") ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863216232 From rgiulietti at openjdk.org Tue Dec 19 17:44:51 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 19 Dec 2023 17:44:51 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> Message-ID: On Tue, 19 Dec 2023 17:15:40 GMT, Erik Gahlin wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes according to reviewer's comments. > > src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 39: > >> 37: import static java.lang.reflect.Modifier.*; >> 38: >> 39: final class SerializationMisdeclarationChecker { > > Is there a reason this event is placed in java.io package and not jdk.internal.event like other events? The mirror event itself and the JFR event are placed in their standard locations. Only the checker is in `java.io`, so I'm not sure what you mean here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431740613 From rgiulietti at openjdk.org Tue Dec 19 17:44:52 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 19 Dec 2023 17:44:52 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: References: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> Message-ID: On Tue, 19 Dec 2023 17:13:58 GMT, Erik Gahlin wrote: >> The intent is that they are stable and for programmatic usage, whereas the message is more for human consumption. The codes are used in the test, for example, and are declared as public static in the event classes. >> >> Alternatively, one could parse the message, but that's less robust in face of changes, I think. > > Users (not OpenJDK developers) don't know what the error code means. I think it's better to not have them. This is how other events work. If you want to guard against changes, I would export the package to the test. What about fixed `String`s rather than `int`s for the kind of error? Something like `"SUID_INEFFECTIVE_ON_ENUM"`, and so on? It would be nice to be able to use enums, but AFAIK that's not supported in JFR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431744479 From rgiulietti at openjdk.org Tue Dec 19 17:48:48 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 19 Dec 2023 17:48:48 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> Message-ID: On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Changes according to reviewer's comments. You mean, in the @Description annotation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863223947 From egahlin at openjdk.org Tue Dec 19 17:58:41 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Dec 2023 17:58:41 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> Message-ID: On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Changes according to reviewer's comments. > You mean, in the @description annotation? Yes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1863235723 From egahlin at openjdk.org Tue Dec 19 17:58:44 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 19 Dec 2023 17:58:44 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> Message-ID: On Tue, 19 Dec 2023 17:37:50 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 39: >> >>> 37: import static java.lang.reflect.Modifier.*; >>> 38: >>> 39: final class SerializationMisdeclarationChecker { >> >> Is there a reason this event is placed in java.io package and not jdk.internal.event like other events? > > The mirror event itself and the JFR event are placed in their standard locations. > Only the checker is in `java.io`, so I'm not sure what you mean here. Sorry, my fault. Github showed "SerializationMisdeclar..." and I thought it was the event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431762931 From weijun at openjdk.org Tue Dec 19 18:34:38 2023 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 19 Dec 2023 18:34:38 GMT Subject: RFR: 8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation In-Reply-To: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com> References: <1V_luxg4sSw5kt4TwmtXVt-7xPbkYNNTppLXdil8KwI=.89bff412-42d8-45de-a648-5d13b9fdb986@github.com> Message-ID: On Thu, 16 Nov 2023 12:06:26 GMT, rebarbora-mckvak wrote: > This fixes the defect described at https://bugs.openjdk.org/browse/JDK-8313367 > > If the process does not have write permissions, the store is opened as read-only (instead of failing). > > Please note that permissions to use a certificate in a local machine store must be granted - in a management console, select a certificate, right-click -> All tasks... -> Manage Private Keys... -> add Full control to user. Also, when a keystore is read-only. What happens when one tries to write into it? Ideally a `KeyStoreException` should be thrown with a clear and precise message. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16687#issuecomment-1863285096 From rriggs at openjdk.org Tue Dec 19 19:44:44 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 19 Dec 2023 19:44:44 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 12:21:05 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Better name for a label, corrected name of removed field. src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 108: > 106: SUID_NAME + " should be declared of type long"); > 107: } > 108: if (!isStatic(f)) { The two calls to isStatic could be reordered closer together to be a single if (isstatic()) { ... } else {... }. src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java line 126: > 124: public static int ACC_METH_PARAM_TYPES = 404; > 125: public static int ACC_METH_NON_ACCESSIBLE = 405; > 126: I'd rather see few (fewer, just one) kinds of events, with so many different kinds of events there needs to be a convenient method to look for any kind of serialization mis-declaration. Perhaps a single event with flags for the different kinds of errors. The event classes could be responsible for turning the flags back into useful messages on display. test/jdk/jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java line 157: > 155: } > 156: > 157: private static class A implements Serializable { The test classes should document the good or badness of the class either in the class/field/method names or in comments. What's wrong with this XXX. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431846034 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431850091 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431856800 From rriggs at openjdk.org Tue Dec 19 19:44:45 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 19 Dec 2023 19:44:45 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: References: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> Message-ID: On Tue, 19 Dec 2023 17:41:57 GMT, Raffaello Giulietti wrote: >> Users (not OpenJDK developers) don't know what the error code means. I think it's better to not have them. This is how other events work. If you want to guard against changes, I would export the package to the test. > > What about fixed `String`s rather than `int`s for the kind of error? > Something like `"SUID_INEFFECTIVE_ON_ENUM"`, and so on? > It would be nice to be able to use enums, but AFAIK that's not supported in JFR. You could define them with an Enum but use the ordinal as the value for JFR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1431864329 From dfuchs at openjdk.org Wed Dec 20 08:34:49 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 20 Dec 2023 08:34:49 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: <-0hCh3zRb_gxLlZ9RQaeVh3pgxXZShI8FCNE-RG2NIU=.fa6c30c2-2b7c-4d10-aed4-b6095d358939@github.com> On Tue, 19 Dec 2023 16:00:09 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/jdk/internal/event/SerializationMisdeclarationEvent.java line 94: >> >>> 92: >>> 93: /* >>> 94: * These constants are not final on purpose. >> >> Just curious - what's the purpose? I don't see them being changed/updated anywhere (not even in tests). > > Declaring a `public static int` field `final` means that the value is then stored in the client class. If a value is changed, then the client needs to be recompiled as well, but this is not enforced by the language, so it might lead to inconsistencies. > > The clean solution would be to use an enum class, but that's not supported by JFR. Not having them final is a quite smelly. I would suggest to make them final with a comment that new values can be added but that existing values must not be changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432400888 From dfuchs at openjdk.org Wed Dec 20 08:34:51 2023 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 20 Dec 2023 08:34:51 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: References: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> Message-ID: On Tue, 19 Dec 2023 19:39:22 GMT, Roger Riggs wrote: >> What about fixed `String`s rather than `int`s for the kind of error? >> Something like `"SUID_INEFFECTIVE_ON_ENUM"`, and so on? >> It would be nice to be able to use enums, but AFAIK that's not supported in JFR. > > You could define them with an Enum but use the ordinal as the value for JFR. Same remark here about finality as https://github.com/openjdk/jdk/pull/17129#discussion_r1432400888. public statics should be final. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432402527 From rgiulietti at openjdk.org Wed Dec 20 11:14:42 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 20 Dec 2023 11:14:42 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v4] In-Reply-To: References: Message-ID: On Tue, 19 Dec 2023 19:19:35 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Better name for a label, corrected name of removed field. > > src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 108: > >> 106: SUID_NAME + " should be declared of type long"); >> 107: } >> 108: if (!isStatic(f)) { > > The two calls to isStatic could be reordered closer together to be a single if (isstatic()) { ... } else {... }. I guess you are looking to an older commit? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432581987 From mullan at openjdk.org Wed Dec 20 13:22:45 2023 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 20 Dec 2023 13:22:45 GMT Subject: RFR: 8187634: keystore.getCertificateAlias(cert) returns original alias, inconsistent with fix of JDK-6483657 In-Reply-To: References: Message-ID: <5C9mUD_R7J9srfj_jIs3AVFFZFzPPqcsZ7rmJNmbRl0=.293a8247-5b85-4b79-84bf-ff7498689e6d@github.com> On Fri, 8 Dec 2023 19:12:57 GMT, Weijun Wang wrote: > The alias in the keystore is `mapEntry.getKey()`. `entry.getAlias()` is the original friendly name, which is still useful when overwriting or removing an entry. Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/17037#pullrequestreview-1790879292 From rriggs at openjdk.org Wed Dec 20 14:19:51 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 20 Dec 2023 14:19:51 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: References: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> Message-ID: On Wed, 20 Dec 2023 08:29:19 GMT, Daniel Fuchs wrote: >> You could define them with an Enum but use the ordinal as the value for JFR. > > Same remark here about finality as https://github.com/openjdk/jdk/pull/17129#discussion_r1432400888. public statics should be final. I'd also remove the error codes, the string messages will be pretty stable and the extra surface area of the constants is just maintenance overhead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432772028 From rriggs at openjdk.org Wed Dec 20 14:24:51 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 20 Dec 2023 14:24:51 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> Message-ID: On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Changes according to reviewer's comments. src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113: > 111: if (longFromStatic(f) == null) { > 112: commitEvent(SUID_CONVERTIBLE_TO_LONG, > 113: SUID_NAME + " must be convertible to long via widening to be effective"); The serialization spec only shows using long. If any recommendation is made it should be to declare the field as a `long` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432778556 From rriggs at openjdk.org Wed Dec 20 14:31:54 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 20 Dec 2023 14:31:54 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> Message-ID: <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com> On Tue, 19 Dec 2023 16:45:04 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Changes according to reviewer's comments. It would also be useful/interesting to include a test that checks every Serializable class (by Invoking `ObjectStreamClass.lookup(clazz)`) in the Java runtime and reports any jfr events. Fixing them would be a separate task. The compiler warnings from last year should have fixed most/many non-conforming classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1864569540 From rgiulietti at openjdk.org Wed Dec 20 15:06:53 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 20 Dec 2023 15:06:53 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com> References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com> Message-ID: On Wed, 20 Dec 2023 14:28:39 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes according to reviewer's comments. > > It would also be useful/interesting to include a test that checks every Serializable class (by Invoking `ObjectStreamClass.lookup(clazz)`) in the Java runtime and reports any jfr events. > Fixing them would be a separate task. The compiler warnings from last year should have fixed most/many non-conforming classes. @RogerRiggs Do you mean a permanent test in the codebase, or just a throwaway run? Anyway, interesting suggestion. > src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113: > >> 111: if (longFromStatic(f) == null) { >> 112: commitEvent(SUID_CONVERTIBLE_TO_LONG, >> 113: SUID_NAME + " must be convertible to long via widening to be effective"); > > The serialization spec only shows using long. If any recommendation is made it should be to declare the field as a `long` There's a check on the type at L.104 which is about the "should" recommendation, since serialization does not care about the type of the field being `long`. This check is about the value at runtime, which is a "must" because serialization expects it to be convertible to long by widening. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1864628102 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432827176 From rgiulietti at openjdk.org Wed Dec 20 15:06:55 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 20 Dec 2023 15:06:55 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v3] In-Reply-To: References: <_8M6KPN0UJHeW1cx31IW0mIfaXG5ls5nUfZ0TwxMdAs=.fd4facc4-91d4-4117-9b1f-a2cc1806d2b7@github.com> Message-ID: On Wed, 20 Dec 2023 14:17:19 GMT, Roger Riggs wrote: >> Same remark here about finality as https://github.com/openjdk/jdk/pull/17129#discussion_r1432400888. public statics should be final. > > I'd also remove the error codes, the string messages will be pretty stable and the extra surface area of the constants is just maintenance overhead. Working on that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432828516 From rriggs at openjdk.org Wed Dec 20 15:09:58 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 20 Dec 2023 15:09:58 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com> Message-ID: On Wed, 20 Dec 2023 15:01:02 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 113: >> >>> 111: if (longFromStatic(f) == null) { >>> 112: commitEvent(SUID_CONVERTIBLE_TO_LONG, >>> 113: SUID_NAME + " must be convertible to long via widening to be effective"); >> >> The serialization spec only shows using long. If any recommendation is made it should be to declare the field as a `long` > > There's a check on the type at L.104 which is about the "should" recommendation, since serialization does not care about the type of the field being `long`. > > This check is about the value at runtime, which is a "must" because serialization expects it to be convertible to long by widening. The implementation should not show through. I don't remember if the particular implementation was intentional or just a shortcut to get the value. But any suggestion that implies a fix should be to recommend the best practice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1432834402 From rriggs at openjdk.org Wed Dec 20 15:12:56 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 20 Dec 2023 15:12:56 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v5] In-Reply-To: <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com> References: <4UGp6W9Tm0eHgXJEk-ZgVWUGgDkMMJb1hKTTixkcTHk=.9dd10aba-8d8f-42b0-a732-317c84b54a25@github.com> <2yRrfqmGcf3cIYkaaNuVXMzLQ6jNKoOCKZJXuYcwbgk=.b16d767f-88b1-47f6-a4bb-98d6c435401e@github.com> Message-ID: On Wed, 20 Dec 2023 14:28:39 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes according to reviewer's comments. > > It would also be useful/interesting to include a test that checks every Serializable class (by Invoking `ObjectStreamClass.lookup(clazz)`) in the Java runtime and reports any jfr events. > Fixing them would be a separate task. The compiler warnings from last year should have fixed most/many non-conforming classes. > @RogerRiggs Do you mean a permanent test in the codebase, or just a throwaway run? Anyway, interesting suggestion. A separate PR to add permanent test would advise about the current state and prevent new cases. If there are cases that can't be fixed (because of some kind of backward compatibility issue), there might need to be an exclusion list. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17129#issuecomment-1864639166 From weijun at openjdk.org Wed Dec 20 15:48:49 2023 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 20 Dec 2023 15:48:49 GMT Subject: Integrated: 8187634: keystore.getCertificateAlias(cert) returns original alias, inconsistent with fix of JDK-6483657 In-Reply-To: References: Message-ID: On Fri, 8 Dec 2023 19:12:57 GMT, Weijun Wang wrote: > The alias in the keystore is `mapEntry.getKey()`. `entry.getAlias()` is the original friendly name, which is still useful when overwriting or removing an entry. This pull request has now been integrated. Changeset: 424c58f3 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/424c58f3e94927b68329510e38bf5621f6f6e1a1 Stats: 99 lines in 2 files changed: 97 ins; 0 del; 2 mod 8187634: keystore.getCertificateAlias(cert) returns original alias, inconsistent with fix of JDK-6483657 Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/17037 From rgiulietti at openjdk.org Wed Dec 20 17:00:10 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 20 Dec 2023 17:00:10 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v6] In-Reply-To: References: Message-ID: > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Removed event kind. serialVersionUID must have type long. Test now base on keyword search in event message. Commented test classes about misdeclarations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/fa04bf48..a6f80250 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=04-05 Stats: 285 lines in 4 files changed: 87 ins; 96 del; 102 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From rgiulietti at openjdk.org Wed Dec 20 17:09:05 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 20 Dec 2023 17:09:05 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v7] In-Reply-To: References: Message-ID: > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Minor changes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/a6f80250..0cab1c1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=05-06 Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From rgiulietti at openjdk.org Wed Dec 20 18:08:09 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 20 Dec 2023 18:08:09 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v8] In-Reply-To: References: Message-ID: <9tk_5iLxqgURHyC59--KpXolXd11NV3gd8L4bCxigjU=.e8bef2cd-9934-451e-a428-8fb2a1283ec6@github.com> > Adds serialization misdeclaration events to JFR. Raffaello Giulietti 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 11 additional commits since the last revision: - Merge branch 'master' into 8275338 - Renamed an event field. - Minor changes. - Removed event kind. serialVersionUID must have type long. Test now base on keyword search in event message. Commented test classes about misdeclarations. - Changes according to reviewer's comments. - Better name for a label, corrected name of removed field. - Event enabled on profile.jfc but disabled on default.jfc. - Restrict accessibility of nested classes. - Make use of EventNames. - Merge branch 'master' into 8275338 - ... and 1 more: https://git.openjdk.org/jdk/compare/6ea0f368...94fc01ba ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/0cab1c1b..94fc01ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=06-07 Stats: 2512 lines in 172 files changed: 1722 ins; 321 del; 469 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From rgiulietti at openjdk.org Thu Dec 21 09:36:06 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 21 Dec 2023 09:36:06 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v9] In-Reply-To: References: Message-ID: > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Removed @module from test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/94fc01ba..3289bee3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=07-08 Stats: 14 lines in 1 file changed: 0 ins; 2 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From egahlin at openjdk.org Thu Dec 21 09:42:06 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 21 Dec 2023 09:42:06 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v9] In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 09:36:06 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Removed @module from test. src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 37: > 35: > 36: @Name(Type.EVENT_NAME_PREFIX + "SerializationMisdeclaration") > 37: @Label("Serialization Deserialization") The label of the event seems incorrect, shouldn't it be "Serialization Misdeclaration"? src/jdk.jfr/share/classes/jdk/jfr/events/SerializationMisdeclarationEvent.java line 47: > 45: public final class SerializationMisdeclarationEvent extends AbstractJDKEvent { > 46: > 47: @Label("MisdeclaredClass") Should be "Misdeclared Class" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1433814736 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1433813701 From rgiulietti at openjdk.org Thu Dec 21 09:53:10 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 21 Dec 2023 09:53:10 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v10] In-Reply-To: References: Message-ID: > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Corrected @Label of event and of field. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/3289bee3..9cb25a12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=08-09 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From weijun at openjdk.org Thu Dec 21 16:23:37 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 21 Dec 2023 16:23:37 GMT Subject: RFR: 8265372: Simplify PKCS9Attribute In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 20:34:21 GMT, Ben Perez wrote: > Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. > > It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues. > > Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs. I suggest removing the TABLE in the class spec. Now that we have the map it's easy to read all info from one place. There is no need to maintain the table anymore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17132#issuecomment-1866596268 From weijun at openjdk.org Thu Dec 21 17:32:48 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 21 Dec 2023 17:32:48 GMT Subject: RFR: 8265372: Simplify PKCS9Attribute In-Reply-To: References: Message-ID: <4cZmPycr4bhlWebjdLJX12HvcA8ePx-IuHL2dJpErA0=.1985c369-a811-43f1-b596-19810f127cb6@github.com> On Fri, 15 Dec 2023 20:34:21 GMT, Ben Perez wrote: > Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. > > It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues. > > Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 186: > 184: /** > 185: * Array of attribute OIDs defined in PKCS9, by number. > 186: */ I don't think `PKCS9_OIDS` is useful now. It's used in `PKCS9Attributes.getAttributes()` but this method is used nowhere. It's also used in `PKCS9Attributes.toString` but we can just iterate through `attributes` there. I don't see a reason to print the attributes in this order. If we want to print them in the order they appear in the data, we can use `LinkedHashMap` to in `PKCS9Attributes`. `Hashtable` is a little stale. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 193: > 191: static { > 192: try { > 193: BYTE_ARRAY_CLASS = Class.forName("[B"); Is this simply `byte[].class`? In fact I wonder if it's worth define a variable for this. Just use the literal directly everywhere. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 220: > 218: ObjectIdentifier.of(KnownOIDs.IssuerAndSerialNumber); > 219: // [11], [12] are RSA DSI proprietary > 220: // [13] ==> signingDescription, S/MIME, not used anymore No need to talk about indexes in the array now since there is no array. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 230: > 228: ObjectIdentifier.of(KnownOIDs.CMSAlgorithmProtection); > 229: > 230: private static final Map oidMap = new LinkedHashMap<>(); Why `Linked`? Need an order somewhere? src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 232: > 230: private static final Map oidMap = new LinkedHashMap<>(); > 231: private static void add(ObjectIdentifier oid, boolean singleValued, > 232: Class valueClass, Byte[] valueTags) { I think there is no need to use `Byte`, just using `byte` is OK. There is nowhere that the tag can be `null`. The `indexOf()` method is only used once and it needs not be generel. Also, if you make the last argument above a vararg (`byte... valueTag`), there will be no need to write so many `new Byte[] {` in the `add` calls. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 241: > 239: static { > 240: try { > 241: Class str = Class.forName("[Ljava.lang.String;"); `String[].class`. In fact I wonder if it's worth define a variable for this. Just use the literal directly everywhere. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 255: > 253: > 254: add(CONTENT_TYPE_OID, true, > 255: Class.forName("sun.security.util.ObjectIdentifier"), `sun.security.util.ObjectIdentifier.class`, same below. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 287: > 285: new Byte[]{DerValue.tag_Sequence}); > 286: > 287: add(SIGNING_CERTIFICATE_OID, true, null, Is the `null` class here safe? `SigningCertificateInfo` is already used elsewhere. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 308: > 306: /** > 307: * The index of the OID of this attribute in PKCS9_OIDS, > 308: * or -1 if it's unknown. Rewrite comment. Also for `value`. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 339: > 337: > 338: private void init(ObjectIdentifier oid, Object value) > 339: throws IllegalArgumentException { If we inline `init` into its caller, there is a chance to make all fields `final`. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 344: > 342: info = oidMap.get(oid); > 343: Class clazz = (info == null) ? BYTE_ARRAY_CLASS : info.valueClass(); > 344: if (clazz == null) { If we assign a class to `SIGNING_CERTIFICATE_OID`, this will never be null. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 462: > 460: break; > 461: > 462: default: // Can't happen Then throw an exception. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 480: > 478: > 479: KnownOIDs knownOID = KnownOIDs.findMatch(oid.toString()); > 480: if (knownOID == null) { The OID might be defined in `KnownOIDs` but not supported here. Then you might fall into the `default` case below. I think a better check is to see if `info` is null. src/java.base/share/classes/sun/security/pkcs/PKCS9Attribute.java line 574: > 572: break; > 573: > 574: default: // Can't happen Then throw an exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434277885 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434283698 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434284316 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434284947 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434293465 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434296628 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434300444 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434309185 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434306645 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434330844 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434310225 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434331159 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434336294 PR Review Comment: https://git.openjdk.org/jdk/pull/17132#discussion_r1434336632 From weijun at openjdk.org Thu Dec 21 17:42:46 2023 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 21 Dec 2023 17:42:46 GMT Subject: RFR: 8265372: Simplify PKCS9Attribute In-Reply-To: References: Message-ID: On Fri, 15 Dec 2023 20:34:21 GMT, Ben Perez wrote: > Refactored PKCS9Attribute to use a hash map instead of multiple arrays. The key for the hash map is an `ObjectIdentifier` and the values are a record `AttributeInfo` that stores the information previously contained in the arrays `PKCS9_VALUE_TAGS`, `VALUE_CLASSES`, and `SINGLE_VALUED`. > > It seems as though we should be able to get rid of constants such as `EMAIL_ADDRESS_OID` since they aren't heavily used with the hash map approach, but since the values are public it might cause compatibility issues. > > Another question is how to handle `RSA DSI`, `S/MIME`, `Extended-certificate`, and `Issuer Serial Number` OIDs. The prior version threw an error but in this refactor they are treated as an "unknown OID" and only throw a debug warning. This was addressed in https://bugs.openjdk.org/browse/JDK-8011867 but prior to this refactor the aforementioned OIDs were treated differently than unknown OIDs. The map is definitely simpler to read than the original arrays. I wonder if we can further enhance the two big `switch`. Ideally, the info for object type and encoding are already described in `AttributeInfo` and all the conversion between object and encoding should be able to be deduced from them. Or, if the info is still not enough, maybe we can add two lambdas to each `AttributeInfo` which is for decoding and encoding, separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17132#issuecomment-1866698656 From rriggs at openjdk.org Thu Dec 21 21:49:55 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 21 Dec 2023 21:49:55 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v10] In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 09:53:10 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Corrected @Label of event and of field. src/java.base/share/classes/java/io/ObjectStreamClass.java line 466: > 464: > 465: if (SerializationMisdeclarationEvent.enabled() && serializable) { > 466: new SerializationMisdeclarationChecker(cl).checkMisdeclarations(); Is there any benefit to avoiding the allocation and passing the class through the methods as an extra arg? src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 149: > 147: if (!(spf instanceof ObjectStreamField[])) { > 148: commitEvent(SERIAL_PERSISTENT_FIELDS_NAME + > 149: " must be an instance of ObjectStreamField[] to be effective"); Hmmm... The terminology "to be effective" seems a bit indirect and may lead to some head scratching. In most cases it means it is ignored. I might suggest to just state the condition that is required and drop the extra phrase. For example, "xxx should be an instance of ObjectStreamField[]". It would result in shorter messages and if further explanation of the message is needed it can more completely elaborate on the impact of the incorrect declaration. src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java line 165: > 163: commitEvent("method " + m + " on an enum class is not effective"); > 164: } else if (cl.isRecord()) { > 165: commitEvent("method " + m + " on an record class is not effective"); "an record" -> "a record" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1434524764 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1434512690 PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1434513714 From rgiulietti at openjdk.org Thu Dec 21 22:27:09 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 21 Dec 2023 22:27:09 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v11] In-Reply-To: References: Message-ID: <71dcKEKrAclcdZ8eYRsC0RZzlVT_Yg7hej-NSMrY1to=.d5c7901c-78d1-4476-a67d-9e8df58d611d@github.com> > Adds serialization misdeclaration events to JFR. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Simplified event messages. Remove ckecker allocation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17129/files - new: https://git.openjdk.org/jdk/pull/17129/files/9cb25a12..91523c67 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=09-10 Stats: 82 lines in 2 files changed: 7 ins; 19 del; 56 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129 From rgiulietti at openjdk.org Thu Dec 21 22:27:10 2023 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 21 Dec 2023 22:27:10 GMT Subject: RFR: 8275338: Add JFR events for notable serialization situations [v10] In-Reply-To: References: Message-ID: On Thu, 21 Dec 2023 21:24:43 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected @Label of event and of field. > > src/java.base/share/classes/java/io/ObjectStreamClass.java line 466: > >> 464: >> 465: if (SerializationMisdeclarationEvent.enabled() && serializable) { >> 466: new SerializationMisdeclarationChecker(cl).checkMisdeclarations(); > > Is there any benefit to avoiding the allocation and passing the class through the methods as an extra arg? The allocation has been removed and the event messages have been simplified in the most recent commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17129#discussion_r1434558624 From duke at openjdk.org Fri Dec 22 04:25:56 2023 From: duke at openjdk.org (duke) Date: Fri, 22 Dec 2023 04:25:56 GMT Subject: Withdrawn: 8318486: Rename JavaLangAccess.xxNoRepl to xxReportError In-Reply-To: References: Message-ID: On Thu, 19 Oct 2023 07:04:50 GMT, Chen Liang wrote: > Please review a patch that renames `JavaLangAccess::xxNoRepl` to `xxReportError` to explicitly indicate these APIs report encoding errors. > > The old "NoRepl" suffix presumably means "No Replacement", but it has been misunderstood as "No Replication" (#16209) and misused as an array sharing API in performance optimization patches. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16260 From jjiang at openjdk.org Mon Dec 25 09:36:15 2023 From: jjiang at openjdk.org (John Jiang) Date: Mon, 25 Dec 2023 09:36:15 GMT Subject: RFR: 8322734: A redundant return in PKCS5Padding Message-ID: It looks the `return` in method `PKCS5Padding::padWithLen` is redundant. ------------- Commit messages: - 8322734: A redundant return in PKCS5Padding Changes: https://git.openjdk.org/jdk/pull/17189/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17189&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322734 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17189.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17189/head:pull/17189 PR: https://git.openjdk.org/jdk/pull/17189 From jiefu at openjdk.org Mon Dec 25 09:45:49 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 25 Dec 2023 09:45:49 GMT Subject: RFR: 8322734: A redundant return in PKCS5Padding In-Reply-To: References: Message-ID: On Mon, 25 Dec 2023 09:30:02 GMT, John Jiang wrote: > It looks the `return` in method `PKCS5Padding::padWithLen` is redundant. I see the same case in ISO10126Padding.java. Shall we also remove it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17189#issuecomment-1868892682 From jjiang at openjdk.org Mon Dec 25 10:54:54 2023 From: jjiang at openjdk.org (John Jiang) Date: Mon, 25 Dec 2023 10:54:54 GMT Subject: RFR: 8322734: A redundant return in method padWithLen [v2] In-Reply-To: References: Message-ID: > It looks the `return`s in the methods `PKCS5Padding::padWithLen` and `ISO10126Padding::padWithLen` are redundant. John Jiang has updated the pull request incrementally with one additional commit since the last revision: Remove return from ISO10126Padding::padWithLen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17189/files - new: https://git.openjdk.org/jdk/pull/17189/files/4c402ac5..9e3c07cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17189&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17189&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17189.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17189/head:pull/17189 PR: https://git.openjdk.org/jdk/pull/17189 From jiefu at openjdk.org Mon Dec 25 12:11:49 2023 From: jiefu at openjdk.org (Jie Fu) Date: Mon, 25 Dec 2023 12:11:49 GMT Subject: RFR: 8322734: A redundant return in method padWithLen [v2] In-Reply-To: References: Message-ID: <4ZZaoaWklY2fqX2WfcxDs4K3ZDSYx-8grOZSSsKD08M=.288bf9f4-6c42-42ef-a07f-8d47add95fb1@github.com> On Mon, 25 Dec 2023 10:54:54 GMT, John Jiang wrote: >> It looks the `return`s in the methods `PKCS5Padding::padWithLen` and `ISO10126Padding::padWithLen` are redundant. > > John Jiang has updated the pull request incrementally with one additional commit since the last revision: > > Remove return from ISO10126Padding::padWithLen LGTM ------------- Marked as reviewed by jiefu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17189#pullrequestreview-1795869626 From jjiang at openjdk.org Wed Dec 27 02:34:01 2023 From: jjiang at openjdk.org (John Jiang) Date: Wed, 27 Dec 2023 02:34:01 GMT Subject: RFR: 8322734: A redundant return in method padWithLen In-Reply-To: References: Message-ID: On Mon, 25 Dec 2023 09:42:36 GMT, Jie Fu wrote: >> It looks the `return`s in the methods `PKCS5Padding::padWithLen` and `ISO10126Padding::padWithLen` are redundant. > > I see the same case in ISO10126Padding.java. > Shall we also remove it? @DamonFool Thanks for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/17189#issuecomment-1869889979 From jjiang at openjdk.org Wed Dec 27 02:34:01 2023 From: jjiang at openjdk.org (John Jiang) Date: Wed, 27 Dec 2023 02:34:01 GMT Subject: Integrated: 8322734: A redundant return in method padWithLen In-Reply-To: References: Message-ID: On Mon, 25 Dec 2023 09:30:02 GMT, John Jiang wrote: > It looks the `return`s in the methods `PKCS5Padding::padWithLen` and `ISO10126Padding::padWithLen` are redundant. This pull request has now been integrated. Changeset: 2a59243c Author: John Jiang URL: https://git.openjdk.org/jdk/commit/2a59243cbaf3e7d5d1bfc9f247d28bc648687ea5 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod 8322734: A redundant return in method padWithLen Reviewed-by: jiefu ------------- PR: https://git.openjdk.org/jdk/pull/17189 From jjiang at openjdk.org Fri Dec 29 06:53:59 2023 From: jjiang at openjdk.org (John Jiang) Date: Fri, 29 Dec 2023 06:53:59 GMT Subject: RFR: 8322766: Micro bench SSLHandshake would use modern algorithms Message-ID: test/micro/org/openjdk/bench/java/security/SSLHandshake.java is using keystore type `JKS` and TrustManagerFactory/KeyManagerFactory algorithm `SunX509`. It may be better to use `PKCS12` and `PKIX` respectively. ------------- Commit messages: - 8322766: Micro bench SSLHandshake would use modern algorithms Changes: https://git.openjdk.org/jdk/pull/17202/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322766 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17202/head:pull/17202 PR: https://git.openjdk.org/jdk/pull/17202 From djelinski at openjdk.org Fri Dec 29 19:16:50 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 29 Dec 2023 19:16:50 GMT Subject: RFR: 8322766: Micro bench SSLHandshake would use modern algorithms In-Reply-To: References: Message-ID: <217_Wed2TnzmIEk4DXnrryUw8KDcLjP5Xx83_Lcauhc=.f2997ae9-1c2e-4cb7-9f73-b3219ff58c7b@github.com> On Fri, 29 Dec 2023 06:49:26 GMT, John Jiang wrote: > test/micro/org/openjdk/bench/java/security/SSLHandshake.java is using keystore type `JKS` and TrustManagerFactory/KeyManagerFactory algorithm `SunX509`. > It may be better to use `PKCS12` and `PKIX` respectively. Could you change to getDefaultAlgorithm / getDefaultType instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17202#issuecomment-1872286018 From jjiang at openjdk.org Sat Dec 30 00:48:00 2023 From: jjiang at openjdk.org (John Jiang) Date: Sat, 30 Dec 2023 00:48:00 GMT Subject: RFR: 8322766: Micro bench SSLHandshake would use modern algorithms [v2] In-Reply-To: References: Message-ID: > test/micro/org/openjdk/bench/java/security/SSLHandshake.java is using keystore type `JKS` and TrustManagerFactory/KeyManagerFactory algorithm `SunX509`. > It may be better to use `PKCS12` and `PKIX` respectively. John Jiang has updated the pull request incrementally with one additional commit since the last revision: Use default algorithms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/17202/files - new: https://git.openjdk.org/jdk/pull/17202/files/56404fff..b0c2fcc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=17202&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=17202&range=00-01 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/17202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17202/head:pull/17202 PR: https://git.openjdk.org/jdk/pull/17202 From jjiang at openjdk.org Sat Dec 30 00:51:46 2023 From: jjiang at openjdk.org (John Jiang) Date: Sat, 30 Dec 2023 00:51:46 GMT Subject: RFR: 8322766: Micro bench SSLHandshake would use modern algorithms In-Reply-To: <217_Wed2TnzmIEk4DXnrryUw8KDcLjP5Xx83_Lcauhc=.f2997ae9-1c2e-4cb7-9f73-b3219ff58c7b@github.com> References: <217_Wed2TnzmIEk4DXnrryUw8KDcLjP5Xx83_Lcauhc=.f2997ae9-1c2e-4cb7-9f73-b3219ff58c7b@github.com> Message-ID: On Fri, 29 Dec 2023 19:13:57 GMT, Daniel Jeli?ski wrote: >> test/micro/org/openjdk/bench/java/security/SSLHandshake.java is using keystore type `JKS` and TrustManagerFactory/KeyManagerFactory algorithm `SunX509`. >> It may be better to use `PKCS12` and `PKIX` respectively. > > Could you change to getDefaultAlgorithm / getDefaultType instead? @djelinski I just used the default type/algorithm instead, though the default `KeyManager` is `SunX509` but not `PKIX`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17202#issuecomment-1872409622 From djelinski at openjdk.org Sat Dec 30 09:23:53 2023 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Sat, 30 Dec 2023 09:23:53 GMT Subject: RFR: 8322766: Micro bench SSLHandshake would use modern algorithms [v2] In-Reply-To: References: Message-ID: On Sat, 30 Dec 2023 00:48:00 GMT, John Jiang wrote: >> test/micro/org/openjdk/bench/java/security/SSLHandshake.java is using keystore type `JKS` and TrustManagerFactory/KeyManagerFactory algorithm `SunX509`. >> It may be better to use `PKCS12` and `PKIX` respectively. > > John Jiang has updated the pull request incrementally with one additional commit since the last revision: > > Use default algorithms Thanks. Users usually use the default algorithms, so benchmarking them is probably more useful than measuring the non-default ones. There's a [ticket to update the default keyManager algorithm](https://bugs.openjdk.org/browse/JDK-8272875), so it may become the default one day. Did you compare the performance of the different algorithms? ------------- PR Comment: https://git.openjdk.org/jdk/pull/17202#issuecomment-1872490605 From jjiang at openjdk.org Sat Dec 30 12:13:45 2023 From: jjiang at openjdk.org (John Jiang) Date: Sat, 30 Dec 2023 12:13:45 GMT Subject: RFR: 8322766: Micro bench SSLHandshake would use modern algorithms [v2] In-Reply-To: References: Message-ID: On Sat, 30 Dec 2023 09:20:59 GMT, Daniel Jeli?ski wrote: > Users usually use the default algorithms, so benchmarking them is probably more useful than measuring the non-default ones. I see. > There's a [ticket to update the default keyManager algorithm](https://bugs.openjdk.org/browse/JDK-8272875), so it may become the default one day. Thanks for this info! > Did you compare the performance of the different algorithms? I found the performance of using PKCS12 keystore and PKIX key manager in TLS full handshaking is much slower. Already filed [JDK-8322767] for it. [JDK-8322767]: https://bugs.openjdk.org/browse/JDK-8322767 ------------- PR Comment: https://git.openjdk.org/jdk/pull/17202#issuecomment-1872516192