<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 27, 2022, at 4:27 PM, Michael Hall <<a href="mailto:mik3hall@gmail.com" class="">mik3hall@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Sep 27, 2022, at 2:48 PM, Alexander Matveev <<a href="mailto:alexander.matveev@oracle.com" class="">alexander.matveev@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Michael,
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class="">Look at <a href="https://github.com/openjdk/jdk/pull/8666" class="">https://github.com/openjdk/jdk/pull/8666</a></div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">Alexander<br class="">
<div class=""><br class=""></div></div></div></div></blockquote></div></div></div></blockquote><br class=""></div><div>Alexander,</div><div>FWIW I came up with another workaround/fix for this. </div><div>Sort of as suggested it modifies the CFBundleIdentifier in the application java command's embedded Info.plist. </div><div>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.</div><div>The command is PlistZap</div><div><a href="http://mikehall.pairserver.com/PlistZap.java" class="">http://mikehall.pairserver.com/PlistZap.java</a></div>Historical basis for name…<div class=""><a href="https://www.jaymoseley.com/hercules/zap_utility/imaspzap.htm" class="">https://www.jaymoseley.com/hercules/zap_utility/imaspzap.htm</a></div><div class="">It was and probably still is a IBM mainframe program for doing disk patches or fixes. </div><div class="">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.</div><div class="">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…</div><div class=""><a href="https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier" class="">https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleidentifier</a></div><div class="">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.</div><div class="">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. </div><div class="">So anyhow, example of use shows file hex dumps at the change…</div><div class=""><br class=""></div><div class="">java -cp /Users/mjh PlistZap -i HalfPipe.app/Contents/runtime/Contents/Home/bin/java<br class="">Before...<br class="">3e00 66696572 3c2f6b65 793e0a20 20202020 fier</key>. <br class="">3e10 2020203c 73747269 6e673e6e 65742e6a <string>net.j<br class="">3e20 6176612e 6f70656e 6a646b2d 696e7465 ava.openjdk-inte<br class="">3e30 726e616c 2e6a6176 613c2f73 7472696e rnal.java</strin<br class="">After...<br class="">3e00 66696572 3c2f6b65 793e0a20 20202020 fier</key>. <br class="">3e10 2020203c 73747269 6e673e6e 65742e6a <string>net.j<br class="">3e20 6176612e 6f776a6a 7552752d 696e7465 ava.owjjuRu-inte<br class="">3e30 726e616c 2e6a6176 613c2f73 7472696e rnal.java</strin<br class="">done<br class=""><br class=""></div><div class="">Showing signature is still valid after signing…</div><div class="">codesign -v --verbose=4 "HalfPipe.app" <br class="">HalfPipe.app: valid on disk<br class="">HalfPipe.app: satisfies its Designated Requirement</div><div class=""><br class=""></div><div class="">And from the application it still works…</div><div class="">exec ${java.home}/bin/java -version<br class="">openjdk version "20-internal" 2023-03-21<br class="">OpenJDK Runtime Environment (build 20-internal-adhoc.mjh.jdk)<br class="">OpenJDK 64-Bit Server VM (build 20-internal-adhoc.mjh.jdk, mixed mode)</div><div class=""><br class=""></div><div class="">I realize there are possibly not enough applications involved for this to be a major concern but a hash like fix would be possible.</div><div class=""><br class=""></div></body></html>