Working, signed, notarized app will not run on another system

sh-3.2# security cms -D …

This suggests that you’re doing things from a root shell. Is that because you’ve enabled the root account, logged in as root, and are doing everything from there? Or are you spinning up a root shell using sudo -s or similar techniques? I recommend against the latter because sudo only changes part of your execution context [1].

I have tried to verify the entitlements, but I get this output:

That’s problematic. When you use a restricted entitlement, like com.apple.developer.endpoint-security.client, you must also have an App ID entitlement so that the trusted execution system can match up your code with your provisioning profile. For more background on this, see What exactly is a provisioning profile?

Xcode should have added that entitlement for you. Indeed, Signing a Daemon with a Restricted Entitlement has code that prints the entitlements and an example of its output:

2021-08-04 16:24:10.979941+0100 DaemonInAppsClothing[50219:4886989] entitlements: {
    "com.apple.application-identifier" = "SKMME9E2Y8.com.example.apple-samplecode.DaemonInAppsClothing";
    "com.apple.developer.networking.custom-protocol" = 1;
    "com.apple.developer.team-identifier" = SKMME9E2Y8;
    "com.apple.security.get-task-allow" = 1;
}

Are you still building this code with Xcode? Or have you transitioned over to your own build system?

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

[1] For more details on execution contexts in macOS, see the Execution Contexts section of Technote 2083 Daemons and Agents.

• I am using sudo -su
• I did not add "com.apple.developer.team-identifier" to my entitlements.
• I am using xcode to build and archive, but I am manually signing and notarizing. I created a disk image using a script I found in another of your posts: (Manual Code Signing Example)

Here is some more information on the executable:

#codesign -dv --verbose=4 ./DaemonInAppsClothing
Executable=/Library/Application Support/DaemonInAppsClothing/DaemonInAppsClothing.app/Contents/MacOS/DaemonInAppsClothing
Identifier=Fidelis.DaemonInAppsClothing
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1032 flags=0x10000(runtime) hashes=21+7 location=embedded
VersionPlatform=1
VersionMin=786688
VersionSDK=786688
Hash type=sha256 size=32
CandidateCDHash sha256=8a7f854608607af4862cc81643c9a694e645b990
CandidateCDHashFull sha256=8a7f854608607af4862cc81643c9a694e645b990a283366dce26b3000f6bff05
Hash choices=sha256
CMSDigest=8a7f854608607af4862cc81643c9a694e645b990a283366dce26b3000f6bff05
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=32768
Executable Segment flags=0x1
Page size=4096
CDHash=8a7f854608607af4862cc81643c9a694e645b990
Signature size=9003
Authority=Developer ID Application: Fidelis Cybersecurity, INC (AMLU8UA7F6)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Feb 28, 2022 at 10:12:08 AM
Info.plist entries=20
TeamIdentifier=AMLU8UA7F6
Runtime Version=12.1.0
Sealed Resources version=2 rules=13 files=944
Internal requirements count=1 size=64

So I think somehow it does know my identity, but something I changed recently won't let it run on 11.X. It now tells me I need version 12.1 or newer for this app.

I am using sudo -su

Do not do this as a matter of course. Our tools are set up so that they work when you log in as a normal user. If you then switch to a root shell you end up running the tools in a non-standard environment, which exposes you to all sorts of potential weirdness.

I am using Xcode to build and archive, but I am manually signing and notarizing.

Xcode should have set up your entitlements correctly. I recommend that you dump the entitlements of the program in the Xcode archive to see how Xcode did it.

Also remember that the code in your Xcode archive should be signed with an Apple Development identity. If you re-sign it with Developer ID, you must also apply a new profile. I go into this in some detail in Creating Distribution-Signed Code for Mac.

So I think somehow it does know my identity

What you showed there is not sufficient to confirm that. You also need to dump the entitlements (by adding --entitlements - to you command). The TeamIdentifier property in the code signature is important, but it’s the App ID in the entitlements that controls whether the system can find your provisioning profile.

It now tells me I need version 12.1 or newer for this app.

Check the deployment target in your Xcode project.

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

Where can I get these samples?

There isn’t a sample associated with that doc, but the instructions in the doc should be sufficient for you to create your own project from scratch.

when I switched out main.swift for my c++ code, and added in the dylib files, they do not end up in the archive

OK, those are two separate things.

To investigate the main issue, I recommend that you replace main.swift with a main.m from my old DevForums version of this doc. That’ll confirm that the packaging side of things is working for C-like code. And converting that code to C++ shouldn’t be hard.

As to your dynamic libraries, once you have a working app-like project then you add dynamic libraries to the project as you would in an app, that is:

1. Drag the library into your project.

2. Select the target in question.

3. Go to the General tab.

4. Add the libraries to the Frameworks and Libraries list.

5. Flip the Embed popup to Embed & Sign.

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