8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped

[GoeLin]

I backport this for parity with 17.0.21-oracle from 25.

Resolved one copyright, probably clean anyways.

---

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8368694 needs maintainer approval

Issue

• JDK-8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped (Bug - P4 - Approved)

Reviewers

• Andrew John Hughes (@gnu-andrew - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4617

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

[openjdk]

@GoeLin 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:

8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped

Reviewed-by: andrew

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

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

• a891cf0: 8390327: [17u] test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java fails to compile in Java 17 after JDK-8343855 backport
• 71d0531: 8301793: AlgorithmId should not encode a missing parameters field as NULL unless hardcoded
• ab7da9d: 8365776: Convert JShell tests to use JUnit instead of TestNG
• ... and 1 more: https://git.openjdk.org/jdk17u-dev/compare/ac6ec6d49ad936124b00fb8198d02861eb5d815a...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.

[openjdk]

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

[mlbridge]

Webrevs

• 02: Full - Incremental (f1adf25b)
• 01: Full - Incremental (ff38fa48)
• 00: Full (43ede693)

[gnu-andrew]

Dropped approval for this one until it is in its final form against master.

[gnu-andrew]

This still contains the changes removed in #4616

[GoeLin]

Hi @gnu-andrew
Sorry, that's the downside of dependent PRs, they require a merge, and this makes these errors. Thanks for catching this!

[GoeLin]

HI @gnu-andrew
Is this now fine to go? Could you please approve it? Thanks!

[gnu-andrew]

Confirmed clean now.

[gnu-andrew]

Hi @gnu-andrew Sorry, that's the downside of dependent PRs, they require a merge, and this makes these errors. Thanks for catching this!

Yes, I am always in two minds about whether to use them. They are mostly useful to the developer rather than the reviewers, and pretty much a must have if you need to make sure something works in GHA after multiple PRs (e.g. when we were moving 8u to a newer MacOS). I try to restrict them to these cases, or when a backport doesn't really make sense without being able to point to the one that depends on it (e.g. openjdk/jdk25u-dev#756 and openjdk/jdk25u-dev#757 that I just did myself).

FWIW, I do a rebase after it moves back to master, despite Skara's moans. Git is intelligent enough to match the upstream commit with the local one and just drop it, rather than trying to merge all the changes on top of themselves. This situation is only created in the first place because Skara rebases commits before pushing and thus changes the commit ID.

I removed the approval for this reason. Sorry for not getting back to it earlier this week, but I had to chase changes for the upcoming RHEL releases yesterday.

/approve yes

[openjdk]

@gnu-andrew
8368694: The approval request has been approved.

[GoeLin]

Thanks for the approval!

[GoeLin]

/integrate

[openjdk]

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

• a891cf0: 8390327: [17u] test/jdk/java/net/httpclient/lib/jdk/httpclient/test/lib/common/HttpServerAdapters.java fails to compile in Java 17 after JDK-8343855 backport
• 71d0531: 8301793: AlgorithmId should not encode a missing parameters field as NULL unless hardcoded
• ab7da9d: 8365776: Convert JShell tests to use JUnit instead of TestNG
• ... and 1 more: https://git.openjdk.org/jdk17u-dev/compare/ac6ec6d49ad936124b00fb8198d02861eb5d815a...master

Your commit was automatically rebased without conflicts.

[openjdk]

@GoeLin Pushed as commit 1467219.

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