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

[Michael Hall]

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

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