User Profile

I don't know if this can be of any help to others but I got the same stapling "error 65" in the following case I created a DMG containing a classical bundle "myTest.app" I successfully notarized the .dmg file I got the "Error 65" when trying to staple it. Processing: /Users/xxxx/Development/myTest_Install.dmg CloudKit query for myTest_Install.dmg (2/aaf85e0a1c60c86705e9a8880ebe1ad4cd32bf56) failed due to "Record not found". Could not find base64 encoded ticket in response for 2/aaf85e0a1c60c86705e9a8880ebe1ad4cd32bf56 The staple and validate action failed! Error 65. I ultimately found was that the error was due "myTest.app" not being notarized !!!! Come on Apple, instead of an error message that only aliens can understand it would not be too difficult to give us something more helpful! All the best

Hi, As suggested, I added both com.apple.security.cs.allow-dyld-environment-variables  and com.apple.security.cs.disable-library-validation entitlements. Both are set for the main bundle but checked that they are also present for the embedded bundle while auxiliary binaries have the com.apple.security.inherit entitlement. Unfortunately enough the problem is still present. I will be in travel until the end of the month but when I will be back I am ready for a DTS tech support incident. However, since most of the contents of the App are generated by MatLab, I really don't know how to produce a small test App. All the best Alain

Thank you for your suggestions I will experiment further with entitlements. I already use com.apple.security.cs.disable-library-validation but not the other one because I read in some of your posts that you discourage its use... and because I did not fully understand what it does. Just to let you know, we use the MatLab_Runtine v911 and not a more recent one (perhaps easier to use) because, for some strange reasons, it is the only one which is free of use. However, it’s hard to be sure without looking at your stuff in a lot more depth. If I cannot solve the problem by myself, there would be no problem on my side in sharing the whole project with you, but I do not wish to take up too much of your time. Formalizing everything for you and your informed answers , this is already a big help. Thank you very much again Alain

Sorry if I was not clear enough but your guesses are fully correct: The Matlab Runtime will be installed by users at the imposed location defined by the MathWorks installer: /Applications/MATLAB/MATLAB_Runtime There are two reasons for not to bundle the runtime and not to try to publish to the App Store : the developper of Grasp warned me that, in hot experimental periods, he may produce several upgrades a day to satisfy the immediate needs of scientists. Hence publishing to the store would be too slow by far. the runtime size is 5 GB and downloading it several times a day is not advisable. If MATLAB is always installed at a fixed location, you can reference it statically and thus the environment variable stuff is irrelevant. Yes but, as stated in my last post I found that the binary of some of the libs contains the string DYLD_LIBRARY_PATH probably because they read auxiliary data files. Thus my guess is that DYLD_LIBRARY_PATH being erased or hidden by SIP, MatLab can't find those files and prompts: Error: Could not find version 9.11 of the MATLAB Runtime. In other words I got the feeling that the RPATH mechanism is Okay for the libs but does not apply to auxiliary data files, while the DYLD_LIBRARY_PATH mechanism is Okay for both. Do you have in mind something else that the RPATHs ? The only workaround I can imagine is using a BinHex editor to change DYLD_LIBRARY_PATH to something like MY___LIBRARY_PATH and set that new environment variable that SIP will not alter. Unfortunately I don't think MathWorks will give me the permission to do so. Furthermore this would mean distributing and alternative Matlab Runtime that would not be fully functional (I checked only the .dydlib but there is also a lot of java, python, etc., files. Anyway, your questions helped me understand the problem better. Thank you so much. May be I will be forced to limit myself to the unsigned version which relies on the DYLD_LIBRARY_PATH mechanism.

Thank you very much for your message. "Embedding nonstandard code structures in a bundle." Yes, I read this and tried to adapt it to my case. You are trying to ship the grasp app. At least I would like to distribute it as a notarized bundle since users find the current Terminal app too difficult to install and use. To make my previous post shorter I did not mention the full structure of the final bundle since this is not necessary to get and track the bug (see later). Grasp4Mac.app Contents MacOS grasp4Mac <- calls Grasp4Mac.sh Ressource Grasp4Mac.sh <- check Matlab_runtime and calls run_grasp.sh ----------------------- provided by a colleague and generated by scripts ------------- Grasp run_grasp.sh <- set variables such as DYLD_LIBRARY_PATH and launches grasp.app grasp.app MacOS prelaunch <-- the main grasp <-- which calls the MatLab_Runtime libraries applauncher <-- auxiliary -------------------------------------------------------------------------------------- The MatLab_Runtime (5 Gb) is external to the bundle and located at /Applications/MATLAB/MATLAB_Runtime/v911 Signing both the embedded bundle (grasp.app) and the bundle (Grasp4Mac.app) is not a problem Notarizing it is not a problem Thus I concentrated my efforts on grasp.app launched via run_grasp.sh. It exhibits the same error if SIP is enabled (notarized Grasp4Mac bundle) or if I unset DYLD_LIBRARY_PATH and launches ./run_grasp.sh In Contents/Info.plist, what value have you set for CFBundleExecutable? prelaunch DYLD_LIBRARY_PATH is intended for users running programs from a shell run_grasp.sh sets DYLD_LIBRARY_PATH and launches grasp.app I see no indication from your post that you rewrote your library references to be rpath relative. The MatLAB libraries are already using @rpath. Here an example: The lib called by "grasp" i.e. the parent of a long list of dependencies. /bin/maci64/libmwlaunchermain.dylib: @rpath/libmwlaunchermain.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwi18n.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwfoundation_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwctfdatainterfaces.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwctfpackage.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwmcli18nutil.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwmclmcrrt.9.11.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwopccore.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwopcmodel.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwopczippackage.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwfoundation_log.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) @rpath/libmwcpp11compat.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libmwboost_log.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2022.20.117) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1770.255.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /runtime/maci64/libmwmclmcrrt.9.11.dylib: @rpath/libmwmclmcrrt.9.11.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0) Note that is calls /bin/mac164/libmwmclmcrrt.9.11.dylib which was already loaded by /bin/maci64/libmwlaunchermain.dylib Both /bin/mac164 and /bin/maci64 are amongst the RPATHs May be I should write a script to explore the >3000 MatLab libs and search for something strange. Okay but what shall I search, that's the question! Could it be that one of the MathLab's libraries checks that DYLD_LIBRARY_PATH is set and that SIP doe not "ignore it" but erase or hide it? In that case what could be the workaround ? All the best Alain

The problem is still present with Xcode 14.2. I prepared a fresh new project and the Products folder new showed up. The solution for me was inherited from Pulsar's post but with much less editing of the .xcodeproj file: Quit Xcode Open the bundle MYPROJECT.xcodeproj Edit the file MYPROJECT.pbxproj Search for "Products" In my case I found the following: /* Begin PBXGroup section */ 5D1FC2932992BC6900AA5910 = { isa = PBXGroup; children = ( 5D1FC2B92992BEC100AA5910 /* myBinary1 */, 5D1FC29E2992BC6900AA5910 /* myProject */, 5D1FC2BB2992BEF000AA5910 /* myBinary2 */, 5D1FC29D2992BC6900AA5910 /* Products */, ); I simply moved the /* Products */ line to the top of the "children" list 5D1FC29D2992BC6900AA5910 /* Products */, 5D1FC2B92992BEC100AA5910 /* myBinary1 */, 5D1FC29E2992BC6900AA5910 /* myProject */, 5D1FC2BB2992BEF000AA5910 /* myBinary2 */, Save and reopen Xcode. The Products folder was again visible in the project navigator. I don't know how to feel a bug report for the Xcode team Xcode 13, Xcode 14, the bug is stil present.

We finally found why the binaries x86_64 from our Build Server missed the LC_BUILD_VERSION section. Our server admin is a Linux expert and she configured the macOS server as she did for Linux. The offender turned out to be the packager UPX which works nicely on Linux but does strange things on macOS. UPXed binaries miss LC_BUILD_VERSION parameters, however they work nicely on Big Sur and Ventura for M1. On Ventura for Intel (and presumably on Monterey too) they crash with a "Segmentation fault 11". Removing the UPX step in the cmake of the build server turned ou to be the solution! View, what a fight! I finally got a working version of my app and I am very grateful for your help.

Thank you very much. As you said I cannot use your trick since I do not call NSWorkspace directly. Fortunately enough, a mere osascript solved the case. I noticed that the behaviour of Terminal calls changed since a recent update of Big Sur etc. I wonder if this is a related problem. My X11 based app is organised as follows: [MacOS folder] mybinary --> [Resources] myScript.sh --> myToolBar --> binary_01, binary_02, [...], binary_xx If myScript.sh is called without opening a Terminal window, any of the binaries "binary_xx" when they call "xterm -e" no Terminal window is shown. If myScript.sh is called from an opened Terminal window, "binary_xx" can open a Terminal window too. It is quite strange that now any "binary_xx" inherits a hidden/visible Terminal window from the initial shell script call. As I said my first notice of the problem after a recent Big Sur upgrade but it also affects other macOS versions. This is just to inform you since this is not a blocking problem, at least for me. Just an unwanted extra Window ... I can live with it. All the best

Notararized only. I got the impression that is not possible to sandbox an X11 based application or at least I failed to do so. As a workaround I will try to call the Terminal through an osacript. All the best Alain

Sorry for the delay. Here the crash report from the Console when "com.apple.security.cs.allow-unsigned-executable-memory" removed. Crash report and entitlement All the best

Thank you very much for your help again. As a diagnostic step, try enabling all the hardened runtime exception entitlements and see if that gets your code to start. And this was an excellent advice since my app is again functional. Up-to-now I successfully used the only entitlement: com.apple.security.cs.disable-library-validation I am now forced to add the following: com.apple.security.cs.allow-unsigned-executable-memory I really don't know why since the code of most of the 50 Fortran binaries in the bundle was unchanged. They were only re-compiled on the build server. Anyway, the build server is another story and, at least, with your help, I could notarize the bundle again. For sure, you gave me decisive help! All the best

Thank you very much for your help. That's extremely useful. I encourage you to investigate the build process used by your build server Of course yes but the "build server" is not under my responsibility and thus the vtool trick is welcome to go ahead with my project! $ vtool -show-build myBinary <-- the LC_BUILD_VERSION was successfully added myBinary: Load command 6 cmd LC_BUILD_VERSION cmdsize 24 platform MACOS minos 11.0 sdk 12.1 ntools 0 I thought that the missing minos was the cause of the Killed: 9 error in the Terminal and EXC_BAD_ACCESS (Code Signature Invalid) in the Console. If fact the problem is with "--options runtime" wether or not com.apple.security.cs.disable-library-validation is added to the entitlements This is new to me since I used that codesign option for long for both the current project and some others. $ codesign --remove-signature myBinary $ ./myBinary <--- Okay $ codesign -d --keychain /Users/filhol/Library/Keychains/login.keychain --force --verbose -s "Developer ID Application: xxxxxx" --entitlements simple.entitlements myBinary $ ./myBinary <--- Okay $ codesign -d --keychain /Users/filhol/Library/Keychains/login.keychain --force --options runtime --verbose -s "Developer ID Application: xxxxxx" --entitlements simple.entitlements myBinary $ codesign --display --verbose myBinary CodeDirectory v=20500 size=13876 **flags=0x10000(runtime)** hashes=423+7 location=embedded $ ./myBinary **Killed: 9 ** <-- Why ? And this can be repeated at will. Just removing the "runtime" option makes the binary operational. What do you suggest to bypass this problem ? Here my configuration: MacBook pro late 2013, MacOS Big Sur 11.7.2, Xcode 13.2.1 (I ordered a MacBook pro M1 but not yet received) I will try on a more recent Intel MacOS asap. All the best

I have the same problem with Big Sur 11.6.5. The strange thing is that a double-clic on an existing .txt or .rtf correctly displays the text. It is the File/Open menu that reluctantly displays a blank page. An SSD reformatting + a full macOS re-install did not cure that problem. Any help will be much appreciated! Thanks A

Thanks Claude31, I will try that solution which, as you say, is not perfect. Since the folder may contain several file sets, this means asking first for the folder then asking for the file or file set. sandboxing is a real headache (at least for me). I agree with you.

Hi Quinn, Thank you for your answer. I will try bundling each auxiliary binary but this may imply making the macOS version quite different from the versions for other platforms, something I hoped I could avoid. A remaining couple of questions: 1- when myMainApp calls myAuxBin shall it be through a Finder command "open" or can I still use a direct call to the binary within the MacOS folder ? 2- One of these auxiliary binary uses a classical Open dialogue to open a file but also opens with no dialogue a set of other files with the same name but different extensions. Is this compatible with sandboxing or is there a trick I should know ? All the best Linus