What is different between SSH session and GUI Terminal session ? The main difference is that the login keychain is unlocked. You can do the same thing by unlocking the login keychain in your ssh session. However, what I don't know -- and would really like to know -- is what codesign is looking for in the login keychain that isn't in the other keychain. So I could move it to that keychain and not have to worry about the login one for building.

I was referring to "Signing a Daemon with a Restricted Entitlement." The bundle is signed. I'll go over your article again; I've confirmed it's the entitlements it doesn't like. (It turns out I don't currently need the entitlements yet -- but the plan is to use Endpoint Security in it eventually, I just don't have that permission yet.)

Mostly I'm playing around here -- I wanted to log if that sort of discrepancy came up. And then I wanted to find the path to the possibly-offending process, and flag it for examination. And I knew I could go from bundle ID to path, and vice versa, and that was the reason I was asking.

Also... if the code signing identifier can't be trusted, why is that what the OS gives network extensions? (I guess it also gives the audit token, but that's opaque and I'm still not clear on what is and is not supposed to be obtainable from it. :))

Because NEFlowMetaData originated on iOS where the code signing identifier can be trusted. Ok that actually occurred to me last night as I was unable to sleep. 😄 The NE flow metadata also has the sourceAppUniqueIdentifier -- I assume there's a way to go from a filesystem path to that? One of your posts mentions a cdhash which I presumed was the same thing, but I didn't see how to get either one. Thanks!

You can use the audit token as a cache key to avoid taking these slow paths every time. Yeah, my experimental setup uses multiple processes (why? Because I am experimenting in it 😄), so one thing I was thinking of trying would be used for a block/allow list, and have the C&C process say "This app/executable is going to be treated differently somehow," and then send that down to the provider, to use for cache checking. (Rather than doing it in the provider, which I already think takes way too long, which is why I am also playing around with Instruments.) But it looks like I can't safely/reliably do that.

(I realize I could look in /Applications and /System/Applications, but on macOS an app can be in other locations and still be usable. And, I'd also kinda like to know what happens if there are multiple matches for it on the system. This seems like the kind of thing Launch Services would handle, but a medium-length check didn't show anything.)

So, given that, how -- and I realize this is a really broad question -- do you determine if an app's signature is, uh, legitimate? I've stared at that for several minutes now; I know there's a big step I'm not taking to frame it correctly, and I think that would also answer it. 😄 Pardon me while I break down my thoughts a bit. A signature would be "uh, legitimate" if it is either signed by Apple, or signed by the team that said it did. (I mean, I assume I can't create a team called "com.apple.sean" or, I suppose more importantly, can't claim to be com.google and have an app called "Google Chrome" with a bundle identifier of, say, "com.kithrup.hahahaha.fooled.you" but a signing identifier of "com.google.chrome". It is an assumption.) I can throw this in its own post and expand on my uncertain thoughts if that would be better.

That gets done in the part that will receive the data? And if I call that, I have to also specify String/NSString, Int/NSInt, etc., in addition to my custom classes? I will be googling for examples later, since I have just woken up, but thanks as usual. 😄

I am in fact failing to find examples of setClasses(_:for:argumentIndex:ofReply:) for Swift. The big thing I'm running into is that the .class member of a class is not hashable. Specifically: note: only concrete types such as structs, enums and classes can conform to protocols

And, ok, I got that solved.         let exportedInterface = NSXPCInterface(with: MyProtocol.self)         let allowedClasses = exportedInterface.classes(for: #selector(setList(_:withReply:)), argumentIndex:0, ofReply:false)         let newSet = allowedClasses.union(NSSet(object: MyClass.self) as! Set<AnyHashable>)         exportedInterface.setClasses(newSet, for:#selector(setList(_:withReply:)), argumentIndex:0, ofReply:false)         newConnection.exportedInterface = exportedInterface (I have to do the same in ObjC for the "user" side, because it can get a list of MyClass in a reply, but ObjC is a lot easier, and better documented as well, for this.) Thanks 😄

Ah ha! MDQuery, searching for kMDItemDisplayName and/or _kMDItemDisplayNameWithExtensions should do the trick. I haven't written the code for it yet, but that should do the trick.

Check that this helper app or daemon is placed in the correct location inside the bundle as described here. That link doesn't mention daemons, though. If an app has something that is intended to run at boot time, I had assumed a launchd plist would be installed by the app into /Library/LaunchDaemons -- is /Applications/AppName.app/Contents/Library/LaunchDaemons intended instead?

My question is complicated by me (currently anyway) having the daemon as an app bundle, embedded inside my wrapping app so it has its own set of resources. But I can deal with that by simply asking for the bundle for the main app by its bundle ID, I presume, and having something like MyApp.app/Contents/Library/Daemon/Resources. I had gone for the app-like approach because of a post Eskimo wrote, that I can't find right now but I probably have stashed in my copious and disorganized notes.

No, that's right, I need to use the app-like structure because of entitlements. So given that, I don't think I can use SMJobBless?