Fortunately, I am familiar with the differences between an agent and a daemon. 😄 I am very relieved to know I wasn't reading things incorrectly about SMBlessJob. The basics of what I was trying to achieve: we'll have a daemon, which will be used to do things like start and stop the proxy as needed, coordinate information about the system account and related settings, check for updates (if we don't end up using App Store deployment, which seems likely to be the case), and various other things. It'll need entitlements because -- once I get the bit from Apple -- I'll also have it doing anti-tampering using Endpoint Security. All of that is pretty simple and basic. What I had hoped to do, however, was allow a drag&drop installation. In that case, when the container application was launched, it would check to see if various files were installed, and if not, do that itself. But to do that it would need user permission, and the call I would have used has been deprecated. I think I can do that using a helper-tool with privilege, but I haven't mapped that out yet (for clarification: the "think I can do that" means that, yes, I am fairly positive it's technically possible, but I haven't figured out what the details are or what the code would look like). Instead, at least for now, I think we'll have to rely on a pkg installation method, which can run a script to install a plist in /Library/LaunchDaemons as well as a few other things. The preferred installation mechanism will presumably be via MDM. Which means that's going to be one of the next things I have to ask about, but that's for another time. 😄 I hadn't at all thought about having it claim it's a system extension. But since I want that tasty Endpoint Security capability... that might work, mightn't it? In which case, the daemon would be part of the app bundle, and then get it installed using OSSystemExtensionRequest. (If you could see my face right now, you'd see my eyes wide and looking up to my left...)

Well it's not an ES sysex yet because I'm still waiting for Apple to give it to me. It's been 5 or 6 weeks, although I recognize the holidays mess everyone's schedules up. Is it possible to customize an ES sysex launchd file? This is for future reference, I'm not sure that I do need any such customization -- my initial thought had simply been to have a simple launchd.plist that said "run this all the time" and install that via the pkg installer. I'm rewriting my containing app's extension loader code right now, to handle multiple extensions.

Well that's a nice, simple answer for that, at least. 😄

FSRef is also deprecated (and comes with the warning that it's not on friendly terms with APFS), so the question is: where are you getting your FSRef?

I'm using # What I *want* to do is have this copied somewhere. # But I don't know how to tell XCode to do that. set_target_properties(LibraryControl PROPERTIES     XCODE_ATTRIBUTE_SWIFT_OBJC_INTERFACE_HEADER_NAME "LibraryControl-Swift.h"     XCODE_ATTRIBUTE_DERIVED_FILE_DIR "${PROJECT_BINARY_DIR}"     XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER "${PROJECT_SOURCE_DIR}/common/mac/LibraryControl-Bridging-Header.h" ) and then set target_include_directories appropriately in the other CMakeLists.txt files.

I am still getting this problem. 13C100, downloaded it fresh today. And yet it works on another machine. sigh.

Ok, sorry for the confusing use of pronouns. I should have paid them more. I added the com.apple.developer.endpoint-security.client entitlement to the entitlements file for the app. I created a profile, using the portal, that had Endpoint Security as an additional entitlement; it was signed with our Developer ID certificate. I downloaded the newly-created profile, and examined it using emacs: it did not have the com.apple.developer.endpoint-security.client entitlement in it. For the executable (which kept getting killed, of course), I saw that there was a complaint about signature and profile mismatch in system.log, so I used codesign and cms to look at the entitlements and profile for the executable, and the com.apple.developer.endpoint-security.client entitlement was not in the cms output.

It's a launchd-driven app Two screenshots attached here, one showing an edited version of the downloaded provisioning profile, and the other showing the app id from the developer portal

I thought ES was only available on macOS. Here it is:

I just did all that, and got the same results I have been getting. I have tried creating a brand new one, and deleting the old one(s) and recreating, I have tried having App Groups + System Extension, I have tried with only Endpoint Security. I have looked at the downloaded file using vi, and with 'security cms'. I am, at this point, going to make a screen recording, and file a TSI. I really hope it'll be obvious what I'm doing wrong 😩.

Quinn discovered it! I only got permission for it for development, while I was creating the profile with distribution. Now to figure out how to get it for distribution... (Since Quinn and I are 8 hours apart, temporally, this took back&forth a couple of days communicating via TSI.)

In my defense, I missed the word "only" in "approved for development only" -- the one I need it for is a "Developer ID" and that shares many of the same letters.

Yes, it turns out I can, by using event.attributeDescriptor(forKeyword: keyword) on the NSAppleEventDescriptor, which gives me an audit_token_t, from which I can at least sometimes get security (eg SecCode). Answer from @eskimo via TSI, which was SO WORTH IT.

Being lazy, I was hoping for pre-canned code. 😄 I've got notes to digest about it all, at least.

Nobody has any thoughts about this? 😩