> On Apr 17, 2021, at 8:57 AM, Andy Herrick <andy.herr...@oracle.com> wrote:
>
>
> On 4/17/2021 1:14 AM, David Holmes wrote:
>> Hi Michael,
>>
>> On 17/04/2021 10:57 am, Michael Hall wrote:
>>> Is there anyway to get a simple/test reference type application available
>>> that could be used in reproducing bugs?
> I put a simple test application I was using in your bug report:
> https://bugs.openjdk.java.net/browse/JDK-8263156
> <https://bugs.openjdk.java.net/browse/JDK-8263156>
I’ll start with this or at least take a look at it in attempting a reproducer.
>>>
>>> I had two I think potentially serious bugs that were basically not
>>> addressed for problems in reproducing.
>>>
>>> JDK-8263156 : [macos]: OS X application signing concerns - a sealed
>>> resource is missing or invalid
>>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156
>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>
>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156
>>> <https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263156>>
>>>
>>> The command to reproduce was provided. The error appears to be in files
>>> included in the embedded JDK not being signed. So apparently not having to
>>> do with anything of mine. (Mentioned I now see in the comments).
>
> only executables and libraries are signed - this tool running across the
> whole app will find unsigned files, that would be expected.
Hmm. ok. Is the jdk separately signed? Would something in copying it change a
date or something that would cause the verify to fail on the jdk signature
thinking something has changed rather than what you sign for the app?
ls -l HalfPipe.app/Contents/runtime/Contents
total 8
...
drwxr-xr-x 3 mjh staff 96 Apr 16 19:29 _CodeSignature
>
>>>
>>> As I indicate this is not a serious error for me since I am not submitting
>>> the app to the Mac App Store but I believe this would get the app Apple
>>> rejected for anyone who is attempting that. A show stopper for a major use
>>> case. It seems too bad to simply close it because I missed an email asking
>>> for a reproduce.
>>
>> Note the bug referenced is closed as "incomplete" - that is a temporary
>> state while awaiting additional information (usually from the submitter).
>> If we never hear back from the submitter then it will be closed with a
>> different (more terminal) state. If we do hear back then the bug gets
>> reopened.
>>
>> Cheers,
>> David
>>
>>> With a reference application I could demonstrate the error against would
>>> eliminate the need to provide a separate reproducible test case. Quite
>>> sized for the application in question. Such an application is actually
>>> mentioned in the bug report comments. Could such a application be made
>>> available for download or user reproducing - the jpackage command and
>>> arguments?
>>>
>>> I have looked a little bit at if to see if I can figure out how to sign the
>>> embedded jdk files. So far only accomplishing that I can no longer simply
>>> use my name for signing but have to use my fully qualified security
>>> identity.
>>>
>>> The question now seems to be what is in fact the difference between mine
>>> and the, unavailable to me, reference application as to these files
>>> verifying as correctly signed.
>>>
>>> A second bug
>>> JDK-8263154 : [macos]: OS X DMG builds have errors and end up incorrect
>>>
>>> I thought a fix for this was all set to go in and was pulled. It was
>>> apparently determined that the problem only applies if the —install-dir
>>> parameter is used for DMG’s. Where it really makes no sense. My use
>>> apparently held over from when I was just creating the app.I thought this
>>> had somehow also in some way regressed to not reproducible. I still think a
>>> fairly simple change to the AppleScript as was originally planned would
>>> resolve the issue independently of parameters. The default DMG build I
>>> would think should _always_ indicate installation to the Applications
>>> folder.
>
> This is the change proposed now by Alexander on pull request:
> https://git.openjdk.java.net/jdk/pull/3505
> <https://git.openjdk.java.net/jdk/pull/3505>
>
> That dmg should ignore --input-dir and always propose dragging apps into
> /Applications
Agreed.
>
>>>
>>> With —install-dir this remains a reproducible bug for me at 17-ea.
> yes - but what is value of "--install-dir" - can you insure it is a fully
> qualified directory path that exists on all users machines and all users have
> write access to ? With the current code, if applescript cannot create alias
> to this location on target machine it will show this buggy looklin gfinder
> view.
>>>
>>> If a reference build was provided somewhere I might have picked up on the
>>> parameter difference sooner.
>>>
>>>
> /Andy
Yes, there is no good reason to do this and my doing it was a mistake. But
currently still at 17ea
