New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application Exports report as "Damaged" on macOS Sierra #4705

Closed
madparker opened this Issue Oct 17, 2016 · 24 comments

Comments

Projects
None yet
6 participants
@madparker

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:

screen shot 2016-10-17 at 12 19 52 pm

To reproduce:

  1. Open up a new processing sketch (or any processing sketch, really)

  2. Go to File>Export Application

  3. Select Mac OS X and click export

  4. Move the exported application to another Mac OS X machine, running El Capitan

  5. Attempt to run application on new machine

@madparker

This comment has been minimized.

Show comment
Hide comment
@madparker

madparker Oct 17, 2016

I believe this is a code signing issue, but right clicking and selecting "open" no longer allows it to run.

I believe this is a code signing issue, but right clicking and selecting "open" no longer allows it to run.

@gohai

This comment has been minimized.

Show comment
Hide comment
@gohai

gohai Oct 18, 2016

Contributor

@madparker Both machines on El Capitan (10.11)?

Contributor

gohai commented Oct 18, 2016

@madparker Both machines on El Capitan (10.11)?

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Oct 18, 2016

Member

And this is with 3.2.1?

Member

benfry commented Oct 18, 2016

And this is with 3.2.1?

@madparker

This comment has been minimized.

Show comment
Hide comment
@madparker

madparker Oct 19, 2016

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

Matt

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

Matt

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Oct 19, 2016

Member

And that's not the case for the same application exported with earlier releases?

Member

benfry commented Oct 19, 2016

And that's not the case for the same application exported with earlier releases?

@madparker

This comment has been minimized.

Show comment
Hide comment
@madparker

madparker Oct 20, 2016

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:

http://apple.stackexchange.com/questions/243687/allow-applications-downloaded-from-anywhere-in-macos-sierra

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:

http://apple.stackexchange.com/questions/243687/allow-applications-downloaded-from-anywhere-in-macos-sierra

@benfry benfry changed the title from Mac Application Export "Damaged" to Application Exports report as "Damaged" on macOS Sierra Oct 20, 2016

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Oct 20, 2016

Member

Ok, that's a huge difference; Apple is kneecapping folks like us with the changes in Sierra. We'll have to figure something out…

Member

benfry commented Oct 20, 2016

Ok, that's a huge difference; Apple is kneecapping folks like us with the changes in Sierra. We'll have to figure something out…

@benfry benfry added the macosx label Oct 20, 2016

@benfry benfry added the high label Oct 29, 2016

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 2, 2016

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

  • ftp command line
  • wget / curl
  • scp

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:

xattr -d -r com.apple.quarantine # to remove GateKeeper quarantine

But I can't ask my users to do that ,of course, nor require them to use command-line ftp.

Also useful:

sudo spctl --master-disable # disable Gatekeeper
sudo spctl --master-enable

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:

$ check-signature EQC_v2.app/
(c) 2014 Apple Inc. All rights reserved.
EQC_v2.app/: invalid Info.plist (plist or signature have been modified)
In architecture: x86_64
NO

A final chuckle: the check-signature utility itself triggered Gatekeeper as being untrusted! haha:
coreservicesuiagent-1

rwelti commented Nov 2, 2016

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

  • ftp command line
  • wget / curl
  • scp

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:

xattr -d -r com.apple.quarantine # to remove GateKeeper quarantine

But I can't ask my users to do that ,of course, nor require them to use command-line ftp.

Also useful:

sudo spctl --master-disable # disable Gatekeeper
sudo spctl --master-enable

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:

$ check-signature EQC_v2.app/
(c) 2014 Apple Inc. All rights reserved.
EQC_v2.app/: invalid Info.plist (plist or signature have been modified)
In architecture: x86_64
NO

A final chuckle: the check-signature utility itself triggered Gatekeeper as being untrusted! haha:
coreservicesuiagent-1

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 3, 2016

Member

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.

Member

benfry commented Nov 3, 2016

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.

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 3, 2016

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

rwelti commented Nov 3, 2016

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

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 3, 2016

The run-me-1rst.command script would only be need to be run ONCE, I did not make that clear. It isn't a launcher script, it merely performs a single command, the xattr command, to unquarantine the .app/ folder.

rwelti commented Nov 3, 2016

The run-me-1rst.command script would only be need to be run ONCE, I did not make that clear. It isn't a launcher script, it merely performs a single command, the xattr command, to unquarantine the .app/ folder.

@madparker

This comment has been minimized.

Show comment
Hide comment
@madparker

madparker Nov 3, 2016

Yeah, not ideal, but certainly better than the current situation. Once you have a clickable shell script working, maybe post it here as an example?

Yeah, not ideal, but certainly better than the current situation. Once you have a clickable shell script working, maybe post it here as an example?

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 3, 2016

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:
I found and compiled a program unsign to remove signatures, from
a project called unsign

First I made sure the exported app was signed (by Ben):

$ codesign -dvvv EQC_v2.app/
Executable=/Users/russwelt/Downloads/application.macosx.latest/EQC_v2.app/Contents/MacOS/EQC_v2
Identifier=org.processing.app
Format=app bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=338 flags=0x0(none) hashes=5+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=40512ef260f3e0409b982c4e59886952ee567739
CandidateCDHash sha256=11ee6579f4b69181bdb622399c245a7206315375
Hash choices=sha1,sha256
CDHash=11ee6579f4b69181bdb622399c245a7206315375
Signature size=8896
Authority=Developer ID Application: Ben Fry LLC
Authority=Developer ID Certification Authority

Then I unsigned my exported app, the actual executable, with:

 $ unsign  /Users/russwelt/Downloads/application.macosx.latest/EQC_v2.app/Contents/MacOS/EQC_v2
 reading infile: /Users/russwelt/Downloads/application.macosx.latest/EQC_v2.app/Contents/MacOS/EQC_v2
   processing fat architecture 1 of 2
     found LC_CODE_SIGNATURE
   processing fat architecture 2 of 2
     found LC_CODE_SIGNATURE
 wrote outfile: /Users/russwelt/Downloads/application.macosx.latest/EQC_v2.app/Contents/MacOS/EQC_v2.unsigned

Then I renamed the unsigned version above to be the actual one, down in the MacOS/ dir:

$ mv EQC_v2.unsigned EQC_v2

Now it seems to be unsigned alright:

$ codesign -dvvv EQC_v2.app/   
EQC_v2.app/: code object is not signed at all

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.

rwelti commented Nov 3, 2016

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:
I found and compiled a program unsign to remove signatures, from
a project called unsign

First I made sure the exported app was signed (by Ben):

$ codesign -dvvv EQC_v2.app/
Executable=/Users/russwelt/Downloads/application.macosx.latest/EQC_v2.app/Contents/MacOS/EQC_v2
Identifier=org.processing.app
Format=app bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=338 flags=0x0(none) hashes=5+3 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=40512ef260f3e0409b982c4e59886952ee567739
CandidateCDHash sha256=11ee6579f4b69181bdb622399c245a7206315375
Hash choices=sha1,sha256
CDHash=11ee6579f4b69181bdb622399c245a7206315375
Signature size=8896
Authority=Developer ID Application: Ben Fry LLC
Authority=Developer ID Certification Authority

Then I unsigned my exported app, the actual executable, with:

 $ unsign  /Users/russwelt/Downloads/application.macosx.latest/EQC_v2.app/Contents/MacOS/EQC_v2
 reading infile: /Users/russwelt/Downloads/application.macosx.latest/EQC_v2.app/Contents/MacOS/EQC_v2
   processing fat architecture 1 of 2
     found LC_CODE_SIGNATURE
   processing fat architecture 2 of 2
     found LC_CODE_SIGNATURE
 wrote outfile: /Users/russwelt/Downloads/application.macosx.latest/EQC_v2.app/Contents/MacOS/EQC_v2.unsigned

Then I renamed the unsigned version above to be the actual one, down in the MacOS/ dir:

$ mv EQC_v2.unsigned EQC_v2

Now it seems to be unsigned alright:

$ codesign -dvvv EQC_v2.app/   
EQC_v2.app/: code object is not signed at all

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.

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 3, 2016

To clarify, when I ftp'd it to the other Mac, I used CyberDuck, NOT the command line ftp (which already transfers stuff as "unquarantined"). CyberDuck and browser downloads are where stuff gets marked as quarantined, AFAIK.

rwelti commented Nov 3, 2016

To clarify, when I ftp'd it to the other Mac, I used CyberDuck, NOT the command line ftp (which already transfers stuff as "unquarantined"). CyberDuck and browser downloads are where stuff gets marked as quarantined, AFAIK.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 3, 2016

Member

Hm, that would be surprising since part of the reason we had to start signing was that applications were reported as damaged.

Member

benfry commented Nov 3, 2016

Hm, that would be surprising since part of the reason we had to start signing was that applications were reported as damaged.

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 3, 2016

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:

banners and alerts

$ codesign -dvv ArcLengthParametrization_SelfSigned.app/
Executable=/Users/russwelt/Downloads/signingTestAsDownloadedDMG/ArcLengthParametrization_SelfSigned/application.macosx/ArcLengthParametrization_SelfSigned.app/Contents/MacOS/ArcLengthParametrization_SelfSigned
Identifier=org.processing.app
Format=app bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=242 flags=0x0(none) hashes=5+3 location=embedded
Signature size=8543
Authority=Developer ID Application: Ben Fry LLC
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Oct 23, 2015 j=296, 2:04:56 PM
Info.plist=not bound
TeamIdentifier=8SBRM6J77J
Sealed Resources=none
Internal requirements count=1 size=180

And now the unsigned one:

banners and alerts-1

$ codesign -dvv ArcLengthParametrization_UnSigned.app/
ArcLengthParametrization_UnSigned.app/: code object is not signed at all

Sharp eyes will notice the words "disk image" in the dialog above.
I realized I launched it from the mounted image by mistake.
But same behavior after dragging to a local folder.

The test files above are here, for a limited time:

anon ftp://ftp.iris.washington.edu/pub/pickup/signingTest.dmg
(Sorry, ftp:// links not recognized by github markdown.}

I sincerely hope this is helpful, I'm not trying to muddy the water or contradict your guys' experience, in the past or present.

rwelti commented Nov 3, 2016

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:

banners and alerts

$ codesign -dvv ArcLengthParametrization_SelfSigned.app/
Executable=/Users/russwelt/Downloads/signingTestAsDownloadedDMG/ArcLengthParametrization_SelfSigned/application.macosx/ArcLengthParametrization_SelfSigned.app/Contents/MacOS/ArcLengthParametrization_SelfSigned
Identifier=org.processing.app
Format=app bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20200 size=242 flags=0x0(none) hashes=5+3 location=embedded
Signature size=8543
Authority=Developer ID Application: Ben Fry LLC
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Oct 23, 2015 j=296, 2:04:56 PM
Info.plist=not bound
TeamIdentifier=8SBRM6J77J
Sealed Resources=none
Internal requirements count=1 size=180

And now the unsigned one:

banners and alerts-1

$ codesign -dvv ArcLengthParametrization_UnSigned.app/
ArcLengthParametrization_UnSigned.app/: code object is not signed at all

Sharp eyes will notice the words "disk image" in the dialog above.
I realized I launched it from the mounted image by mistake.
But same behavior after dragging to a local folder.

The test files above are here, for a limited time:

anon ftp://ftp.iris.washington.edu/pub/pickup/signingTest.dmg
(Sorry, ftp:// links not recognized by github markdown.}

I sincerely hope this is helpful, I'm not trying to muddy the water or contradict your guys' experience, in the past or present.

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 3, 2016

I would be curious to know if you experience the same behavior as I showed above, if you get time to download it.

rwelti commented Nov 3, 2016

I would be curious to know if you experience the same behavior as I showed above, if you get time to download it.

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 3, 2016

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:

$ find .  -exec codesign -dvv {} \; 2>&1 | grep ^Identifier=
Identifier=com.oracle.java.8u51.jdk
Identifier=net.java.openjdk.cmd
Identifier=net.java.openjdk.cmd
Identifier=net.java.openjdk.cmd
Identifier=com.oracle.java.8u51.jdk

the self-signed, untouched one, for comparison:

$ find .  -exec codesign -dvv {} \; 2>&1 | grep ^Identifier=
Identifier=org.processing.app
Identifier=org.processing.app
Identifier=com.oracle.java.8u51.jdk
Identifier=net.java.openjdk.cmd
Identifier=net.java.openjdk.cmd
Identifier=net.java.openjdk.cmd
Identifier=com.oracle.java.8u51.jdk

rwelti commented Nov 3, 2016

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:

$ find .  -exec codesign -dvv {} \; 2>&1 | grep ^Identifier=
Identifier=com.oracle.java.8u51.jdk
Identifier=net.java.openjdk.cmd
Identifier=net.java.openjdk.cmd
Identifier=net.java.openjdk.cmd
Identifier=com.oracle.java.8u51.jdk

the self-signed, untouched one, for comparison:

$ find .  -exec codesign -dvv {} \; 2>&1 | grep ^Identifier=
Identifier=org.processing.app
Identifier=org.processing.app
Identifier=com.oracle.java.8u51.jdk
Identifier=net.java.openjdk.cmd
Identifier=net.java.openjdk.cmd
Identifier=net.java.openjdk.cmd
Identifier=com.oracle.java.8u51.jdk

@rwelti

This comment has been minimized.

Show comment
Hide comment
@rwelti

rwelti Nov 3, 2016

@madparker
I have written a lot today so for now, here is a link to a description with actual code that I made of the "scripted launch" workaround to "damaged" apps. It's brittle and not a solution but interesting perhaps. It has one advantage: console output is logged to a file.

launchProcAppViaScript.txt

rwelti commented Nov 3, 2016

@madparker
I have written a lot today so for now, here is a link to a description with actual code that I made of the "scripted launch" workaround to "damaged" apps. It's brittle and not a solution but interesting perhaps. It has one advantage: console output is logged to a file.

launchProcAppViaScript.txt

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Nov 4, 2016

Member

Really appreciate you taking the time to look into this.

Other tidbits that might be useful:

  • The embedded Java and the app itself need to be signed in separate steps (see build.xml for how Processing.app is handled, or JavaBuild for how it's done for exported apps)
  • Disk images have another layer of messiness in Sierra. I don't know all the details, but there's additional changes to randomize where app code is located that's giving headaches to a lot of developers.
  • There's a decent chance that a double-clickable remove-xattr.tool or remove-xattr.command will itself need xattr's removed once shuttled around this way. (However, I haven't had time to dig through your whole thread here, so there might be things I'm missing.)

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.

Member

benfry commented Nov 4, 2016

Really appreciate you taking the time to look into this.

Other tidbits that might be useful:

  • The embedded Java and the app itself need to be signed in separate steps (see build.xml for how Processing.app is handled, or JavaBuild for how it's done for exported apps)
  • Disk images have another layer of messiness in Sierra. I don't know all the details, but there's additional changes to randomize where app code is located that's giving headaches to a lot of developers.
  • There's a decent chance that a double-clickable remove-xattr.tool or remove-xattr.command will itself need xattr's removed once shuttled around this way. (However, I haven't had time to dig through your whole thread here, so there might be things I'm missing.)

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.

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Dec 21, 2016

Member

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.

Member

benfry commented Dec 21, 2016

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.

@liasomething

This comment has been minimized.

Show comment
Hide comment
@liasomething

liasomething Dec 26, 2016

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 ... ;) ?):
a) tell the client to write only xattr -rc myApplicaiont.app in the terminal.
(this could be explained in an easy read-me file and does not make the clients machine not save in general)
b) use dropbox, put your app there and ask the client to just sync their dropbox folder, but not (!) use the dropbox download link. at least that worked for me (today).

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 ... ;) ?):
a) tell the client to write only xattr -rc myApplicaiont.app in the terminal.
(this could be explained in an easy read-me file and does not make the clients machine not save in general)
b) use dropbox, put your app there and ask the client to just sync their dropbox folder, but not (!) use the dropbox download link. at least that worked for me (today).

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry May 4, 2017

Member

Thanks to @rwelti's work, I was able to track this down today. So this will be fixed in the next release (3.3.4 or 3.4).

Member

benfry commented May 4, 2017

Thanks to @rwelti's work, I was able to track this down today. So this will be fixed in the next release (3.3.4 or 3.4).

@benfry benfry closed this May 5, 2017

@thierry75

This comment has been minimized.

Show comment
Hide comment
@thierry75

thierry75 May 19, 2017

just to let you know i bypassed this issue by unsigning the binary of my exported app using:
https://github.com/steakknife/unsign
then it goes back to "unknown" in place of damaged and allow right click open trick to open it...

just to let you know i bypassed this issue by unsigning the binary of my exported app using:
https://github.com/steakknife/unsign
then it goes back to "unknown" in place of damaged and allow right click open trick to open it...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment