jpackage bugs

[Andy Herrick]

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
>>
>>
>>