JDK-8276150 : Quarantined jpackage apps are labeled as "damaged"
  • Type: Bug
  • Component: tools
  • Sub-Component: jpackage
  • Affected Version: 16,17,18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2021-10-27
  • Updated: 2022-07-13
  • Resolved: 2021-11-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 18
17.0.5-oracleFixed 18 b25Fixed
Related Reports
Relates :  
JDK-8254662 - [macos] macOS tells an app to be damaged when created from jpackage and downloaded from external location
Relates :  
JDK-8277493 - [REDO] Quarantined jpackage apps are labeled as "damaged"
Relates :  
JDK-8277494 - [BACKOUT] JDK-8276150 Quarantined jpackage apps are labeled as "damaged"
Description
ADDITIONAL SYSTEM INFORMATION :
I'm running on macOS 12.0.1 (Monterey) on a MacBook Pro and running OpenJDK 17

A DESCRIPTION OF THE PROBLEM :
I'm actually having the exact same issue as previously reported here:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8254662
This bug was closed as not reproducible.  But I'm seeing this exact behavior with the 'dmg' I created with JDK 17: I can run the dmg locally to install the app in /Applications and subsequently run it.  But if I upload that same dmg to a web site and then re-download it, I can still install into /Appliations, but when I run the app, macOS tells me it's damaged and only lets me move it to the trash.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See the previously opened ticket.  The 'jpackage' command I used myself is:
jpackage --name SATriage --app-version 1.0.0 --icon /Users/twolf/spectare/git/swing_app/src/com/spectare/gui/images/bigLogo.icns --input ./ --main-jar swing_app.jar

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The above command creates a SATriage-1.0.0.dmg file.  If I upload this to the web and subsequently download it and run it, I expect it to still install SATriage.app into /Applications folder and that I can still run the .app thereafter.  But I get an error.
ACTUAL -
When I try to run the app, I get an error dialog that says "SATriage.app" is damaged and can't be opened. You should move it to the Trash".

CUSTOMER SUBMITTED WORKAROUND :
Removing attributes from the app lets the application run:
sudo xattr -cr /Applications/XXX.app
But this is not a good workaround as it probably has side effects.
Comments
jdk17u-na: was backed out again.
13-07-2022
Changeset: 936f7ff4 Author: Andy Herrick <herrick@openjdk.org> Date: 2021-11-19 14:23:04 +0000 URL: https://git.openjdk.java.net/jdk/commit/936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0
19-11-2021
The existing code only unsigns items in "Contents/runtime" or "Contents/Frameworks" sub-dirs before signing everything. Should we continue to only unsign the executables and libraries in these sub-directories, or unsign such files anywhere in the app-image ? Since everything in the input dir will be included in an app-image, it should be possible to have signed executables and/or libraries in the input dir. This would cause: 1.) This problem if posting unsigned app on the web. 2.) Different problem when signing if different signing attributes are used (which is why we unsign elements in the runtime before signing) Because of these two problems I propose we unsign everything in an app-image before checking if it needs to be signed.
10-11-2021
yes - the above is confirmed, when unsigned app is built including a signed java runtime, the "damaged" error occurs, when built with unsigned runtime, the "developer cannot be verified" message is shown. To fix we could unsign the runtime that is put into an unsigned app. We already unsign everything before signing (to get everything signed the same). Now we would just use that code to unsign everything when creating unsigned app.
09-11-2021
DOH#! this happens for my app also using JDK-17 to build it, I was using JDK-18 ea, and can't see it there - so it appears to already be fixed in JDK-18, I will try to figure out what change fixed it. Actually - it is not 17 vs 18, but official builds vs private builds. I suspect the problem is that with the runtime signed, MacOSs is seeing unsigned app (containing a signed runtime) as "partially signed" and therefore damaged.
09-11-2021
Now that we have your dmg I can see the problem with your app that I don't see with mine (I get the unsigned app from the internet dialog instead of the damaged app dialog). will figure out whats the difference ...
09-11-2021
FWIW, I am able to reproduce this. Build a dmg using jpackage locally and then install it locally and open the application, all works fine. I then copy over this dmg to a webserver and then download it and then install it and try to open it, I get the popup saying the app is damaged and can only be moved to Bin. Reading up on this a bit and then investigating the differences between the local dmg and the downloaded dmg (which is essentially the same, byte for byte), I do see some differences which are crucial. It comes down to the extended attributes that get applied to the downloaded dmg file. To list the extended attributes on that file, I did: xattr /path/to/download/foo.dmg This resulted in: ... <snipped unrelated attributes> com.apple.quarantine When I run that same command against the locally created dmg file, I see no such "com.apple.quarantine" attribute. Reading more about this, I found this discussion useful which explains how to view the value of this attribtue and then understand what that value means https://stackoverflow.com/questions/46198557/understanding-output-of-xattr-p-com-apple-quarantine/46219929#46219929. So I did a: xattr -p com.apple.quarantine /path/to/download/foo.dmg on that downloaded file and that output the value. I then used to the UUID that was output to find its details in the sqllite DB as explained in that link. Not much useful info in that table other than it stating that I downloaded that dmg file from a particular URL using Firefox (that's the browser I had used). I then read up some old discussion that this "com.apple.quarantine" extended attribute gets applied to a file if the application that downloaded it has "LSFileQuarantineEnabled" attribute set to "true" in its Info.plist file. Since Firefox was the application that downloaded the dmg, I checked the Info.plist file (which is typically at /Applications/<appname>/Contents/Info.plist) and it indeed had: <key>LSFileQuarantineEnabled</key> <true/> So that's actually a hint that it's the tool/application that was used to download the application/dmg which contributes to marking that file app/file as quarantined. So I decided to skip Firefox or any other browser and instead use the curl command line tool to download the same dmg file that I had hosted on the webserver. Once downloaded, I did the same: xattr /path/to/download/foo.dmg and this time I didn't see any com.apple.quarantine on it. I then went ahead and installed this app and then even opened it and it all went fine. So it looks like it's not the target application/dmg which is an issue here, instead it's the mode/tool of download which is contributing to it. I have no experience in this area to explain why Firefox (or other similar tools) mark the file with that com.apple.quarantine extended attribute and what value it generally is adding to the whole "trustability" aspect. Give it a try with curl to see if it solves your issue too.
09-11-2021
Additional Information from submitter: =========================== I wish I could comment directly on the JIRA issue - since I was the one who reported the problem. This interface doesn't even let me attach files! If it did, I could simply send you my application's dmg file and you could reproduce it. Two coworkers reproduced this on macOS 10.15 (Catalina) and I see it on Monterey (12.0.1), so it's not difficult to reproduce. One additional piece of feedback: I previously stated that "sudo xattr -cr /Applications/SATriage.app" got rid of the problem for me. This did not work for my Catalina-based coworkers. But they did get the app working by omitting the 'r' in the above command. So, reiterating: I'd be happy to upload the dmg bundle to somewhere so you can try it - just tell me how/where!
08-11-2021
[~almatvee] could you please try to reproduce this issue?
02-11-2021
Additional Information from submitter: =========================== The comment said that the related issue was checked in JDK 16 and couldn't reproduce. But after submitting the bug report, I built my dmg under JDK 16 as well as JDK 18ea and I see the same issue in all 3 versions of the JDK. This form doesn't let me attach anything, otherwise I would simply give you the DMG to try.
02-11-2021
I cannot reproduce this as described. I am running Mac OS 11.2.3 If I build a dmg using jpackage for a simple app, and post it on the web. Then download that dmg, and open it. Then install the app (drag and drop it in the applications folder) Then try to run the app (either clicking on /Applications/<app name>.app in finder, or running /Applications/Content/Macos/<app name> from terminal window I get the expected dialog: "<app name>" cannot be run because the developer cannot be verified. macOS cannot verify this app is free from malware Firefox downloaded this file today at 2:12 PM from ... [Move to Trash] [Cancel] xattr /Applications/<app name>.app responds with only : com.apple.quarantine same with "Contents" or "Contents/Info.plist" or "Contents/MacOS/<app name> Again, I am both building this on, and downloading to MacOS 11.2.3
29-10-2021
The issue is similar to JDK-8254662. As per the comment https://bugs.openjdk.java.net/browse/JDK-8254662?focusedCommentId=14374620&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14374620 the issue was checked in JDK 16. However this is reported from JDK 17.
29-10-2021