8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts

[alexeybakhtin]

Hello, I'd like to backport JDK-8179502 to JDK17u to improve the timeout adjustment for OCSP GET requests (which was missed in JDK-8179503).

The backport is almost clean except for the following:

• OCSP.java was merged manually because of JDK-8328638 and JDK-8329213 is already backported into 17u-dev
• copyright year in GetPropertyAction.java and URICertStore.java files are updated manually
• CRLReadTimeout.java test is updated manually because of the different notation of internal X509CRLImpl and CRLExtensions classes.

All new and related jtreg tests are passed

---

Progress

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

Issues

• JDK-8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts (Enhancement - P4 - Requested)
• JDK-8345114: Enhance OCSP, CRL and Certificate Fetch Timeouts (CSR)

Reviewers

• Yuri Nesterenko (@yan-too - Reviewer) 🔄 Re-review required (review applies to df460a63)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk17u-dev.git pull/2747/head:pull/2747
$ git checkout pull/2747

Update a local copy of the PR:
$ git checkout pull/2747
$ git pull https://git.openjdk.org/jdk17u-dev.git pull/2747/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2747

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk17u-dev/pull/2747.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back abakhtin! 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]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[openjdk]

At least one of the issues associated with this backport has a resolved CSR for a different version. As this means that this backport may also need a CSR, the csr label is being added to this pull request to signal this potential requirement. The command /csr unneeded can be used to remove the label in case a CSR is not needed.

[mlbridge]

Webrevs

• 02: Full - Incremental (65e02f91)
• 01: Full - Incremental (e73f8c1a)
• 00: Full (df460a63)

[alexeybakhtin]

CSR JDK-8337407 for JDK17 is created

[bridgekeeper]

@alexeybakhtin 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!

[HempushpaSahu]

Hi @alexeybakhtin
Is there any plan to merge this PR anytime soon?

Thanks.

[alexeybakhtin]

Hi @HempushpaSahu. Yes, I will request integration into 17u as soon as it is reviewed here.

[HempushpaSahu]

Hi @alexeybakhtin,
I noticed from JDK-8337407 issue, jnimeh is the reviewer.
Could you please confirm whether the review is currently in progress?
Also, is it possible to assign an additional reviewer if one is available?

Thanks.

[alexeybakhtin]

Hello everyone,
Could you please review the backport? I want to backport it for parity with Oracle.

[HempushpaSahu]

Hi,
Since there is multiple follow-ups for this PR and customer is awaiting the fix, could someone please provide an update on the review status?

Thanks.

[HempushpaSahu]

Hi,
Could someone please review the PR?

Thanks.

[HempushpaSahu]

Hi @jnimeh ,
Could you please assist with reviewing the PR or if you are occupied with other tasks please tag the appropriate person who can help us to review?
The customer is waiting for the fix. Once this backport is merged, they will be able to move forward.

Thanks.

[jnimeh]

Hello @HempushpaSahu. I can review the CSR. I think you need someone who has reviewer status in the jdk-updates project in order to be able to commit this. I only have committer status there. You should be able to find many folks with jdk-updates reviewer status on the OpenJDK census page though.

[jnimeh]

I would also suggest looking at incorporating JDK-8309740 and JDK-8309754 in follow-on integrations as they pertain to the tests in this PR.

[HempushpaSahu]

Hi @seanjmullan ,
Could you please help us here to review the PR?

[HempushpaSahu]

Hello @HempushpaSahu. I can review the CSR. I think you need someone who has reviewer status in the jdk-updates project in order to be able to commit this. I only have committer status there. You should be able to find many folks with jdk-updates reviewer status on the OpenJDK census page though.

Thanks @jnimeh for your inputs.

[HempushpaSahu]

Hi @GoeLin
Could you please help to review this PR or tag the appropriate person who can help us to review?
Thanks.

[HempushpaSahu]

Hi @GoeLin
Could you please help to review this PR?
Thanks.

[HempushpaSahu]

Hi @alexeybakhtin,
JDK-8337407 issue has some activity in last week.
Could you please confirm whether the review is currently in progress?

Thanks.

[alexeybakhtin]

CSR is approved.
Please review the PR.

[openjdk]

⚠️ @alexeybakhtin This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[jerboaa]

Pasting @GoeLin's question from #2754 here:

What happens if someone has set com.sun.security.crl.timeout and installs the update. Will that value be taken over to com.sun.security.ocsp.readtimeout, or will that fall back to 15s?

[alexeybakhtin]

Pasting @GoeLin's question from #2754 here:

What happens if someone has set com.sun.security.crl.timeout and installs the update. Will that value be taken over to com.sun.security.ocsp.readtimeout, or will that fall back to 15s?

Hi @GoeLin, you are right. The new "com.sun.security.ocsp.readtimeout" property is set independently of "com.sun.security.crl.timeout". In your case, it will fall back to the default 15s value. It changes current behavior.
I can update this logic to change the default read timeout to the "com.sun.security.crl.timeout" value.

[franferrax]

Hi @alexeybakhtin and @GoeLin,

After e73f8c1, DEFAULT_READ_TIMEOUT is now unused and can be removed.

Apparently, this backward-compatibility problem went undetected in the original change. Please also note that the behavior is no longer aligned with the CSR (emphasis by me):

For all properties, existing and new, the proposed expanded syntax will conform to the following:

• […]
• As with the current behavior, non-numeric, non-decimal (e.g. hexadecimal values prepended by "0x", etc) values will be interpreted as illegal and will default to the 15 second timeout. The same is true for negative values.

com.sun.security.ocsp.readtimeout is now an exceptional case, it won't default to the 15 seconds timeout, but to com.sun.security.ocsp.timeout (which defaults to 15 seconds).

Should the CSR be adjusted? Otherwise, how do we ensure Oracle's backport behaves the same way? I don't have enough backporting experience, is it usually accepted to diverge from newer releases (≥ 21u) in a backport CSR?

[alexeybakhtin]

Hi @franferrax
Thank you for the finding. I'll remove DEFAULT_READ_TIMEOUT
You are right, the CSR for update releases should be updated for com.sun.security.ocsp.readtimeout default value. I'll do it and ask you to review it from an engineering point of view.
I hope in this way, without backward compatibility, the patch will be accepted.

[franferrax]

I will take a look, but please note I'm not a Reviewer.

One more comment, I see that the following issues are not part of the backport. Although all of them are test-only changes (mostly tuning the timeout), we might also want to include these to avoid some instability.

• JDK-8309740, openjdk/jdk@5ca4cdd
• JDK-8310629, openjdk/jdk@b20dc1e
• JDK-8325024, openjdk/jdk@432756b
• JDK-8337826, openjdk/jdk@9b11bd7

The last one is an ongoing effort to try to fix JDK-8309754, so we could alternatively wait for that fix and then make all the 5 backports together.

[alexeybakhtin]

Backport PRs are created for test fixes

[HempushpaSahu]

Hi @alexeybakhtin , I have tested the four backports mentioned above together, and they have passed successfully. Should we include these tests as part of the PR?
Thanks.

[alexeybakhtin]

@franferrax , @HempushpaSahu, Thank you!
I do not think it is possible to add other bug fixes to this PR, so I submitted dependent backport PRs for the mentioned test fixes:

• JDK-8309740, openjdk/jdk@5ca4cdd
• JDK-8310629, openjdk/jdk@b20dc1e
• JDK-8325024, openjdk/jdk@432756b
• JDK-8337826, openjdk/jdk@9b11bd7

Backports are clean, so no review is required

[franferrax]

Hi @alexeybakhtin, thank you for the additional time and effort put into this! My intention is to help move things faster, because I've been made aware about customers waiting for this.

However, as @GoeLin explained, if Oracle doesn't include this backport in 17.0.14, the documentation won't be updated, so we'll need to wait for them to proceed. Apparently, Oracle's reason for not doing the backport is its low priority. Customers are now trying to get it prioritized through Oracle support, but it looks like we won't make it for the 17.0.14 rampdown date (December 3).

NOTE: FYI, AFAIK, you can add multiple backports to a pull requiest with the /issue add <id>[,<id>,...] command.

[alexeybakhtin]

Hi @franferrax,
Thank you for your support.
We also have customers who are waiting for this enhancement.

About /issue command - I do not like this approach much. It will bring a much more difference between the backport and the original fix. Right now, all test fixes are applied cleanly. But, if it would help to integrate this enhancement, I can combine all follow-up backports into this one.