There are a few parts here with how you expect your tool to 1) find a/the keychain 2) access it 3) have permission. If you're running a LaunchDaemon (not a LaunchAgent) without specifying the user, it runs as root. That implies you're using the system keychain, not your personal login one. User interaction not allowed means your process is trying to prompt for access (it wasn't granted it already), and user interaction has been disallowed (common when you're not running in a GUI-capable session, can also be specified at runtime using the relevant API in the Security framework). Daemon processes should always be given access to the keychain items they need beforehand, and shouldn't require user interaction.

Have you confirmed the certificate chain is correct using Keychain Access or another diagnostic tool? Certificate Assistant can evaluate an identity and show the chain it's constructed, as proof. For the Developer ID part, depending how AIR signs the product it may be re-signable after you've used your Apple Development or other identity, as a last step. For example, productsign(1) will happily re-sign a PKG to a new file, and that could side-step a broken chain-construction algorithm in the adt tool.

It might help if you described your threat/security model. You say the scripts are signed, but who's signing them and who's writing them? The NSUser*Task classes are meant for scripts the current user put in the Application Scripts folder themselves, by hand. Sandboxed apps can't write to that folder, but can read from it and run the task classes on the entries there. I think the most you're allowed to do is ask for the folder to be created, then reveal it in Finder.

The Team in the signature of the dylib definitely needs to match, you should get detailed error messages if you run your app in the debugger with the hardened runtime enabled; it will list why a particular candidate was inappropriate. Make sure you're comparing the verbose output of codesign -d in the app and dylib LC_VERSION_MIN_MACOSX was replaced by LC_BUILD_VERSION, they should be equivalent for these purposes. I don't think it's possible to build a Mach-O binary without one of them. Relative paths should be fine, though @rpath is generally a better idea (any of the dylibs in Xcode.app/Contents/Frameworks are a good example), e.g. libclang.dylib is "@rpath/libclang.dylib" with an rpath of "@loader_path/../lib" Something like OpenSSL really deserves to be a framework, if you can manage it

Relying entirely on codesign --verify is not a good guide (as I've previously experienced). It doesn't check whole classes of issues related to signatures, dynamic libraries, entitlements, and code signature requirements Since you're building manually (makefiles or other, not Xcode), you're likely missing a particular flag or step. Replacing libcrypto with an empty dylib target built by Xcode might be one way of narrowing down the issue In my experience, library validation issues are best troubleshooted in the debugger, since dyld is pretty explicit when it can't find something I'm pretty sure --display (-d) and --sign (-s) are mutually-exclusive modes of codesign What was the exact issue you saw? You said your app stops loading the dylib, but how did you find out?

Assuming this is related to SIP and Filemaker wasn't evicted from /System (which I think it should have been, depending on your version of macOS), it was probably marked with the extended attribute com.apple.rootless which protects system files from being manipulated. I've seen some machines with the protection applied to some files incorrectly on early versions of High Sierra, but are you sure you can't delete it as the root user? Have you asked Filemaker support about the issue, because deleting it may be unexpected for your installation? Otherwise you would have to boot into recovery and delete it from the command line.

Are you sure that's correct? I can't think of anything in libcrypto (which is supposed to be more fundamental than libssl) that would require JIT-like exceptions to the hardened runtime.

I had a similar issue when IKImageBrowserView was deprecated and I had to move to CollectionView. After checking many different methods, I ended up subclassing CollectionView to override NSDraggingDestination then testing the -collectionViewLayout's -layoutAttributesForDropTargetAtPoint: representedElementCategory and representedElementKind. Super can be called at every step and tested if the result qualifies as a group/section destination so you're not forced to reimplement everything, just make sure to tell the delegate to accept the drop at the end so it can do the "real" work.

All work is done in the subclass Not necessarily, because after super you're just checking if you need to "correct" the operation and re-dispatch to the delegate Always, because you're just correcting the location/operation part Only used headers, but the principle is the same.

If this is your first time in AppKit, you should read all the drag-and-drop resources first, to understand the lifecycle, and how events are separated from the dragging session, are separated from the data/delegate implementation You're not overriding any of the NSResponder events, just the NSDraggingDestination parts: -draggingEntered:, -draggingUpdated:, -draggingEnded:, and -performDragOperation: None of this override deals with the data, just the dragging location and operation. If you detect that the current mouse location for dragging is on a header (see my mention of layout attributes), handle things differently from what the superclass does.

Dragging the header is much more complex, to the point where you'd probably have to maintain extra state just to identify the session, which would start in the CollectionView's mouse event methods. The existing delegate methods won't necessarily be able to differentiate, which is another issue: drag item {onto item, before/after item, onto section}, drag section: {before/after section, onto section, onto item?}. Just as your individual item views don't implement NSDraggingSource (or NSDraggingDestination) to be draggable, your header view wouldn't either.

Your link to the entitlement used is pretty clear about it allowing JIT-like behavior, but without the relative safety of using the JIT APIs. Considering the library you're loading is supposed to provide security primitives, it's worth examining why it's triggering an exception that: In rare cases, an app might need to override or patch C code, use the long deprecated NSCreateObjectFileImageFromMemory (which is fundamentally insecure), or use the DVDPlayback framework. Add the Allow Unsigned Executable Memory Entitlement to enable these use cases. Otherwise, the app might crash or behave in unexpected ways. and Including this entitlement exposes your app to common vulnerabilities in memory-unsafe code languages. Carefully consider whether your app needs this exception.

It depends what the additional component contains. DMGs are a good way to distribute components that users can manage themselves (like dragging an APP into /Applications), but XIP is a special case: The xip tool is used to create a digitally signed archive. As of macOS Sierra, only archives that are signed by Apple are trusted, and the format is deprecated for third party use. Another format is PKG, but that assumes the user will be installing components which require administrator privileges. Is there a limitation preventing the component from being bundled with the app?

More generally, the error codes returned by various Security APIs can usually be converted to something human-readable by SecCopyErrorMessageString. When all you have is a negative integer, it will at least turn it back into the enum as a string. The specific error CSSMERR_CSP_INVALID_ATTR_PADDING suggests padding was the issue.

Yes, you're supposed to use a special extended attribute which is a UUID to "personalize" the separate app stubs. See the section "Moving Away From Custom Resource Rules" of TN2206 macOS Code Signing In Depth - https://developer.apple.com/library/archive/technotes/tn2206/_index.html for a description of com.apple.application-instance