App not Upload And Sign

Hello

I am writing an application for MacOs. I am trying to upload application to the app store.
Application include a GUI ( written in swiftUI ) , 2 binary executable files ( written in c++) and multiple dylibs and frameworks.
We enable sandbox for xcode project (GUI).

Our app perfectly run in local system with no signing. But when I sign app, application not running.

Code Block language
Date/Time: 2021-05-12 20:51:28.939 +0430
OS Version: Mac OS X 10.15.3 (19D76)
Report Version: 12
Anonymous UUID: 834384F2-5954-0185-35C5-B2AF77021892
Sleep/Wake UUID: 00BA8D61-4945-41C9-9DA4-96417724397B
Time Awake Since Boot: 110000 seconds
System Integrity Protection: enabled
Crashed Thread: 0
Exception Type: EXC_CRASH (Code Signature Invalid)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace CODESIGNING, Code 0x1
kernel messages:
VM Regions Near 0 (cr2):
-->
__TEXT 0000000103003000-00000001034a1000 [ 4728K] r-x/r-x SM=COW
Thread 0 Crashed:
0 0x000000010f314000 _dyld_start + 0
Thread 0 crashed with X86 Thread State (64-bit):
rax: 0x0000000000000000 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x00007ffeecbfcba8
r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000
rip: 0x000000010f314000 rfl: 0x0000000000000200 cr2: 0x0000000000000000
Logical CPU: 0
Error Code: 0x00000000
Trap Number: 0




And when I archive the app for uploading to app store, it is failing Archive validation for the app store with the message "App sandbox not enabled. The following executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true in the entitlements property list".

One of binary executable compiled with "Unix makefile" compiler, and other one with xcode.

I tried to enable sandbox for binary executable in xcode. But didn't work after I enabled sandbox.

error when runs in terminal:

Code Block language
zsh: illegal hardware instruction


error when runs in xcode:

Code Block language
libsystem_secinit.dylib`_libsecinit_appsandbox.cold.5:
0x7fff70e300e8 <+0>: pushq %rbp
0x7fff70e300e9 <+1>: movq %rsp, %rbp
0x7fff70e300ec <+4>: pushq %r14
0x7fff70e300ee <+6>: pushq %rbx
0x7fff70e300ef <+7>: movq %rdx, %r14
0x7fff70e300f2 <+10>: movq %rsi, %r9
0x7fff70e300f5 <+13>: movq %rdi, %rbx
0x7fff70e300f8 <+16>: leaq 0xc41(%rip), %r8 ; "%s"
0x7fff70e300ff <+23>: movl $0x800, %esi ; imm = 0x800
0x7fff70e30104 <+28>: movl $0x800, %ecx ; imm = 0x800
0x7fff70e30109 <+33>: movl $0x0, %edx
0x7fff70e3010e <+38>: xorl %eax, %eax
0x7fff70e30110 <+40>: callq 0x7fff70e30396 ; symbol stub for: __snprintf_chk
0x7fff70e30115 <+45>: movq %r14, 0x29c169d4(%rip) ; gCRAnnotations + 16
0x7fff70e3011c <+52>: movq %rbx, 0x29c169c5(%rip) ; gCRAnnotations + 8
-> 0x7fff70e30123 <+59>: ud2
Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)


As I understand, sandbox isn't compatible with binary executable files and it is for applications.


Question 1. What is the best signing options for MacOs paid application with in-app purchase?
Question 2. What are possible scenarios for getting these errors?
Question 3. Am I missed some other options?
Question 4. Do I need to enable sandbox for binary executable files?
Question 5. How could I manage to upload the app to the app store?


Thanks in advance

Answered by DTS Engineer in 674564022

As I understand, sandbox isn't compatible with binary executable files
and it is for applications.

That’s not quite right. Your setup, an GUI app with a bunch of nested dynamic libraries and command-line tools, is supported by App Sandbox and hence the Mac App Store. That’s true regardless of what tool you use to create these components, including, say, your Unix make files. You just have to package it all up correctly (-:

For general advice on this topic, see my Signing a Mac Product For Distribution post. I’m also able to address your specific concerns here:

I tried to enable sandbox for binary executable in xcode. But didn't
work after I enabled sandbox.

Right. The most likely cause of this is the way that you enabled the App Sandbox on these command-line tools. If you run a tool as a child process, it always inherits the parent process’s sandbox. However, when you submit the app to the Mac App Store, the ingestion process requires that all executables be signed with the com.apple.security.app-sandbox entitlement. But if you sign it with just that entitlement then you set up a conflict. The executable is meant to to inherit its parent’s sandbox but you’ve told it to set up a new sandbox. libsystem_secinit detects this and traps.

The fix is to sign the command-line tool with com.apple.security.app-sandbox and com.apple.security.inherit. The latter tells libsystem_secinit that, yeah, you really want to inherit your parent’s sandbox.

IMPORTANT Use codesign to check that the command-line tool has set just those two entitlements:

Code Block
% codesign -d --entitlements :- /path/to/your.app/Contents/MacOS/your-tool


The presence of other entitlements can cause libsystem_secinit to trap in a similar way.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Accepted Answer

As I understand, sandbox isn't compatible with binary executable files
and it is for applications.

That’s not quite right. Your setup, an GUI app with a bunch of nested dynamic libraries and command-line tools, is supported by App Sandbox and hence the Mac App Store. That’s true regardless of what tool you use to create these components, including, say, your Unix make files. You just have to package it all up correctly (-:

For general advice on this topic, see my Signing a Mac Product For Distribution post. I’m also able to address your specific concerns here:

I tried to enable sandbox for binary executable in xcode. But didn't
work after I enabled sandbox.

Right. The most likely cause of this is the way that you enabled the App Sandbox on these command-line tools. If you run a tool as a child process, it always inherits the parent process’s sandbox. However, when you submit the app to the Mac App Store, the ingestion process requires that all executables be signed with the com.apple.security.app-sandbox entitlement. But if you sign it with just that entitlement then you set up a conflict. The executable is meant to to inherit its parent’s sandbox but you’ve told it to set up a new sandbox. libsystem_secinit detects this and traps.

The fix is to sign the command-line tool with com.apple.security.app-sandbox and com.apple.security.inherit. The latter tells libsystem_secinit that, yeah, you really want to inherit your parent’s sandbox.

IMPORTANT Use codesign to check that the command-line tool has set just those two entitlements:

Code Block
% codesign -d --entitlements :- /path/to/your.app/Contents/MacOS/your-tool


The presence of other entitlements can cause libsystem_secinit to trap in a similar way.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Thanks for your helpful post. I followed your Manual Code Signing Example post step by step and I signed my files with "Apple Distribution: TTT", is that OK?
then I replaced the app with path/to/myapp.xcarchive/Products/Applications/myapp.app. After that, I opened Organizer to upload myapp to the App Store. Now I don't get sand-boxing errors for my Command-line tools, but library errors exist. (my tools depends on libraries)

ERROR ITMS-90000: "This bundle is invalid. The executable code in [myapp.app/Contents/Frameworks/1.dylib, myapp.app/Contents/Frameworks/2.dylib, myapp.app/Contents/Frameworks/3.dylib] contain unsupported content."

How can I resolve this problem?

Thanks
I’ve removed this response because I plan to replace it with a better one soon.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple 768613894
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I’ve removed this response because I plan to replace it with a better
one soon.

Well, that got too large so I put it in its own post: Embedding a Command-Line Tool in a Sandboxed App.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Any News?

codesign -s "Apple Distribution" -o runtime --entitlements AA.entitlements -f "AA"
./AA 
zsh: illegal hardware instruction  ./AA

Any News?

Well, yes. I’ve recently replaced the above-mentioned DevForums post with official documentation, namely Embedding a Command-Line Tool in a Sandboxed App.

However, that seems unrelated to your issue, in that this thread is about the signed product crashing and your issue seems to be related to the codesign tool itself crashing. I encourage you to start a new thread about that, making sure to:

  • Tag it with Code Signing so that I see it.

  • Include a crash report for the crash, using the instructions in Posting a Crash Report.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I have done also the steps of the official documentation.

This option "--entitlements AA.entitlements" creates a damaged executable for Apple Silicon.

No issue on intel!

App not Upload And Sign
 
 
Q