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

[Michael Hall]

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