Standalone Bug MAX7, OSX Sierra->zipping->uploading->downloading->unzipping->App broken
Hi,
I was struggling with the testing of standalones I wanted to distribute from a server. So I uploaded as zip file, but the users, after downloading from the server could not start the standalones. So I tried by myself and indeed this is what happens:
For ease of reproduction I created a stupid standalone in the latest Sierra version that just looks for a few picts in two folders that are in the searchpath. Just zip it. Unzip it locally, and all is fine.
Now upload the zipped file to the cloud (I used my own webserver and magentacloud, same results). Download it from there, unzip it and the standalone is loosing all the paths to the folders (you see it in the Console window of my examples below).
As a crosscheck I created a .dmg Image. When up- and downloading the image the standalone works ok.
I used "sudo spctl --master-disable" to disable the Gatekeeper horror completely, but no change.
Yes, and the standalones are signed. In El Capitan all works (I didn't check Windows).
So below you find a link to the two versions (.zip, .dmg) . Please let me know if you can reproduce this behaviour.
https://www.magentacloud.de/share/k11vj.3zkg
There were already some reports in the forum with the same issue/bug:
https://cycling74.com/forums/trouble-uploaddownload-standalones-to-online-service-max-7-2-1-not-max-6
https://cycling74.com/forums/problems-sharing-standalone
In a bigger patch when I tried to write from a text object to a folder in the search path, I am getting errors like
text: Iomega-Sierra:/private/var/folders/32/_4kwzvb1295bg6823hqlk1940000gn/T/AppTranslocation/B7619B54-35D1-476D-996A-B8758688F1AD/d/support/LogFile_16_7_2017: error -1 creating file
Hope that helps.
This is a REAL serious bug that prevents the idea of sharing standalones in MAX7.
Bene
This sounds related to OSX's Gatekeeper Path Randomization. As a first troubleshooting step, grab a copy of RB App Checker Lite from the App Store and drag your standalone on it. See if anything is wrong with the signing. We fixed some stuff in this regard for 7.3.4 IIRC, so make sure you're using the latest version of Max, as well.
Hi Jeremy,
thanks for the hint. I am using 7.3.4. I tried RB App Checker Lite. The standalone seems signed ok so far, the only thing I found was at the end:
"45 auxiliary executables have been found.
5 data files have executable permissions, but should not.
One file is invisible in the Finder.
40 executables are unsigned."
The 5 "should nots" are one selfbuilt glsl shader (.jxs,vp.glsl,fp.glsl) and sysaudio.mxe/sysaudio64.mxe.
The 40 unsigned executables reside in the C74 folder. I am attaching the list as .zip file. (EDIT: Upload did not work so I paste the text below)
The example standalone has all features unchecked that blow up the size of it, so probably there would be more unsigned stuff in bigger standalones.
Do I really have to sign all these 40 mxo's and dylib's just to distribute a .zip file in Sierra???
Bene
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/jitter/glstatus.mxo/Contents/MacOS/glstatus
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/m4l/live.guilib.mxo/Contents/MacOS/live.guilib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/autohelp.mxo/Contents/MacOS/autohelp
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/clang.mxo/Contents/MacOS/clang
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/debugwindow.mxo/Contents/MacOS/debugwindow
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/fseventwatcher.mxo/Contents/MacOS/fseventwatcher
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/genpatcher.mxo/Contents/MacOS/genpatcher
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/maxurl.mxo/Contents/MacOS/maxurl
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/maxxslt.mxo/Contents/MacOS/maxxslt
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/maxzlib.mxo/Contents/MacOS/maxzlib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/objectview.mxo/Contents/MacOS/objectview
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/pianoroll.mxo/Contents/MacOS/pianoroll
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/qtimage.mxo/Contents/MacOS/qtimage
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/querylib.mxo/Contents/MacOS/querylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/setplugpath.mxo/Contents/MacOS/setplugpath
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/sqlite.mxo/Contents/MacOS/sqlite
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/synophrys.mxo/Contents/MacOS/synophrys
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/yaml.mxo/Contents/MacOS/yaml
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/max/zoomer.mxo/Contents/MacOS/zoomer
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/msp/max~.mxo/Contents/MacOS/max~
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/msp/polybuffer.mxo/Contents/MacOS/polybuffer
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/extensions/msp/sfplay32~.mxo/Contents/MacOS/sfplay32~
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/externals/ad/ad_coreaudio.mxo/Contents/MacOS/ad_coreaudio
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/externals/ad/ad_portaudio.mxo/Contents/MacOS/ad_portaudio
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/externals/ad/ad_rewire.mxo/Contents/MacOS/ad_rewire
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/externals/ad/MSPReWireDevice.bundle/
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/externals/mididrivers/coremidi.mxo/Contents/MacOS/coremidi
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/externals/mididrivers/midi_adrewire.mxo/Contents/MacOS/midi_adrewire
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/extensions/sysaudio.mxo/Contents/MacOS/sysaudio
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/externals/jit.movie~.mxo/Contents/MacOS/jit.movie~
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/externals/jit.viddll.engine.mxo/Contents/MacOS/jit.viddll.engine
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libavcodec.57.89.100.dylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libavdevice.57.6.100.dylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libavfilter.6.82.100.dylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libavformat.57.71.100.dylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libavresample.3.5.0.dylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libavutil.55.58.100.dylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libswresample.2.7.100.dylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libswscale.4.6.100.dylib
/Users/sierra/Desktop/TheApp/Contents/Resources/C74/packages/VIDDLL/support/libviddll.dylib
Just a follow up:
I signed all listed executables with a bash script, edited all plist files in frameworks/*frameworks and externals/*bundle with my own appID, but still after unzipping the downloaded file the standalone looses all paths.
RB App Checker Lite, codesign and spctl all have no error messages...
I don't want to put the standalone in the App store, just distribute it as a zip file...
I am really stuck here.
Bene
I think I am coming closer...
When you start the downloaded and unzipped standalone of my link above
https://www.magentacloud.de/share/k11vj.3zkg
system.log in Console shows the following error:
Iomega-Sierras-Mac-Pro com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.IDECacheDeleteAppExtension.524): Path not allowed in target domain: type = pid, path = /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Applications/Xcode.app/Contents/PlugIns/IDECacheDeleteAppExtension.appex
As far as I understand, the standalone links to a file that is located within the Xcode app. And of course GateKeeper does not allow links to outside the signed app bundle.
So, I assume this is a Cycling74 issue that arose when you were building the Max7 app.
Should I send this to support or is Cycling74 already looking after that problem?
Bene
How did you configure your server? Does is use any compression for content encoding in the responses? That is a very common source of error when sending zipped content: the compressed archive is compressed a second time by the server and the inflated browser. Quite often zip files break in this process.
Addendum:
I just checked - your are not compressing the data, but the server uses "Transfer-Encoding chunked" Maybe try "binary"instead for zip files.
Hi Jan,
thanks for checking this out.
I tried with a ftp transfer (via Cyberduck) to my web server and the magenta cloud, which is a cloud service from the German Telekom. I have no idea how I could change settings of the last one. In both cases the standalone did not work after download.
But I think the real reasons for the Gatekeeper action are more described in my last post.
As a crosscheck (and if you have a few minutes) you could rebuild my example with Max7, build a standalone, zip/upload to trusted server/download/unzip and try to start it.
If it works, I have to rethink a lot of things here... ;-)
Bene
@bene I'll take a look at this today.
@bene my first comment is that there must be something wrong with your signing procedure or with your certificate: I get the "CantBelieveIt" can't be opened because it is from an unidentified developer warning.
I've resigned it like this:
codesign --deep -f -s "Developer ID Application: Jeremy Bernstein (7H63E36SS5)" CantBelieveIt.app/Contents/MacOS/CantBelieveIt
and now I'm getting the normal quarantined dialog which requests permission to open the app (rather than forbidding it). A couple of differences in our RB App Checker output, none of which, or all of which might be important:
- your signing time is unverified
- my signing certificate is "Developer ID Application", yours is "Mac Developer". I don't know what the difference is as far as Apple is concerned -- do you have an active developer account for app store development? You're also using a different certificate authority (Apple Worldwide Developer Relations Certification Authority vs my Developer ID Certification Authority).
- our implicit requirements are slightly different (probably due to Xcode version differences, I guess -- I'm signing on the latest Sierra with the latest Xcode).
- I have a line "The application is probably from an authorized Apple Developer." which you do not have -- so something is not quite right there, I think.
It's the "unidentified developer" thing which causes Sierra's Gatekeeper Path Randomization to kick in, so we need to figure out what's different about your credentials...
Hi Jeremy,
Thanks for investigating this.
I made a new standalone just to document how I did the code signing process.
I am attaching the steps I made and the results in terminal as well as in „Rb App Checker Lite“.
I changed my developer account name and number here for privacy reasons.
I did not modify the Bundle Identifier in the plists in this example for the same reasons.
BTW. : I am not using Xcode at all. I am manually signing via terminal (how should I do this with MAX ? I just downloaded the certificates and keys via Xcode)
Sorry, this will get a long one now…
Probably this could be partly a step-by-step reference start for people wanting to sign standalones.
—— This cleans unnecessary references that could lead to problems while code signing ——
Iomega-Sierras-Mac-Pro:~ sierra$ xattr -lr /Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app
Iomega-Sierras-Mac-Pro:~ sierra$ xattr -cr /Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app
— This is code signing „from inside out“ as Apple recommends, the list of unsigned executables is created by „RB App Checker Lite“ when dragging the unsigned app on it, just copy the result to „signethem.txt, make it a pure .txt file, not .rtf ———
Iomega-Sierras-Mac-Pro:~ sierra$ OLDIFS=$IFS;IFS=$'\n';for line in $(cat /Users/sierra/Desktop/signethem.txt ); do codesign -f -s "Mac Developer: my_account_name (my_number)“ -v --deep "$line";done
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/jitter/glstatus.mxo/Contents/MacOS/glstatus: signed bundle with Mach-O universal (i386 x86_64) [glstatus]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/m4l/live.guilib.mxo/Contents/MacOS/live.guilib: signed bundle with Mach-O universal (i386 x86_64) [live.guilib]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/autohelp.mxo/Contents/MacOS/autohelp: signed bundle with Mach-O universal (i386 x86_64) [autohelp]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/debugwindow.mxo/Contents/MacOS/debugwindow: signed bundle with Mach-O universal (i386 x86_64) [debugwindow]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/fseventwatcher.mxo/Contents/MacOS/fseventwatcher: signed bundle with Mach-O universal (i386 x86_64) [fseventwatcher]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/maxurl.mxo/Contents/MacOS/maxurl: signed bundle with Mach-O universal (i386 x86_64) [maxurl]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/maxxslt.mxo/Contents/MacOS/maxxslt: signed bundle with Mach-O universal (i386 x86_64) [maxxslt]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/maxzlib.mxo/Contents/MacOS/maxzlib: signed bundle with Mach-O universal (i386 x86_64) [maxzlib]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/objectview.mxo/Contents/MacOS/objectview: signed bundle with Mach-O universal (i386 x86_64) [objectview]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/pianoroll.mxo/Contents/MacOS/pianoroll: signed bundle with Mach-O universal (i386 x86_64) [pianoroll]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/qtimage.mxo/Contents/MacOS/qtimage: signed bundle with Mach-O universal (i386 x86_64) [qtimage]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/querylib.mxo/Contents/MacOS/querylib: signed bundle with Mach-O universal (i386 x86_64) [querylib]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/setplugpath.mxo/Contents/MacOS/setplugpath: signed bundle with Mach-O universal (i386 x86_64) [setplugpath]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/sqlite.mxo/Contents/MacOS/sqlite: signed bundle with Mach-O universal (i386 x86_64) [sqlite]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/synophrys.mxo/Contents/MacOS/synophrys: signed bundle with Mach-O universal (i386 x86_64) [synophrys]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/yaml.mxo/Contents/MacOS/yaml: signed bundle with Mach-O universal (i386 x86_64) [yaml]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/max/zoomer.mxo/Contents/MacOS/zoomer: signed bundle with Mach-O universal (i386 x86_64) [zoomer]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/msp/max~.mxo/Contents/MacOS/max~: signed bundle with Mach-O universal (i386 x86_64) [max~]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/msp/polybuffer.mxo/Contents/MacOS/polybuffer: signed bundle with Mach-O universal (i386 x86_64) [polybuffer]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/extensions/msp/sfplay32~.mxo/Contents/MacOS/sfplay32~: signed bundle with Mach-O universal (i386 x86_64) [sfplay32~]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/externals/ad/ad_coreaudio.mxo/Contents/MacOS/ad_coreaudio: signed bundle with Mach-O universal (i386 x86_64) [ad_coreaudio]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/externals/ad/ad_nonreal.mxo/Contents/MacOS/ad_nonreal: signed bundle with Mach-O universal (i386 x86_64) [ad_nonreal]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/externals/ad/ad_portaudio.mxo/Contents/MacOS/ad_portaudio: signed bundle with Mach-O universal (i386 x86_64) [ad_portaudio]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/externals/ad/ad_rewire.mxo/Contents/MacOS/ad_rewire: signed bundle with Mach-O universal (i386 x86_64) [ad_rewire]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/externals/ad/MSPReWireDevice.bundle/: signed bundle with Mach-O universal (i386 x86_64) [com.cycling74.MSPReWireDevice]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/externals/mididrivers/augraph.mxo/Contents/MacOS/augraph: signed bundle with Mach-O universal (i386 x86_64) [augraph]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/externals/mididrivers/coremidi.mxo/Contents/MacOS/coremidi: signed bundle with Mach-O universal (i386 x86_64) [coremidi]
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app/Contents/Resources/C74/externals/mididrivers/midi_adrewire.mxo/Contents/MacOS/midi_adrewire: signed bundle with Mach-O universal (i386 x86_64) [midi_adrewire]
— After code signing „inside“, code sign the app itself, I am NOT using deep here to avoid conflicts with the already signed executables „inside“. ——
Iomega-Sierras-Mac-Pro:~ sierra$ codesign -f -s "Mac Developer: my_account_name (my_number)" -v /Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app
/Users/sierra/Desktop/MyTestFolderNEW/CantBelieveItNEW.app: signed app bundle with Mach-O universal (i386 x86_64) [com.mycompany.myprogram]
— This is the result after code signing when dragging the signed standalone onto „RB App Checker Lite“ ——
Evaluating the application “CantBelieveItNEW”.
The application was signed by “Apple Root CA”, “Mac Developer: my_account_name (my_number)”.
The (unverified) signing-time is: 24.07.2017, 14:42:56.
The object code format is “app bundle with Mach-O universal (i386 x86_64)”.
The signature contains the Team ID “8LP9BAYHMX”.
Both bundle and signing identifiers are “com.mycompany.myprogram”.
The signature specifies implicit requirements.
The signature specifies resource rules (v1).
The signature specifies resource rules (v2).
Requirements and resources validate correctly.
The code signature has the UUID “8AA957A3-8422-64D9-1B03-9DE51CB1FDB9”.
Executable code for x86_64 has the UUID “AE2AD42F-A01C-3B83-AEE3-A9F4E06F34B3”.
Executable code for i386 has the UUID “F3DFB9DD-8A8F-3F2C-869B-1050BA2D9948”.
A signing-time snapshot of the application’s Info.plist was found.
Version 7.3.4 (fcd0ee6) (7.3.4)
The signature contains 3 certificates.
Certificate “Apple Root CA”:
Your keychain contains this trusted root certificate.
Will expire on 09.02.2035.
Certificate “Apple Worldwide Developer Relations Certification Authority”:
Will expire on 07.02.2023.
Certificate “Mac Developer: my_account_name (my_number)”:
Will expire on 28.06.2018.
SHA1 fingerprint: “6CD71A82700ED4A1BF4DB2649274C8D13F561395”.
Team ID or Organizational Unit: “8LP9BAYHMX”.
This matches the Team ID contained in the signature.
The application is not sandboxed.
There are 4 embedded frameworks.
33 auxiliary executables have been found.
One file is invisible in the Finder.
5 executables are signed by “Apple Root CA”, “Developer ID Application: Cycling '74 (GBXXCFCVW5)”.
28 executables are signed by “Apple Root CA”, “Mac Developer: my_account_name (my_number)”.
28 executables are in the Resources folder.
— Now I am zipping and uploading the app within its surrounding folder „MyTestFolderNEW“ and uploading it to https://www.magentacloud.de/lnk/AIJAN1wW , please download to verify —-
- After Downloading, unzipping, dragging the folder somewhere and starting, the standalone looses all paths and I get the Gatekeeper Error in system.log, that the standalone tries to find some file inside the Xcode app —
Jul 24 15:34:20 Iomega-Sierras-Mac-Pro com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): Unknown key for integer: _DirtyJetsamMemoryLimit
Jul 24 15:34:20 --- last message repeated 1 time ---
Jul 24 15:34:20 Iomega-Sierras-Mac-Pro com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.pid.IDECacheDeleteAppExtension.766): Path not allowed in target domain: type = pid, path = /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/XPCServices/RootDebuggingXPCService.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /Applications/Xcode.app/Contents/PlugIns/IDECacheDeleteAppExtension.appex
Jul 24 15:34:20 Iomega-Sierras-Mac-Pro CantBelieveItNEW[767]: max_startmaxserver
Jul 24 15:34:21 Iomega-Sierras-Mac-Pro CantBelieveItNEW[767]: jaudiowrapper_createdevice Soundflower (2ch) Built-in Output
Jul 24 15:34:21 --- last message repeated 1 time ---
Jul 24 15:34:21 Iomega-Sierras-Mac-Pro CantBelieveItNEW[767]: sqlite version 3.8.5
Jul 24 15:34:21 Iomega-Sierras-Mac-Pro CantBelieveItNEW[767]: SafeBindUnixDomainSocket: socketPath=/tmp/com.cycling74.501/mfl_734_LS
This looks like a unresolved link during compilation of MAX7 or some other execs…
Hope that helps.
Thanks
Bene
I am 99.9% sure that this error is a red herring and unrelated to the Path Randomization. I am not even launching your app and already getting the unidentified developer warning which is the cause. The question for me is: why don't you get "The application is probably from an authorized Apple Developer." in your RB App Checker output?
Very strange. Could you send me copy of your RB App Checker Output?
I am using v1.1.5 of RB App Checker Lite
Please be sure to use the new standalone i mentioned in my previous post:
https://www.magentacloud.de/lnk/AIJAN1wW
I am not sure if I did exactly the same steps in the older one.
Wow, probably it's just the certificate.
In your output there is a "Developer ID Application" certificate that I do not have in my keychain.
I fumbled around with my certificates in XCode, and suddenly I also have a "Developer ID Application" certificate. I am trying now with this one and let you know the results.
Thanks a lot Jeremy!
Bene
Mmmh, ok, the output from RB App Checker looks a bit different now.
It also states that the app is probably from a autorized Apple developer.
Also a few comments are different now.
Unfortunately the standalone still looses all paths and has the same error in system.log in Console.
Link to zip file : https://www.magentacloud.de/lnk/v6pANZmV
Attached is the RB Checker Output file. EDIT: could not upload so I am pasting it into this message:
-----------------Evaluating the application “CantBelieveItWOW”----------------------
The application was signed by “Apple Root CA”, “Developer ID Application: my_name (my_number)”.
Both the verified timestamp and the signing-time are: 24.07.2017, 17:25:32.
The object code format is “app bundle with Mach-O universal (i386 x86_64)”.
The signature contains the Team ID “53B595RFU7”.
Both bundle and signing identifiers are “com.mycompany.myprogram”.
The signature specifies implicit requirements.
The requirements specify the Team ID “53B595RFU7”.
This matches the Team ID contained in the signature.
The signature specifies resource rules (v1).
The signature specifies resource rules (v2).
Requirements and resources validate correctly.
The code signature has the UUID “2DB41EEF-72D3-20B6-922C-AAC9E70172F7”.
Executable code for x86_64 has the UUID “AE2AD42F-A01C-3B83-AEE3-A9F4E06F34B3”.
Executable code for i386 has the UUID “F3DFB9DD-8A8F-3F2C-869B-1050BA2D9948”.
A signing-time snapshot of the application’s Info.plist was found.
Version 7.3.4 (fcd0ee6) (7.3.4)
The signature contains 3 certificates.
Certificate “Apple Root CA”:
Your keychain contains this trusted root certificate.
Will expire on 09.02.2035.
Certificate “Developer ID Certification Authority”:
Will expire on 01.02.2027.
Certificate “Developer ID Application: my_name (my_number)”:
Will expire on 25.07.2022.
SHA1 fingerprint: “00F2E88D95A6B01BAE8F52BEADB721D3D81AF04C”.
Team ID or Organizational Unit: “53B595RFU7”.
This matches the Team ID contained in the signature.
The application is probably from an authorized Apple Developer.
The application is not sandboxed.
There are 4 embedded frameworks.
33 auxiliary executables have been found.
One file is invisible in the Finder.
28 executables are signed by “Apple Root CA”, “Developer ID Application: my_name (my_number)”.
5 executables are signed by “Apple Root CA”, “Developer ID Application: Cycling '74 (GBXXCFCVW5)”.
28 executables are in the Resources folder.
Bene
Addendum:
I was studying the "Code Signing Tasks" reference from Apple
https://developer.apple.com/library/content/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html#//apple_ref/doc/uid/TP40005929-CH4-SW2
and tried all of their examples about examining a code signature via spctl, code sign, otool. I could get no errors with the dezipped standalone version from my last post.
The only thing I found was in the section "Checking Gatekeeper Conformance" in the second paragraph:
Beginning with macOS 10.10.4, Gatekeeper verifies that no libraries are loaded from outside an app bundle. If an app uses @rpath or an absolute path to link to a dynamic library outside of the app, Gatekeeper rejects the app. This restriction applies to the app’s main executable and any other executable in the bundle, including libraries.
...The error will appear in the system log, with a message like the following for an app MyApp.app trying to link against the library (...) in the nonstandard location...
This leads to my assumption, that this link from within the standalone
/Applications/Xcode.app/Contents/PlugIns/IDECacheDeleteAppExtension.appex
is triggering the Gatekeeper action, because it always pops up in system log as error 147 (see above), as soon as I start the dezipped standalone.
Bene
@bene: the console posts are unrelated to this problem and are Sierra garbage having to do with sandboxed resources. Max is not sandboxed. The error is thrown by the maxurl extension and is 100% irrelevant to the issue at hand (you can try it yourself by removing maxurl.mxo from your application's bundle).
I can reproduce the issue with the relative path, though. It looks like Gatekeeper Path Randomization is still kicking in for some reason, but I can debug it on my system. I'll get back with more info as I have it.
I can get your app to work using the following steps:
1. download + unzip
2. drag the unzipped folder to /Applications (~/Desktop would work, too)
3. create a new folder in the folder you just dragged
4. drag the .app into that folder
5. drag it back out of that folder into the main folder
6. run it
This is OSX at its very, very worst, and I think there's absolutely nothing we can do in Max to stop it. You are already correctly signing the .app now -- all of the prerequisites are satisfied, but the OS still doesn't want you to distribute apps via .zip.
You might experiment with signing the .dmg (although I already did this without much luck). The "move the .app" step appears to be vital, and doesn't work if you move the enclosing folder of the .app -- you have to move the .app itself.
You are probably going to need to rethink your distribution such that only an app bundle, or an installer (.pkg) is shipped. The data in the example folders would need to be inside of the app's resources folder (.app/Contents/Resources) which is in the Runtime's search path. Or if those folders are intended to be user-modifyable, you could create them in ~/Documents. Maybe you can create them in a folder with the .app directly in /Applications if you use an installer.
Sorry for the trouble -- this is all very good information which we will collect for reference. If I have time, I'll experiment with installer-building to see if that solves the problem.
Thanks Jeremy for the clarification.
After reading the link, I at least feel that the name of my test app had the right name ;-)
still unbelievable...
Bene
... and I forgot,
yes, the folders should be manageable and searchable by unexperienced users, where the last one is (to my knowledge) not possible inside a bundle...
And a last one:
I signed a .dmg image I made with the last test app. I up/downloaded, moved the folder to the desktop and it seems to work now??!!!
Here is the link to the image: https://www.magentacloud.de/lnk/p4pgtJvK
I added the -f flag when signing.
It would be great if you could confirm that on your machine.
Thanks
Bene
@bene, confirmed, it works for me. Yay!
You may also be able to sign the .zip archive, if you really prefer to distribute as a .zip, but I think the .dmg is a good way to go.
Thanks for confirming, yay!
As a finishing task, I tried with signing a .zip version, unfortunately it did not work (not within the download folder, not after moving the folder to the desktop). I then just dragged the standalone out of the folder to the desktop and back again, and, as you already found out above, it works now. Just moving the app one time out of the unzipped folder and back removed path randomization,
Really, really strange Gatekeeper behavior.
So definitely the way to go in OSX Sierra is via .dmg file distribution.
Thanks again for your help!
Bene
@bene @jeremy, I discovered this thread because I'm having the exact same issues. Can I ask if you ended up testing that .dmg using the protocols above where you signed all of the "unsigned executables"? I am a beginner and having trouble following that. FYI, here's the thread I posted last night.
Any advice you can offer would be much appreciated. Thanks!