> On Sep 27, 2022, at 4:27 PM, Michael Hall <mik3h...@gmail.com> wrote: > > > >> On Sep 27, 2022, at 2:48 PM, Alexander Matveev <alexander.matv...@oracle.com >> <mailto:alexander.matv...@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/openjdk/jdk/pull/8666 >> <https://github.com/openjdk/jdk/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.
