Jpackage Mac entitlements

Michael Hall mik3hall at
Thu Apr 22 14:33:52 UTC 2021

> On Apr 22, 2021, at 7:41 AM, Andy Herrick <andy.herrick at> wrote:
> On 4/21/2021 6:15 PM, Michael Hall wrote:
>> Reverted to Jdk 16 and temporarily couldn’t figure out why AppleScript wasn’t working again.
>> I needed to provide an entitlement. At jpackage 16 I found I needed to do this differently with a <>.entitlements file in the resources directory, as I noticed in the verbose command output.
>> I had previously noticed that jpackage 17 now includes a parameter to provide this.
>> Will both options continue to be supported, resource dir and parm, or will parm become the only supported way at or after 17?
> Yes, if --mac-entitlement options exists, it will use it, otherwise , the previous behavior is maintained, the default resource entitlements.plist in the source code will be used unless overridden by <app name>.entitlements in the resource directory.
> /Andy

Ok so in order…

    <app name>.entitlements
	jpackage provided default

If at some point after the —mac-entitlement parameter has been in place for a while and it is decided to eliminate the resource dir option a warning message might be an idea.

I still think possibly including a verify error exception or warning might also be helpful if that has issues

I figured out that when I was trying different things with signing I must of deleted my Developer ID Application: certificate from keychain. Which is what must of been being found by the jpackage /usr/bin/security find-certificate. Hard coding my fully qualified “3rd Party” cert was working fine.

After putting my Developer ID Application cert back in the keychain signing again worked by just using my name - but once more the app doesn’t verify. 
This time if I codesign -v it seems ok. But for some reason the Taccy application shows…

App signature check:
⛔️ spctl error 3
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/ rejected
source=Unnotarized Developer ID
origin=Developer ID Application: <me>

For what I am doing this is not a problem but could be a concern for someone trying to get an application into the App Store. 

So, if you do not currently have plans to do something or there is already a RFE in place that you know of. I will submit one to include a verify on signed applications.

More information about the core-libs-dev mailing list