8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image

[sashamatveev]

Problem is that JDK-8286850 never set correct value in .jpackage.xml to mark image as signed. JDK-8289030 reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.

Added tests to cover this case and added check for values inside .jpackage.xml to validate signed and Mac App Store values.

---

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

Issue

• JDK-8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image

Reviewers

• Alexey Semenyuk (@alexeysemenyukoracle - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10316

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

Using diff file

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

[bridgekeeper]

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

@sashamatveev 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 (5598345c)
• 01: Full - Incremental (19d4981d)
• 00: Full (22ead550)

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Sep 16, 2022, at 6:02 PM, Alexander Matveev <almatvee at openjdk.org> wrote:

Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850 <https://bugs.openjdk.org/browse/JDK-8286850>) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030 <https://bugs.openjdk.org/browse/JDK-8289030>) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.

Alexander,

I think I figured out how to include PR?s in my build and this appears good.

codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement

This was new?
Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image.

I?m not quite sure what it?s saying but it doesn?t seem to impact what I?m doing.

Thanks,
Mike

FWIW, I ran into
[macos] cmstypes.c fails compilation with Xcode13.3
https://bugs.openjdk.org/browse/JDK-8283221 <https://bugs.openjdk.org/browse/JDK-8283221>

Adding this which I noticed in the source?
cmsUNUSED_PARAMETER(SizeOfTag); // mjh

To the two erroring methods?
~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:179: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:182: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]

Seemed a fix. I could build.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220916/e0f5e9de/attachment-0001.htm>

[mlbridge]

Mailing list message from Alexander Matveev on core-libs-dev:

Hi Michael,

On Sep 16, 2022, at 6:19 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:

On Sep 16, 2022, at 6:02 PM, Alexander Matveev <almatvee at openjdk.org<mailto:almatvee at openjdk.org>> wrote:

Problem is that [JDK-8286850](https://bugs.openjdk.org/browse/JDK-8286850) never set correct value in .jpackage.xml to mark image as signed. [JDK-8289030](https://bugs.openjdk.org/browse/JDK-8289030) reads this value to check if we can add per-user and system wide configuration to packaged app. Fixed by setting correct value in .jpackage.xml when we signing predefine application image.

Alexander,

I think I figured out how to include PR?s in my build and this appears good.

codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement

This was new?
Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image.

I?m not quite sure what it?s saying but it doesn?t seem to impact what I?m doing.

This warning means that support for per-user configuration of the installed application will be disabled. We added support for per-user configuration with https://bugs.openjdk.org/browse/JDK-8250950 (Allow per-user and system wide configuration of a jpackaged app).

Thanks,
Alexander

Thanks,
Mike

FWIW, I ran into
[macos] cmstypes.c fails compilation with Xcode13.3
https://bugs.openjdk.org/browse/JDK-8283221

Adding this which I noticed in the source?
cmsUNUSED_PARAMETER(SizeOfTag); // mjh

To the two erroring methods?
~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:179: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]
~/Documents/GitHub/jdk/build/macosx-x86_64-server-release/build.log:182: /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125: error: parameter 'SizeOfTag' set but not used [-Werror,-Wunused-but-set-parameter]

Seemed a fix. I could build.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/761200ee/attachment.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

Alexander,

I think I figured out how to include PR?s in my build and this appears good.

codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement

This was new?
Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image.

I?m not quite sure what it?s saying but it doesn?t seem to impact what I?m doing.

This warning means that support for per-user configuration of the installed application will be disabled. We added support for per-user configuration with https://bugs.openjdk.org/browse/JDK-8250950 <https://bugs.openjdk.org/browse/JDK-8250950> (Allow per-user and system wide configuration of a jpackaged app).

Thanks,
Alexander

Alexander,

I?ll take a look. It sounds like it could be a useful feature at times. The last update still works for me.

Thanks again,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/9c3dfe1a/attachment-0001.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Sep 20, 2022, at 5:01 PM, Michael Hall <mik3hall at gmail.com> wrote:

Alexander,

I think I figured out how to include PR?s in my build and this appears good.

codesign -v --verbose=4 "/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app"
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: valid on disk
/Volumes/BlackJack Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: satisfies its Designated Requirement

This was new?
Warning: Support for per-user configuration of the installed application will not be supported due to missing "BlackJack Blastoff_Unsigned.app/Contents/app/.package" in predefined signed application image.

I?m not quite sure what it?s saying but it doesn?t seem to impact what I?m doing.

This warning means that support for per-user configuration of the installed application will be disabled. We added support for per-user configuration with https://bugs.openjdk.org/browse/JDK-8250950 <https://bugs.openjdk.org/browse/JDK-8250950> (Allow per-user and system wide configuration of a jpackaged app).

Thanks,
Alexander

Alexander,

I?ll take a look. It sounds like it could be a useful feature at times. The last update still works for me.

Thanks again,
Mike

Alexander,
One thing I notice is that
Release Note: Allow per-user and System Wide Configuration of a jpackaged app
https://bugs.openjdk.org/browse/JDK-8288249 <https://bugs.openjdk.org/browse/JDK-8288249>
Mentions?
~/Library/Application Support/${PACKAGE_NAME}
Which would be a per user location. But doesn?t mention
/Library
Which would be the system level location.

Since both of these locations are external to the application bundle I?m not understanding why they would no longer work with whatever you changed.
I may need to look closer.
Given that this does break that, one possibility might be to include parameter changes in the Info.plist file. Some time back Apple java applications used to include a java dictionary in the plist that was more or less equivalent to the jpackage .cfg file. Maybe a override mechanism could be added to that which would be up to the developer to add in post processing.
Customizing the Info.plist file is still the main thing I am considering doing for this feature.
Another recent thought was that I could use this to add a hsdis dylib to the jdk lib directory for an application to allow printing disassembly. But then I noticed it doesn?t appear that hsdis is even needed in recent jdk?s? -XX:+PrintAssembly seems to just work. Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven?t tested.

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/b231d6fd/attachment-0001.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com> wrote:

Given that this does break that, one possibility might be to include parameter changes in the Info.plist file. Some time back Apple java applications used to include a java dictionary in the plist that was more or less equivalent to the jpackage .cfg file. Maybe a override mechanism could be added to that which would be up to the developer to add in post processing.

Never mind on this. That is no different really from the .cfg file and doesn?t help with changing settings on the installed machine, user or system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/17af5334/attachment.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Sep 20, 2022, at 6:04 PM, Michael Hall <mik3hall at gmail.com> wrote:

On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:

Given that this does break that, one possibility might be to include parameter changes in the Info.plist file. Some time back Apple java applications used to include a java dictionary in the plist that was more or less equivalent to the jpackage .cfg file. Maybe a override mechanism could be added to that which would be up to the developer to add in post processing.

Never mind on this. That is no different really from the .cfg file and doesn?t help with changing settings on the installed machine, user or system.

Alexander,

If you don?t mind a little more opinion on this. When I started trying to figure out what to do with application external files on OS/X I began with the ?Application Support? directories. But it occurred to me that most users rarely look at or often possibly aren?t even aware of the ?Application Support? directory. So if I thought if I want the user to look at or actively manage a file I'd put it in their Documents directory.

I also thought it might be nice going for different file types possibly on different platforms if you didn?t have to think about what would be the best place to put things. So I tried to come up with an API that would determine the locations for me and all I would indicate would be the data type. Like?

public enum DataTypes {
/**
* temporary
*/
TEMP,
/**
* log file type
*/
LOG,
/**
* cache file type
*/
CACHE,
/**
* preferences file type
*/
PREFERENCES,
/**
* permanent, critical, not user accessible
*/
PERMANENT,
/**
* permanent, non-critical, user accessible
*/
USER,
/**
*
* Documents folder
*/
DOCUMENTS;
}

Example usages:
// default path
path = Application.getApplication().getFolder(DOCUMENTS).resolve("userprefs.xml?);
Although that pretty obviously resolves to the Documents directory.

Or
Path logDir = Application.getApplication().getFolder(LOG);

Where the API determines the best location for log files and you don?t have to be concerned.
Not so clear exactly where that might be, but you don?t really have to worry about it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220920/ee62ecee/attachment-0001.htm>

[openjdk]

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

8293462: [macos] app image signature invalid when creating DMG or PKG from post processed signed image

Reviewed-by: asemenyuk

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

• aca4276: 8294379: Missing comma after copyright year
• 1f521a1: 8225012: sanity/client/SwingSet/src/ToolTipDemoTest.java fails on Windows
• 5ae6bc2: 8234262: Unmask SIGQUIT in a child process
• 968af74: 8293567: AbstractSplittableWithBrineGenerator: salt has digits that duplicate the marker
• 36b61c5: 8293872: Make runtime/Thread/ThreadCountLimit.java more robust
• 2be3158: 4797982: Setting negative size of JSplitPane divider leads to unexpected results.
• 050eebf: 8294245: Make Compile::print_inlining_stream stack allocated
• 91a23d7: 8294142: make test should report only on executed tests
• 169a5d4: 8294193: Files.createDirectories throws FileAlreadyExistsException for a symbolic link whose target is an existing directory
• 3675f4c: 8293252: Shenandoah: ThreadMXBean synchronizer tests crash with aggressive heuristics
• ... and 151 more: https://git.openjdk.org/jdk/compare/41ce6582674bb5d14f2edb34e40ee1d7ae7601d8...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.

[sashamatveev]

/integrate

[openjdk]

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

• 43eff2b: 8272687: Replace StringBuffer with StringBuilder in RuleBasedCollator
• b88ee1e: 6251738: Want a top-level summary page that itemizes all spec documents referenced from javadocs (OEM spec)
• aca4276: 8294379: Missing comma after copyright year
• 1f521a1: 8225012: sanity/client/SwingSet/src/ToolTipDemoTest.java fails on Windows
• 5ae6bc2: 8234262: Unmask SIGQUIT in a child process
• 968af74: 8293567: AbstractSplittableWithBrineGenerator: salt has digits that duplicate the marker
• 36b61c5: 8293872: Make runtime/Thread/ThreadCountLimit.java more robust
• 2be3158: 4797982: Setting negative size of JSplitPane divider leads to unexpected results.
• 050eebf: 8294245: Make Compile::print_inlining_stream stack allocated
• 91a23d7: 8294142: make test should report only on executed tests
• ... and 153 more: https://git.openjdk.org/jdk/compare/41ce6582674bb5d14f2edb34e40ee1d7ae7601d8...master

Your commit was automatically rebased without conflicts.

[openjdk]

@sashamatveev Pushed as commit 1e222bc.

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

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com> wrote:

Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven?t tested.

Thinking about this I looked at my application that includes java commands and saw that currently I include all. And all appear to be of fixed size. So I assume some kind of launcher stub?

I then remembered

[macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
https://bugs.openjdk.org/browse/JDK-8286122 <https://bugs.openjdk.org/browse/JDK-8286122>

The bug being due?

ITMS-90511: CFBundleIdentifier Collision - The Info.plist CFBundleIdentifier value 'net.java.openjdk.java' of 'java' is already in use by another application.

This because the launcher stub includes it?s own Info.pliat?s always using the same CFBundleIdentifier

If I understand the resolution correctly?
https://github.com/openjdk/jdk17u-dev/commit/6a4b6220f8dc184f408f1295865ed0ad2e3710ca <https://github.com/openjdk/jdk17u-dev/commit/6a4b6220f8dc184f408f1295865ed0ad2e3710ca>

This effectively prohibits jpackage applications going to the App Store from using java native commands by disallowing the jlink option.
I realize this issue is closed and probably not yours to resolve.

But wouldn?t it be possible to simply make the CFBundleIdentifier unique?
Maybe a hash of command name and application name, something like?
Hash(?java?+?MyCommandUsingMacAppStoreApp?)

I don?t think the identifiers for the embedded commands need to be meaningful to the developer or anyone else. A good hash should pretty much eliminate collisions.

My apologies if I?m simply repeating something dismissed in prior discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220926/401611f4/attachment-0001.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Sep 26, 2022, at 9:24 PM, Michael Hall <mik3hall at gmail.com> wrote:

On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:

Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven?t tested.

Thinking about this I looked at my application that includes java commands and saw that currently I include all. And all appear to be of fixed size. So I assume some kind of launcher stub?

I then remembered

[macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
https://bugs.openjdk.org/browse/JDK-8286122 <https://bugs.openjdk.org/browse/JDK-8286122>

It might be an idea, if coming up with a unique or hashed CFBundleIdentifier in the Info.plist isn?t seen as a workable alternative, for jpackage to issue a warning anytime jlink parameters are passed without ?strip-native-commands to issue a warning message that the application will not be eligible for the Mac App Store.
So developers don?t develop applications with a dependency on native commands intending them for the Mac App Store only to find out when they attempt a final MAS version that they are prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220927/8afa5f23/attachment.htm>

[mlbridge]

Mailing list message from Alexander Matveev on core-libs-dev:

Hi Michael,

It is not possible to provide a unique or hashed CFBundleIdentifier. We already implemented to throw error if ?strip-native-commands are not provided to jlink or if provided runtime contain bin directory.
Look at https://github.com//pull/8666

Thanks,
Alexander

On Sep 27, 2022, at 4:44 AM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:

On Sep 26, 2022, at 9:24 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:

On Sep 20, 2022, at 5:50 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:

Still you could use post-processing to add whatever java binary executable commands you wanted. This again would mean changes to the embedded jdk that might have signing side effects. I haven?t tested.

Thinking about this I looked at my application that includes java commands and saw that currently I include all. And all appear to be of fixed size. So I assume some kind of launcher stub?

I then remembered

[macos]: App bundle cannot upload to Mac App Store due to info.plist embedded in java exe
https://bugs.openjdk.org/browse/JDK-8286122

It might be an idea, if coming up with a unique or hashed CFBundleIdentifier in the Info.plist isn?t seen as a workable alternative, for jpackage to issue a warning anytime jlink parameters are passed without ?strip-native-commands to issue a warning message that the application will not be eligible for the Mac App Store.
So developers don?t develop applications with a dependency on native commands intending them for the Mac App Store only to find out when they attempt a final MAS version that they are prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220927/6d507543/attachment-0001.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Sep 27, 2022, at 2:48 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:

Hi Michael,

It is not possible to provide a unique or hashed CFBundleIdentifier. We already implemented to throw error if ?strip-native-commands are not provided to jlink or if provided runtime contain bin directory.
Look at https://github.com//pull/8666 <https://github.com//pull/8666>

Thanks,
Alexander

Alexander
I assume you do this only if --mac-app-store is indicated? I have an application, not for the App Store, that excludes ?strip-native-commands jlink parm and as I mentioned I get all of the native commands. I don?t pay much attention to the messages because it has been working fine for some time, but I don?t think any exceptions are thrown.
My suggestion is that even doing this and not including ?mac-app-store should get a warning it won?t work for App Store so that if a developer is working on an application with native commands and only when complete tries adding the ?mac-app-store parameter they would know immediately and not after considerable effort that there is a problem.

Thanks
MikeFrom the java shell app with embedded commands?

set java.home
java.home=/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/runtime/Contents/Home
exec ${java.home}/bin/java -version
openjdk version "19" 2022-09-20
OpenJDK Runtime Environment (build 19+36-2238)
OpenJDK 64-Bit Server VM (build 19+36-2238, mixed mode)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220927/8d7f1215/attachment-0001.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Sep 27, 2022, at 4:27 PM, Michael Hall <mik3hall at gmail.com> wrote:

On Sep 27, 2022, at 2:48 PM, Alexander Matveev <alexander.matveev at oracle.com <mailto:alexander.matveev at oracle.com>> wrote:

Hi Michael,

It is not possible to provide a unique or hashed CFBundleIdentifier. We already implemented to throw error if ?strip-native-commands are not provided to jlink or if provided runtime contain bin directory.
Look at https://github.com//pull/8666 <https://github.com//pull/8666>

Thanks,
Alexander

Alexander,
FWIW I came up with another workaround/fix for this.
Sort of as suggested it modifies the CFBundleIdentifier in the application java command's embedded Info.plist.
To do this requires post-processing. So it is somewhat a use case for that and a test that some changes can be made to the jdk itself and still get a valid signed application.
The command is PlistZap
http://mikehall.pairserver.com/PlistZap.java
Historical basis for name?
https://www.jaymoseley.com/hercules/zap_utility/imaspzap.htm <https://www.jaymoseley.com/hercules/zap_utility/imaspzap.htm>
It was and probably still is a IBM mainframe program for doing disk patches or fixes.
Early Apple java versions had 1 or 2 occasions where similar fixes were suggested so my java shell application includes an ?fzap? command. Some of that 20+ year old code is included in the above.
PlistZap finds the embedded Info.plist and changes only the part of the CFBundleIndentifier that is set to ?openjdk?. It replaces this with a random string based on all characters valid for a CFBundleIdentifier?
https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier <https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier>
So the basic structure of the current CFBundleIdentifier remains intact but you get I believe 63^7 randomness included. I think this should be sufficient to avoid collisions. But have done no direct testing. It would be easy enough. Generate a few hundred or few thousand random strings and make sure there are no duplicates.
I did find using a built jdk, for post-processing, rather than an installed jdk includes a ?-internal? in the CFBundleIdentifier so I added a ?-I? switch to the command for that.
So anyhow, example of use shows file hex dumps at the change?

java -cp /Users/mjh PlistZap -i HalfPipe.app/Contents/runtime/Contents/Home/bin/java
Before...
3e00 66696572 3c2f6b65 793e0a20 20202020 fier</key>.
3e10 2020203c 73747269 6e673e6e 65742e6a <string>net.j
3e20 6176612e 6f70656e 6a646b2d 696e7465 ava.openjdk-inte
3e30 726e616c 2e6a6176 613c2f73 7472696e rnal.java</strin
After...
3e00 66696572 3c2f6b65 793e0a20 20202020 fier</key>.
3e10 2020203c 73747269 6e673e6e 65742e6a <string>net.j
3e20 6176612e 6f776a6a 7552752d 696e7465 ava.owjjuRu-inte
3e30 726e616c 2e6a6176 613c2f73 7472696e rnal.java</strin
done

Showing signature is still valid after signing?
codesign -v --verbose=4 "HalfPipe.app"
HalfPipe.app: valid on disk
HalfPipe.app: satisfies its Designated Requirement

And from the application it still works?
exec ${java.home}/bin/java -version
openjdk version "20-internal" 2023-03-21
OpenJDK Runtime Environment (build 20-internal-adhoc.mjh.jdk)
OpenJDK 64-Bit Server VM (build 20-internal-adhoc.mjh.jdk, mixed mode)

I realize there are possibly not enough applications involved for this to be a major concern but a hash like fix would be possible.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221002/ae413251/attachment.htm>

[mlbridge]

Mailing list message from Michael Hall on core-libs-dev:

On Oct 2, 2022, at 8:36 AM, Michael Hall <mik3hall at gmail.com> wrote:

and a test that some changes can be made to the jdk itself and still get a valid signed application.

Alexander

You may want to consider if this opens up a security vulnerability that doesn?t currently exist.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221003/4356c368/attachment-0001.htm>