andy.herrick at oracle.com
Sat Apr 17 13:57:24 UTC 2021
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:
>> 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
>> 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
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.
>> 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:
That dmg should ignore --input-dir and always propose dragging apps
>> 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.
More information about the core-libs-dev