Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Application Exports report as "Damaged" on macOS Sierra #4705
There seems to be a serious signing issue when trying to run an exported processing Mac application on computers other than the one it was created. I consistently get this error:
Yes and Yes.
However, I have an update. It seems to only be a problem when the application is zipped and emailed/drop boxed/google drive/etc.
When I put it on a thumb drive and bring that to another machine, it works fine. When I zip it, transmit it through whatever means online, then unzip it, it appears as damaged.
Thanks for the quick response, let me know if there are any other questions (and thanks for all the great work on Processing in general).
Sorry, turns out the other user I was mailing with was confused and was using Sierra. I apologize for not confirming more throughly before commenting. Seems like you can work around it Sierra, but this seems like a major issue:
Glad to see this noted, as I was tearing hair out!!
I went so far as to join Developer program, so I can sign my own exported apps.
Here's what I learned:
I can confirm: binary transfers such as
DO work, because the Finder or whatever hasn't had the chance to inspect them as they are stored.
But via ftp GUI clients like CyberDuck, any browser, or cloud storage - MacOS/Finder intercepts and tags them as insecure (i.e. quarantines them).
The easiest way to unquarantine them and allow them to run is:
But I can't ask my users to do that ,of course, nor require them to use command-line ftp.
The above will return the options "Apps from identified developers" and "Anywhere" to the Security preferences.
Finally, there is a download at Apple Dev site called check-signature. It is a wrapper around codesign, but it ends with a simple "YES" or "NO" as to whether the given file/folder would pass Gatekeeper:
Within Processing, we self-sign the application so that you can run it on your own machine without it being reported as damaged. This was already a lot of effort to implement a year or two ago. And before 10.12, that method worked (with a warning to users, and them needing to allow the app) on other machines.
It looks like we'll have to get into something where people have to install Xcode (yech) in order to use exported applications, and set up an app signing key for themselves (double yech). All around really lousy. It's like… like trying to do serious work on a laptop with no USB ports that match anything I own, no HDMI connector, and no MagSafe for power.
I discovered that if you use a shell script to launch the app, the shell script can launch the app successfully -- even though directly launching the app does not work. Interesting.
So I considered using a double clickable shell script called launch.command or whatever. (No need to use Terminal, if a shell script ends in .command – you must know that already. )
What about a script in the exported app folder called run-me-1st.command? Inside of it it does the xattr command on the folder... hmmm Not ideal, but
It sounds maybe better than downloading and installing Xcode, which can take two hours --that's what it took me just yesterday. I was shocked at the incredible slowness of that process. I used to install it at least once a year and it was never such an undertaking. I think watchOS and tvOS might be causing bloat...
I certainly will, and I'll point you to a download of my app so you can play with all of it if you like, but first I wanted to say that there may no longer be a need for Ben to self-sign the exported apps at all.
Here is why I'm wondering:
First I made sure the exported app was signed (by Ben):
Then I unsigned my exported app, the actual executable, with:
Then I renamed the unsigned version above to be the actual one, down in the MacOS/ dir:
Now it seems to be unsigned alright:
Then I tested that it still ran for me on my own machine where all this took place, and it did.
So I zipped the whole thing up and ftp'd it to my other Mac, and when I double-clicked EQC_v2.app on that Mac I did NOT get the "Move to Trash" dialog, I got the "Unidentified developer" (which can be overridden by right mousing it as we all know)
The point is not that it's possible to "unsign" things! I was simulating the scenario where the exported app was not signed at all at export time from Processing.
So it may, MAY be a case where "less is more".
Of course the devs will have explored this far deeper than I have, I'm just a dabbler.
Later I'll post my scripts, I need to sanitize them from stuff that is not related and would confuse folks.
I feel your pain! Too many permutations of OS versions and Security settings and testing scenarios. I've had a headache for 3 days on this.
You are right to be surprised, I could not duplicate what I just said -- using a ZIP file.
However when I use a disk image (with the same CyberDuck in both cases) I do indeed get "unidentified developer" for the unsigned one.
I made a super simple disk image to show this. Link at end.
There are two export folders, one left alone after export, the other I ran "unsign" on the .app/ .
When I used the (great) DropDMG utility to make a disk image of them, and transferred it that way instead of ZIP, the unsigned app can be launched.
Both xferred with CyberDuck to same testing machine (10.11 Capitan), but the disk image, unsigned app can launch. Interesting. ... So Maybe it's 'cuz it's 10.11?
I will now try same by CyberDucking the DMG file back to the machine I made it on, Sierra 10.12.1.
It still works if it was unsigned and not if it was self-signed.
Here is the untouched, self-signed one:
And now the unsigned one:
Sharp eyes will notice the words "disk image" in the dialog above.
The test files above are here, for a limited time:
I sincerely hope this is helpful, I'm not trying to muddy the water or contradict your guys' experience, in the past or present.
It occurred to me to search for other signed items in my "unsigned" app folder.
I did find a few files still signed, Oracle-related, obviously not preventing app from running:
the self-signed, untouched one, for comparison:
Really appreciate you taking the time to look into this.
Other tidbits that might be useful:
Again, thanks for the help. You're getting a window into the many, many hours of time that go into the maintenance of keeping this stuff in working condition, let alone adding anything new or fixing actual bugs.
Re-reading this comment makes me think that our larger problem may be that the embedded copy of Java is causing the problem because it still shows as signed by me. Mixed signing states will cause the "damaged" messages.
So… if there were a standard way to unsign the app using Apple's tools that are installed by default (i.e. codesign), that might be a good fix for Sierra.
for me i found two quick "solutions" to get an app to a client (maybe this could be announced on the processing site until the issue is fixed so that people don't freak out like me ... ;) ?):