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
