8311596: Add separate system properties for TLS server and client for maximum chain length #15163

haimaychao · 2023-08-04T17:30:06Z

Please review the enhancement for JDK-8311596 and its CSR JDK-8313236. Thank you.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue
Change requires CSR request JDK-8313236 to be approved

Issues

JDK-8311596: Add separate system properties for TLS server and client for maximum chain length (Enhancement - P3)
JDK-8313236: Add separate system properties for TLS server and client for maximum chain length (CSR)

Reviewers

Jamil Nimeh (@jnimeh - Reviewer) ⚠️ Review applies to e8174347
Weijun Wang (@wangweij - Reviewer) ⚠️ Review applies to b3192df3
Sean Mullan (@seanjmullan - Reviewer) ⚠️ Review applies to b3192df3

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15163/head:pull/15163
$ git checkout pull/15163

Update a local copy of the PR:
$ git checkout pull/15163
$ git pull https://git.openjdk.org/jdk.git pull/15163/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 15163

View PR using the GUI difftool:
$ git pr show -t 15163

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15163.diff

Webrev

Link to Webrev Comment

… maximum chain length

haimaychao · 2023-08-04T17:30:15Z

/csr

bridgekeeper · 2023-08-04T17:31:14Z

👋 Welcome back hchao! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2023-08-04T17:32:57Z

@haimaychao has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@haimaychao please create a CSR request for issue JDK-8311596 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

openjdk · 2023-08-04T17:33:55Z

@haimaychao The following label will be automatically applied to this pull request:

security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2023-08-04T17:37:40Z

Webrevs

mcpowers

All of the other changes look fine to me.
Does this need a test?

mcpowers · 2023-08-07T15:36:54Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

@@ -112,6 +112,12 @@ final class SSLConfiguration implements Cloneable {
    static final int maxCertificateChainLength = GetIntegerAction.privilegedGetProperty(
            "jdk.tls.maxCertificateChainLength", 10);

+    // Limit the maximum certificate chain length accepted from clients


Should these be moved to after line 89?

Remain to stay after the related maxCertificateChainLength.

mcpowers · 2023-08-07T15:48:08Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

+     * system property.
+     */
+    static {
+        Integer clientLen = GetIntegerAction.privilegedGetProperty(


I think you could call privilegedGetProperty with the default value as second argument.

If I'm looking at the latest version, I don't see @mcpowers suggestion implemented. He's suggesting using the method with this signature:

public static String privilegedGetProperty(String theProp, String defaultVal)

I did update the code with his suggestion, and please see it in webrev 01: Incremental. However, I further change the code based on the updated CSR, that the new client and server properties have different default values now from the existing property, and the need to know whether the new property is explicitly set or not. We want to make sure the new properties are not overridden when they are set.

jnimeh · 2023-08-07T17:23:11Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

+                "jdk.tls.maxServerCertificateChainLength");
+        maxServerCertificateChainLength = (serverLen != null) ?
+                serverLen : maxCertificateChainLength;
+    }


I wonder if we should take the opportunity here with these new properties as well as jdk.tls.maxCertificateChainLength to also equate negative numbers (and maybe zero) to be the default. Right now only property values that fail the internal parseInt conversion will evaluate to null and would be assigned the default I think. But a negative value I think would be taken as-is from the property. Should a negative max cert chain length get set to the default? If so, it might also make sense to give a warning about the offending value and note that it is being set to the default (similar to what GetPropertyAction.privilegedGetTimeoutProp() does).
If you think this is worthwhile, the CSR should probably be updated to reflect that also.

Change made to set to the default when a negative value is set for these system properties. Updated CSR for this.

bridgekeeper · 2023-09-04T22:34:23Z

@haimaychao This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

jnimeh

This looks good to me. Thanks for making that negative value update.

bridgekeeper · 2023-10-04T20:42:09Z

@haimaychao This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

haimaychao · 2023-10-12T20:21:27Z

/open

openjdk · 2023-10-12T20:23:29Z

@haimaychao This pull request is now open

…ted CSR

mcpowers · 2023-10-13T18:02:34Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

+    // Limit the maximum certificate chain length accepted from clients
+    static final int maxClientCertificateChainLength;
+
+    // Limit the maximum certificate chain length accepted from servers


I would drop "maximum" and just say "Limit the certificate chain length accepted from servers". It's not worth making this change unless you have to make another change to this file.

wangweij · 2023-10-13T18:59:44Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

+         * the values.
+         */
+        if (maxCertificateChainLength > 0) {
+            if (clientLen == 8) {


If the user sets "jdk.tls.maxClientCertificateChainLength" precisely to 8 and you will ignore it?

Since 8 is the default for "jdk.tls.maxClientCertificateChainLength", it is going to be overridden when "jdk.tls.maxCertificateChainLength" is set. Setting "jdk.tls.maxClientCertificateChainLength" to 8 is treated as keeping the original default like no-op.

If I understand correctly, "jdk.tls.maxClientCertificateChainLength" is meant to override "jdk.tls.maxClientCertificateChainLength" if both are defined. Then what would happen if user has specified -Djdk.tls.maxClientCertificateChainLength=8 -Djdk.tls.maxCertificateChainLength=4?

jdk.tls.maxCertificateChainLength will only override jdk.tls.maxClientCertificateChainLength if jdk.tls.maxCertificateChainLength is set AND jdk.tls.maxClientCertificateChainLength is using the default. For the case your provided here, jdk.tls.maxClientCertificateChainLength will be overridden to be 4 which is set by jdk.tls.maxCertificateChainLength.

That's not my understanding. Since jdk.tls.maxClientCertificateChainLength is explicitly set on the command line you should honor it.

Yes, I agree that if the application sets jdk.tls.maxClientCertificateChainLength or jdk.tls.maxServerCertificateChainLength, it should always take precedence even if the specified value is the same as the default.

You will need to first see if these properties are set before assigning the default value.

XueleiFan · 2023-10-20T17:19:52Z

I was wondering, if it is easier to learn and remember/search by following the naming style "jdk.tls.client.XXX" or "jdk.tls.server.XXX" in SunJSSE provider?

haimaychao · 2023-10-24T16:34:01Z

@XueleiFan The current properties named jdk.tls.client.* and jdk.tls.server.* apply to settings either on the client or the server, so we'd have to rename the properties here. My suggestion is to:

Change jdk.tls.maxServerCertificateChainLength to jdk.tls.client.maxAcceptedCertificateChainLength
Change jdk.tls.maxClientCertificateChainLength to jdk.tls.server.maxAcceptedCertificateChainLength

Thanks!

XueleiFan · 2023-10-25T17:38:53Z

@XueleiFan The current properties named jdk.tls.client.* and jdk.tls.server.* apply to settings either on the client or the server, so we'd have to rename the properties here. My suggestion is to:

Change jdk.tls.maxServerCertificateChainLength to jdk.tls.client.maxAcceptedCertificateChainLength

Change jdk.tls.maxClientCertificateChainLength to jdk.tls.server.maxAcceptedCertificateChainLength

Thanks!

For the name "jdk.tls.maxServerCertificateChainLength", it is not clear to me which side, client or server, the property should be applied to. It could also mean that server can only send out certification with this limitation.

For the name jdk.tls.client.maxAcceptedCertificateChainLength, it could be confused to parse the word "accepted". It could mean that the accepted cert-chain length for sending out certificates.

Maybe, you can have a try with "jdk.tls.client.maxServerCertificateChainLength", which means for client side, the server certificate chain length (inbound) is limited. Or if you want to simplify the property name, you can have a try for ""jdk.tls.client.maxInboundCertificateChainLength"".

haimaychao · 2023-10-25T18:32:43Z

It sounds good to me that the word "Accepted" is replaced with "Inbound". It should clear out the confusion I think. Thanks for the suggestion.

So how about changing the properties names from:
jdk.tls.maxServerCertificateChainLength --> jdk.tls.client.maxInboundCertificateChainLength
jdk.tls.maxClientCertificateChainLength --> jdk.tls.server.maxInboundCertificateChainLength

openjdk · 2023-10-26T18:58:42Z

@haimaychao This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8311596: Add separate system properties for TLS server and client for maximum chain length

Reviewed-by: jnimeh, weijun, mullan

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 186 new commits pushed to the master branch:

3a7525d: 8309118: HttpClient: Add more tests for 100 ExpectContinue with HTTP/2
f4c5db9: 8318908: Parallel: Remove ExtendedCardValue
7452d50: 8318940: [JVMCI] do not set HotSpotNmethod oop for a default HotSpotNmethod
3e39d7b: 8319136: Skip pkcs11 tests on linux-aarch64
ee6f25b: 8319120: Unbound ScopedValue.get() throws the wrong exception
e05cafd: 8318467: [jmh] tests concurrent.Queues and concurrent.ProducerConsumer hang with 101+ threads
d3c3f0e: 8317951: Refactor loading of zip library to help resolve JDK-8315220
576c9bc: 8318492: Http2ClientImpl should attempt to close and remove connection in stop()
5411ad2: 8319106: Remove unimplemented TaskTerminator::do_delay_step
75ce02f: 8318951: Additional negative value check in JPEG decoding
... and 176 more: https://git.openjdk.org/jdk/compare/9843c97695fab3fec1e319027b14974d0e84bf0a...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

seanjmullan · 2023-10-27T19:45:29Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

-    static final int maxCertificateChainLength = GetIntegerAction.privilegedGetProperty(
-            "jdk.tls.maxCertificateChainLength", 10);
+    // Maximum allowed certificate chain length
+    static final int maxCertificateChainLength;


I think this can just be a local variable now inside the static block.

Good catch. Done.

wangweij · 2023-10-27T20:07:07Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

+        Integer inboundClientLen = GetIntegerAction.privilegedGetProperty(
+                "jdk.tls.server.maxInboundCertificateChainLength");
+        if (inboundClientLen == null || inboundClientLen < 0) {
+            inboundClientLen = 8;


The logic is little too long for me to digest. I wonder if we can just rewrite the line above to

inboundClientLen = globalPropSet ? maxCertificateChainLength : 8;

then there is no need for serverPropSet and clientPropSet.

Hmm, but how does this work? The inbound properties override the global property if both are set.

This belongs to the if (inboundClientLen == null || inboundClientLen < 0) side. The else side stays the same.

Precisely, it's

if (inboundServerLen == null || inboundServerLen < 0) { maxInboundClientCertChainLen = globalPropSet ? maxCertificateChainLength : 8;; } else { maxInboundClientCertChainLen = inboundServerLen; }

and nothing else is needed.

Updated as suggested. Changed code to:

if (inboundServerLen == null || inboundServerLen < 0) { maxInboundServerCertChainLen = globalPropSet ? maxCertificateChainLength : 10; } else { maxInboundServerCertChainLen = inboundServerLen; }

wangweij · 2023-10-27T20:08:25Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

+        } else {
+            globalPropSet = true;
+        }
+        maxCertificateChainLength = certLen;


There is no need to set certLen or maxCertificateChainLength when globalPropSet is false.

Removed them.

wangweij · 2023-10-27T20:17:15Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

+         * set. That means if either of those properties have been set,
+         * the jdk.tls.maxCertificateChainLength property will not override
+         * the values.
+         */


English is not my native language, but I have some comment on the wording. Normally we don't say maxCertificateChainLength overrides maxInboundCertificateChainLength. In fact, it is maxInboundCertificateChainLength that overrides maxCertificateChainLength. When maxInboundCertificateChainLength is not set, it fallbacks to maxCertificateChainLength (if set) or a default value (8).

I agree that wording is more clear. We should also update the RN with that wording.

This section of comments was taken from the CSR. I updated the comments as follows. If it looks fine, I will update the related doc. Thanks!

/* * If either jdk.tls.server.maxInboundCertificateChainLength or * jdk.tls.client.maxInboundCertificateChainLength is set, it will * override jdk.tls.maxCertificateChainLength, regardless of whether * jdk.tls.maxCertificateChainLength is set or not. * If neither jdk.tls.server.maxInboundCertificateChainLength nor * jdk.tls.client.maxInboundCertificateChainLength is set, the behavior * depends on the setting of jdk.tls.maxCertificateChainLength. If * jdk.tls.maxCertificateChainLength is set, it falls back to that * value; otherwise, it defaults to 8 for * jdk.tls.server.maxInboundCertificateChainLength * and 10 for jdk.tls.client.maxInboundCertificateChainLength. * Usesrs can independently set either * jdk.tls.server.maxInboundCertificateChainLength or * jdk.tls.client.maxInboundCertificateChainLength. */

Sorry, I did not get time to review this behavior update.

This section of comments was taken from the CSR. I updated the comments as follows. If it looks fine, I will update the related doc. Thanks!

/* * If either jdk.tls.server.maxInboundCertificateChainLength or * jdk.tls.client.maxInboundCertificateChainLength is set, it will * override jdk.tls.maxCertificateChainLength, regardless of whether * jdk.tls.maxCertificateChainLength is set or not.

I'm not sure the statement is clear enough. I think there are two points that need to clarify. The 1st one is that there is a default value of jdk.tls.maxCertificateChainLength, which is 10. The 2nd one is that jdk.tls.maxCertificateChainLength works for both client and server mode. jdk.tls.server.maxInboundCertificateChainLength works on server mode, and it does not work for client mode, and therefore it cannot override client mode behavior for jdk.tls.maxCertificateChainLength. The same for jdk.tls.client.maxInboundCertificateChainLength.

To be clear, the release note or the comment might be placed in different code block like:

/* If jdk.tls.server.maxInboundCertificateChainLength is set, it will override jdk.tls.maxCertificateChainLength behavior for server side. */ Integer inboundClientLen = ... /* If jdk.tls.client.maxInboundCertificateChainLength is set, it will override jdk.tls.maxCertificateChainLength behavior for client side. */ Integer inboundServerLen = GetIntegerAction.privilegedGetProperty(

* If neither jdk.tls.server.maxInboundCertificateChainLength nor * jdk.tls.client.maxInboundCertificateChainLength is set, the behavior * depends on the setting of jdk.tls.maxCertificateChainLength. If * jdk.tls.maxCertificateChainLength is set, it falls back to that * value; otherwise, it defaults to 8 for * jdk.tls.server.maxInboundCertificateChainLength

Previously, the jdk.tls.maxCertificateChainLength default value is 10. Now it is changed to 8. This is a behavior change, please document it in release note, or just use 10 in the implementation.

* and 10 for jdk.tls.client.maxInboundCertificateChainLength. * Usesrs can independently set either * jdk.tls.server.maxInboundCertificateChainLength or * jdk.tls.client.maxInboundCertificateChainLength. */

I don't see a behavior change that conflicts with the CSR. I think it is a wording issue, let me suggest some improvements in another comment. There is no longer a default value for jdk.tls.maxCertificateChainLength. Where is it set to 8 in the code?

The choice of 8 for the client is mostly based on different processing requirements and use cases for TLS client vs server certificate chains. If we see evidence that 8 is too low, we can always consider adjusting it.

I'm not sure if the number 8 or 10 really make a good difference in practice. No matter 8 or 10, if customers need lower value, they can always consider adjusting it. My concern is mainly about compatibility issues. If you want to keep the behavior changes, as there is potential compatibility issue, please feel free to describe the behavior change in release note and CSR if you would like.

Good point - the CSR and RN could have been a bit more specific about the compatibility effect of changing the default from 10 to 8, so we will update that. Note that the CertPathBuilder default max path length is 5 non-self-issued intermediate CA certificates, so even a lower value of 8 should have low risk as rigid TLS cert chains greater than 6 certs (where the 6th cert is the end entity cert which is not affected by the CertPathBuilder limit) on the wire will already be rejected. The additional certs permitted in the wire format is more for including a few more additional certs that might help build a valid path when there is more than one possible chain that a server or client might accept, which sometimes happens.

Good point about the setMaxPathLength() limitation. It looks like there might be an issue when the interactivities of setMaxPathLength(and its default value) and the properties defined here are not considered. For example, what if the property is set to 8, while the setMaxPathLength is of value 5? For the "PKIX" trust manager, per your description, if the property is set to 8, but 5 is the limit actually. It looks like a weird behavior to me. If I remember correctly, the "SunX509" trust manager does not use PKIXBuilderParameters, while the "PKIX" trust manager does. It might be not the behavior we'd like to have that property 8 work for "SunX509" but not for "PKIX" trust manager.

Anyway, it might be better to look into the interactive behaviors among the properties and setMaxPathLength/default value.

Good point - the CSR and RN could have been a bit more specific about the compatibility effect of changing the default from 10 to 8, so we will update that. Note that the CertPathBuilder default max path length is 5 non-self-issued intermediate CA certificates, so even a lower value of 8 should have low risk as rigid TLS cert chains greater than 6 certs (where the 6th cert is the end entity cert which is not affected by the CertPathBuilder limit) on the wire will already be rejected. The additional certs permitted in the wire format is more for including a few more additional certs that might help build a valid path when there is more than one possible chain that a server or client might accept, which sometimes happens.

PKIX has been the default SunJSSE TrustManager since JDK 5 and AFAIK we have not had any reports of compatibility issues. This leads me to believe that valid TLS chains longer than 6 certificates are extremely rare.

seanjmullan · 2023-10-31T13:26:47Z

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

+         * value; otherwise, it defaults to 8 for
+         * jdk.tls.server.maxInboundCertificateChainLength
+         * and 10 for jdk.tls.client.maxInboundCertificateChainLength.
+         * Usesrs can independently set either


Typo: s/Usesrs/Users

haimaychao · 2023-10-31T15:14:34Z

Thanks all for the review.

haimaychao · 2023-10-31T15:20:31Z

/integrate

openjdk · 2023-10-31T15:22:21Z

Going to push as commit 0064cf9.
Since your change was applied there have been 186 commits pushed to the master branch:

3a7525d: 8309118: HttpClient: Add more tests for 100 ExpectContinue with HTTP/2
f4c5db9: 8318908: Parallel: Remove ExtendedCardValue
7452d50: 8318940: [JVMCI] do not set HotSpotNmethod oop for a default HotSpotNmethod
3e39d7b: 8319136: Skip pkcs11 tests on linux-aarch64
ee6f25b: 8319120: Unbound ScopedValue.get() throws the wrong exception
e05cafd: 8318467: [jmh] tests concurrent.Queues and concurrent.ProducerConsumer hang with 101+ threads
d3c3f0e: 8317951: Refactor loading of zip library to help resolve JDK-8315220
576c9bc: 8318492: Http2ClientImpl should attempt to close and remove connection in stop()
5411ad2: 8319106: Remove unimplemented TaskTerminator::do_delay_step
75ce02f: 8318951: Additional negative value check in JPEG decoding
... and 176 more: https://git.openjdk.org/jdk/compare/9843c97695fab3fec1e319027b14974d0e84bf0a...master

Your commit was automatically rebased without conflicts.

openjdk · 2023-10-31T15:22:28Z

@haimaychao Pushed as commit 0064cf9.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8311596: Add separate system properties for TLS server and client for…

e13a68f

… maximum chain length

openjdk bot added rfr Pull request is ready for review csr Pull request needs approved CSR before integration labels Aug 4, 2023

openjdk bot added the security security-dev@openjdk.org label Aug 4, 2023

mcpowers reviewed Aug 7, 2023

View reviewed changes

jnimeh reviewed Aug 7, 2023

View reviewed changes

Set to default if a negative value is set

2b91946

jnimeh approved these changes Sep 6, 2023

View reviewed changes

bridgekeeper bot closed this Oct 4, 2023

openjdk bot reopened this Oct 12, 2023

haimaychao added 2 commits October 12, 2023 13:35

Merge

e817434

Change made to configure max allowed cert chain lengths based on upda…

53ae43b

…ted CSR

mcpowers reviewed Oct 13, 2023

View reviewed changes

wangweij reviewed Oct 13, 2023

View reviewed changes

haimaychao added 2 commits October 16, 2023 15:54

Override the client/server defaults

2e264f9

Merge

aca5841

openjdk bot added ready Pull request is ready to be integrated and removed csr Pull request needs approved CSR before integration labels Oct 26, 2023

Change property names to clearly indicate client side and server side

b351b41

seanjmullan reviewed Oct 27, 2023

View reviewed changes

Change maxCertificateChainLength to be a local variable

d9f669f

wangweij reviewed Oct 27, 2023

View reviewed changes

haimaychao added 2 commits October 30, 2023 14:32

Update comments and property process code

31668be

Updated to not longer than 80-chars

b3192df

wangweij approved these changes Oct 30, 2023

View reviewed changes

seanjmullan approved these changes Oct 31, 2023

View reviewed changes

typo fix

83b489b

openjdk bot added the integrated Pull request has been integrated label Oct 31, 2023

openjdk bot closed this Oct 31, 2023

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Oct 31, 2023

8311596: Add separate system properties for TLS server and client for maximum chain length #15163

8311596: Add separate system properties for TLS server and client for maximum chain length #15163

Conversation

haimaychao commented Aug 4, 2023 • edited by openjdk bot Loading

Progress

Issues

Reviewers

Reviewing

Webrev

haimaychao commented Aug 4, 2023

bridgekeeper bot commented Aug 4, 2023

openjdk bot commented Aug 4, 2023

openjdk bot commented Aug 4, 2023

mlbridge bot commented Aug 4, 2023 • edited Loading

Webrevs

mcpowers left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bridgekeeper bot commented Sep 4, 2023

jnimeh left a comment

Choose a reason for hiding this comment

bridgekeeper bot commented Oct 4, 2023

haimaychao commented Oct 12, 2023

openjdk bot commented Oct 12, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wangweij Oct 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seanjmullan Oct 16, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

XueleiFan commented Oct 20, 2023

haimaychao commented Oct 24, 2023

XueleiFan commented Oct 25, 2023 • edited Loading

haimaychao commented Oct 25, 2023

openjdk bot commented Oct 26, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wangweij Oct 27, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seanjmullan Nov 1, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seanjmullan Nov 9, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

haimaychao commented Oct 31, 2023

haimaychao commented Oct 31, 2023

openjdk bot commented Oct 31, 2023

openjdk bot commented Oct 31, 2023

haimaychao commented Aug 4, 2023 •

edited by openjdk bot

Loading

mlbridge bot commented Aug 4, 2023 •

edited

Loading

wangweij Oct 13, 2023 •

edited

Loading

seanjmullan Oct 16, 2023 •

edited

Loading

XueleiFan commented Oct 25, 2023 •

edited

Loading

openjdk bot commented Oct 26, 2023 •

edited

Loading

wangweij Oct 27, 2023 •

edited

Loading

seanjmullan Nov 1, 2023 •

edited

Loading

seanjmullan Nov 9, 2023 •

edited

Loading