Is there anyway to get a simple/test reference type application available that could be used in reproducing bugs? 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> 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). 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. 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. With —install-dir this remains a reproducible bug for me at 17-ea. If a reference build was provided somewhere I might have picked up on the parameter difference sooner.
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 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>
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).
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.
With —install-dir this remains a reproducible bug for me at 17-ea.
If a reference build was provided somewhere I might have picked up on the parameter difference sooner.
On Apr 17, 2021, at 12:14 AM, David Holmes <david.holmes@oracle.com> wrote:
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.
I was unaware of this distinction. Then I will attempt to come up with a simpler reproducible test case but I don’t know if I’ll succeed. If the test that didn’t reproduce that is mentioned in the comments was available I could try to compare that with what I am doing for differences. I could provide my invocation parameters to the email requesting the reproducer. That is my only direct involvement. If it is something else particular to the application itself I don’t know what that might be. Modular vs. my non-modular? Or something like that maybe. I think this always embeds the current JDK and I have checked against more than one so it doesn’t seem to be JDK version specific. Thanks for pointing this status information out.
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
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>
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.
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 That dmg should ignore --input-dir and always propose dragging apps into /Applications
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
On Apr 17, 2021, at 8:57 AM, Andy Herrick <andy.herrick@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
On Apr 17, 2021, at 9:14 AM, Michael Hall <mik3hall@gmail.com> wrote:
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
Sorry got distracted thinking about the signature thing. But currently at 17ea if a user, other than myself now, makes the same mistake of including —install-dir the DMG problem is still there.
On Apr 17, 2021, at 9:14 AM, Michael Hall <mik3hall@gmail.com> wrote:
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
OK I think this may be it. For my testing I sort of force the DMG build back to the —install-dir one. open -Wg HalfPipe-1.0.dmg cp -r /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app … diskutil eject HalfPipe open outputdir/HalfPipe.app codesign -v outputdir/HalfPipe.app outputdir/HalfPipe.app: a sealed resource is missing or invalid If instead I do the proper drag and drop install to the Applications directory. codesign -v /Applications/HalfPipe.app No error. So apparently ‘cp’ is not a good idea on a signed application. At least not on a signed java one. This one can probably be closed permanently.
On Apr 17, 2021, at 9:37 AM, Michael Hall <mik3hall@gmail.com> wrote:
So apparently ‘cp’ is not a good idea on a signed application. At least not on a signed java one.
Fyi for anyone who wants to copy a Mac signed java app from a script or maybe from java Runtime. Instead of… cp -r /Volumes/HalfPipe/HalfPipe.app outputdir/HalfPipe.app this… ditto /Volumes/HalfPipe outputdir Copies and still codesign verifies.
participants (3)
-
Andy Herrick
-
David Holmes
-
Michael Hall