8326447: jpackage creates Windows installers that cannot be signed

[alexeysemenyukoracle]

Support the use of a custom msi wrapper executable when building an exe installer.

Put installer.exe file in the resource directory and jpackage will use it instead of the default msiwrapper.exe resource for exe installer.

To test this feature created a test that builds exe installer with a custom icon. The result installer exe is used as a custom msi wrapper executable in the second jpackage command that builds exe installer with the default icon. The installer exe produced by the second jackage command should have the same icon as the exe installer created in the first jpackage run.

Moved code verifying icons in executables from LauncherIconVerifier.WinIconVerifier class into WinExecutableIconVerifier class to make it available for tests. Replaced inline powershell script extracting icons from executables with standalone read-executable-icon.ps1 powershell script. The script uses ExtractIcon instead of ExtractAssociatedIcon. It extracts icon from the executable's resources and will not fall back to anything if there is no icon resource.

---

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

Warning

 ⚠️ Found leading lowercase letter in issue title for 8326447: jpackage creates Windows installers that cannot be signed

Issue

• JDK-8326447: jpackage creates Windows installers that cannot be signed (Bug - P3)

Reviewers

• Alexander Matveev (@sashamatveev - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 23732

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

8326447: jpackage creates Windows installers that cannot be signed

Reviewed-by: almatvee

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 15 new commits pushed to the master branch:

• 65f79c1: 8347335: ZGC: Use limitless mark stack memory
• e410af0: 8342393: Promote commutative vector IR node sharing
• f755fad: 8349653: Clarify the docs for MemorySegment::reinterpret
• a5c9a4d: 8349032: C2: Parse Predicate refactoring in Loop Unswitching broke fix for JDK-8290850
• 302bed0: 8350499: Minimal build fails with slowdebug builds
• 0795d11: 8350464: The flags to set the native priority for the VMThread and Java threads need a broader range
• 05b4812: 8350041: Skip test/jdk/java/lang/String/nativeEncoding/StringPlatformChars.java on static JDK
• a891630: 8350480: RISC-V: Relax assertion about registers in C2_MacroAssembler::minmax_fp
• 5cbd9d1: 8349959: Test CR6740048.java passes unexpectedly missing CR6740048.xsd
• 25322aa: 8350258: AArch64: Client build fails after JDK-8347917
• ... and 5 more: https://git.openjdk.org/jdk/compare/dfcd0df60c60cf89dc01682264a573ad39e61a17...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]

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

• core-libs

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]

Webrevs

• 02: Full - Incremental (d5827daa)
• 01: Full - Incremental (31ebde0c)
• 00: Full (32a8a696)

[alexeysemenyukoracle]

@sashamatveev PTAL

[sashamatveev]

How user should figure out what installer.exe suppose to do? Should user just take it from another JDK which works? It does not look like a solution to this issue.

[sashamatveev]

Can we add test which will use SignTool to sign produced .exe installer? This test can be similar to our macOS signing tests which require additional system configuration.

[alexeysemenyukoracle]

Should user just take it from another JDK which works?

Yes

It does not look like a solution to this issue.

Do you have a better idea?

[alexeysemenyukoracle]

Can we add test which will use SignTool to sign produced .exe installer?

What would be the action if the test fails? Why SignTool?

Other tools are:

• osslsigncode
• ksign
• jsign
• signpath

Should we test that the installer exe is signable by specific versions of all these tools?

[sashamatveev]

Do you have a better idea?

Can we sign msiwrapper.exe which does not have any embedded msi? jmod.exe can be used to extract it from resources. If it works maybe bug in our embed code. If it does not work do we know when it was introduced and figure out root cause?

[alexeysemenyukoracle]

maybe bug in our embed code

The code has been the same since the first release of jpackage.

do we know when it was introduced and figure out root cause

Quote from the bug description:

JDK 21.0.2 (Temurin)

A DESCRIPTION OF THE PROBLEM :
I have recently upgraded from Java 18 to Java 21, and noticed that there has been a change in jpackage which is causing signtool (the Microsoft code signing tool) to fail when signing the installer. Even though the installer .exe can be run on the system, the signtool command fails with:

SignTool Error: SignedCode::Sign returned error: 0x800700C1

This rather cryptic message refers to ERROR_BAD_EXE_FORMAT. Note that the same build run with Java 18 produces an .exe installer which does not have this problem.

If I compare the .exe produced by Java 21 with that produced by Java 18 with dumpfile and pestudio, I notice two differences:

1. There is a 'version' section containing application name and version information in the Java 18 installer which is no longer present
2. The linker version has changed from 1.27 to 1.37

Maybe something is off with the toolchain used to assemble Temurin JDK 21.

I used pestudio to inspect the value of the linker's version in PE headers of Open JDK binaries from Oracle. A few releases I inspected have something like "Microsoft Linker 14.36".
I did the same for msiwrapper.exe from Temurin JDK21 (OpenJDK21U-jdk_x64_windows_hotspot_21.0.2_13.zip). The linker version is "Microsoft Linker 14.37". For Temurin JDK18 (OpenJDK18U-jdk_x64_windows_hotspot_18.0.2.1_1.zip) the linker version is "Microsoft Linker 14.27".

2. The linker version has changed from 1.27 to 1.37

Maybe the submitter meant the linker version changed from 14.27 to 14.37?

Anyway, they didn't complain about the Oracle variant of OpenJDK. If this is linker version-specific issue SignTool test may pass with Oracle OpenJDK and fail with other variants built with different toolchains.

[sashamatveev]

Thanks for explanation. It makes sense now and fix is just to provide workaround for such cases.

[sashamatveev]

Looks good.

[alexeysemenyukoracle]

/integrate

[openjdk]

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

• 2efb033: 8350601: Miscellaneous updates to jpackage test lib
• d4fdc79: 8344981: [REDO] JDK-6672644 JComboBox still scrolling if switch to another window and return back
• b78043f: 8320220: Compilation of cyclic hierarchy causes infinite recursion
• a3188e0: 8349991: GraphUtils.java can use String.replace() instead of String.replaceAll()
• d422abc: 8350668: has_extra_module_paths in filemap.cpp may be uninitialized
• 829d7a8: 8339889: Several compiler tests ignore vm flags and not marked as flagless
• 0151b15: 8348367: Remove hotspot_not_fast_compiler and hotspot_slow_compiler test groups
• c5992ca: 8349533: Refactor validator tests shell files to java
• dea7a9f: 8350516: Update model numbers for ECore-based cpus
• 5023971: 8267068: Incomplete @throws javadoc for various javax.crypto.spec classes
• ... and 30 more: https://git.openjdk.org/jdk/compare/dfcd0df60c60cf89dc01682264a573ad39e61a17...master

Your commit was automatically rebased without conflicts.

[openjdk]

@alexeysemenyukoracle Pushed as commit 267d69b.

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

[credmond]

I am seeing this also, after switching from Azul to Temurin (JDK23).

It's not just the installer, the application .exe itself cannot be signed either.

Something is definitely not correct with Temurin's release.

[gtoison]

@credmond see: adoptium/adoptium-support#1244
The issue seems to be with the Temurin build

[credmond]

Agreed, I am just reinforcing that. I also tested with OpenJDK and had no issues.