> On Mar 17, 2020, at 3:28 PM, Andy Herrick <andy.herr...@oracle.com> wrote:
>
> yes jpackage itself will not do any signing unless you use the various
> signing option(s).
>
> But the executables in the jdk itself are signed, including those packaged as
> a resource like jpackageapplauncher itself.
>
> The app executable itself, in your case
> FastRGraalHP.app/Contents/MacOS/FastRGraalHP, is a copy of jpackageapplauncher
>
> /Andy
>
> On 3/17/2020 4:04 PM, Michael Hall wrote:
>>
>>>
>>> codesign -dv outFastR/FastRGraalHP.app
>>> Executable=/Users/mjh/HalfPipe/HalfPipe_jpkg/outFastR/FastRGraalHP.app/Contents/MacOS/FastRGraalHP
>>> Identifier=jpackageapplauncher
>>> …
>>>
>>> It does appear that jpackage is doing some default code signing.
>>>
>> Running verbose I see no indication, other than maybe the above, that
>> jpackage is in fact code signing. If this is something Apple is doing and
>> GraalVM is doing something to violate it then it is definitely not something
>> jpackage can probably do anything about.
>>
OK thanks. Graal seems to do some access control requiring
Context context = Context.newBuilder().allowNativeAccess(true).build();
Or allowAllAccess()
Must be some issue of theirs or something I just haven’t figured out being new
to it.
