> On May 17, 2022, at 12:15 AM, Alexander Matveev 
> <alexander.matv...@oracle.com> wrote:
> Hi Michael,
> I filed following enhancement for signing user provided app image and yes it 
> will be two step process. Invoke jpackage to generate image, then user can 
> modified it and then invoke jpackage again to sign it.
> https://bugs.openjdk.java.net/browse/JDK-8286850
> For JDK-8286122, I will integrate proposed fix as is. Error will be thrown if 
> user tries to include native commands for Mac App Store image.
> Still not sure if we will provide solution for including native commands with 
> Mac App Store. Including special versions of native commands with jpackage 
> will work only if runtime is generated by jpackage. It will not solve issue 
> with user provided runtime. Also, it is not clear if app updates will require 
> same unique ID based on UUID across app versions.

This enhancement doesn’t directly concern this issue. Although given this 
enhancement it would be possible to provide a temporary ‘hack’ fix without 
building it into jpackage. Where the executables are changed to make them 
unique in the post-processing step. If it is not your intention to address this 
issue given this enhancement you would probably have to check the provided 
application bundle to be sure it doesn’t have the colliding Info.plist native 
commands. What Apple DTS provided may of had commands for this? I don’t 
remember. Or you would have to just fail any passed application bundles with 
native java commands.

From https://bugs.openjdk.java.net/browse/JDK-8286850 

> Generating DMG or PKG from —app-image with signing enabled will not sign app 
> image as it currently do.

I am not sure you would want to change this. If the developer doesn’t want to 
do any post-processing of the application bundle then they should be able to 
use the current invocations unchanged to do this?
I would think if you want post-processing you would generate unsigned 
applications, post-process, use the enhancement to sign. 

> Also, many functionality provided by native JDK commands can be used via 
> ToolProvider. For example if you include jdk.jpackage module with your app, 
> you should able to use jpackage functionality from your app via ToolProvider 
> without actual jpackage native command.
> Thanks,
> Alexander

Which might be another way this could be useful. If any 3rd parties want to 
generate their own application bundles they could still use jpackage as the 
definitive way to sign those.


Reply via email to