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)

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]

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

[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.