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. 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 > On May 16, 2022, at 6:03 PM, Michael Hall <mik3h...@gmail.com> wrote: > > > >> On May 16, 2022, at 7:09 PM, Alexander Matveev >> <alexander.matv...@oracle.com> wrote: >> >> Hi Michael, >> >>> >>>>> >>>>> I’m not real familiar with the build process. But would it be possible >>>>> for the user to build their own jdk that substitutes something else for >>>>> the colliding identifier that gets embedded? >>>> Yes, it should be possible and in theory such JDK with native commands can >>>> be used. However, current fix will not allow such JDK build, since we >>>> checking for presence of “bin” folder and not if ID is actually unique. To >>>> work around this limitation user can package without native commands >>>> first, then add native commands and re-sign application. >>> >>> Signing is currently an integrated part of the process. I thought about >>> making an enhancement request to have it possible to do it stepped. First >>> build the application, then allow the user to post-process that. Maybe run >>> a tool/script to modify the application level Info.plist file. Then allow a >>> second final step that does the signing. I don’t remember if I actually >>> made that enhancement request. But currently there is no way with jpackage >>> to standalone sign the application is there? I think this is somewhat >>> involved with the application bundle being iterated and for one thing each >>> jar being separately code signed? I think it took a release or two of the >>> command to get this correct. So I doubt Xcode could manage it. Is there a >>> way to do the signing standalone with jpackage that I am not aware of? >>> >>> If I didn’t do an enhancement request on this I could, if you think >>> jpackage could manage it? >>> >> >> There is no a way to do the signing of standalone app image and app image >> will not get signed if you generating DMG or PKG by providing app image via >> —app-image and specifing signing. Only PKG will get signed if signing is >> specified with —app-image. >> >> Currently jpackage will block following command: >> jpackage --type app-image --app-image Test.app --mac-sign ... >> Error: Option [--app-image] is not valid with type [app-image] >> >> I think we can allow app-image type with app image input if signing is >> requested and command from above will just sign app image in place. >> >> Generating DMG or PKG from —app-image and with signing enabled will not sign >> app image as it currently do. >> >> If no objections for proposed enhancement I will go ahead and file one. >> >> Thanks, >> Alexander > > Alexander > > I’m not entirely sure I’m following this. I assumed it wasn’t currently > possible to do standalone signing against an application bundle but would > require an enhancement request. If you are saying you will do that request > yourself, that’s fine. > Again, I think this should be possible as a two step process. The first would > be to generate the application bundle. Then perform some application bundle > post-processing, probably independent of jpackage. Finally allow a jpackage > invocation that takes the path to the completed application bundle and > performs the signing. > If this is what you are thinking we are on the same page. > > Thanks > Mike >
