> 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
<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.
Thanks
Mike
>
