I'm trying to enable SSL encryption on the Apache server and I get the following error message: uwerasche@raschesserver ~ % sudo apachectl configtest [Sun Mar 05 15:08:46.892791 2023] [so:error] [pid 15411] AH06665: No code signing authority for module at /usr/libexec/apache2/mod_cache_socache.so specified in LoadModule directive. httpd: Syntax error on line 98 of /private/etc/apache2/httpd.conf: Code signing absent - not loading module at: /usr/libexec/apache2/mod_cache_socache.so What can I do? Uwe

Yesterday I sent an audio .AU plugin to a beta tester. It was packaged in a .pkg installer that was code-signed, notarized, and stapled. I sent it to them via Google Drive. The tester reported that it installed okay. But when they try to open an instance of the plugin in Logic, they got an error saying: "Load Plugin Error. Failed to load plug-in: detected corrupted plug-in data." followed by a message saying to contact the manufacturer. The plugin loads fine on my end (we are both using Logic, M1 native, OS 12.6.3). My best guess is that Google Drive did a virus scan and that somehow caused Gatekeeper to reject the file (although it still allowed the tester to install it as if everything was normal). I then sent the exact same file to the tester via another method (not Google Drive) and the plugin loads fine, as expected. This is the second time I've experienced something like this with the newer Macs rejecting an otherwise valid file seemingly because it was loaded onto Google Drive. Any ideas what's going on here? Should Google Drive be off-limits for my plugins? Like, I'd need to tell my users that the plugin might not work if they ever put it on Google Drive? Thanks.

Is there any additional work that developers need to do to enable File Quarantine for their apps besides adding LSFileQuarantineEnabled to their Info.plist (and all the helpers)? All files made by the app's processes should be quarantined by macOS without any additional changes to the app by the developer correct? Thanks!

I've got a Developer ID Application certificate - however when I open the details in KeyChain it tells me "Developer ID Application XXXXXXX certificate is not trusted" When I try signing my code with this certificate, using codesign -s MY_CERTIFICATE_NAME -v --deep --timestamp --entitlements entitlements.plist -o runtime "path/to/MyApp.app" --force I get Warning: unable to build chain to self-signed root for signer MY_CERTIFICATE_NAME It does work when I use another certificate - one that is trusted (however with that other certificate, I get problems in notartizing, apparently because it is an "Apple Development" certificate and not a "Developer ID Application" certificate). How can I make my certificate trusted? All online advice I can find online doesn't help: Find any other certificates and change their trust settings from "Always Trusted" to "Use System Defaults" (however they all are on "Use System Defaults" already). Adding intermediate signing certificates to KeyChain as in - https://stackoverflow.com/a/66083449/851699 - I've tried this, and my problem persists.

I get that Mac wants to keep users safe, but -- for the love of god -- at least give the option to "allow anyway" and let the user override gatekeeper and make the final call for themself. It's aggravating that I can't even run code I wrote myself that I know for a fact isn't malicious. I want to be able to make the decision myself whether to run, even if gatekeeper doesn't like it.

I have an app that seems to be properly signed and notarized which I installed using Homebrew. Upon the first launch macOS warned that the app was downloaded from the internet and asked whether I want to proceed, to which I agreed. Subsequent launches do not show this warning. However, launchd refuses to launch its login item: 2023-01-11 10:23:16.258575 (gui/501/org.p0deje.Maccy-LaunchAtLoginHelper [16190]) <Warning>: Could not find and/or execute program specified by service: 155: Refusing to execute/trust quarantined program/file: org.p0deje.Maccy-LaunchAtLoginHelper Indeed, the com.apple.quarantine is still set on the app itself and all is contents, including this helper: $ ls -la@ /Applications/Maccy.app total 0 drwxr-xr-x@ 3 kentzo staff 96 Aug 31 14:20 . com.apple.macl 72 com.apple.provenance 11 com.apple.quarantine 67 drwxrwxr-x 84 root admin 2688 Jan 11 10:20 .. drwxr-xr-x@ 11 kentzo staff 352 Aug 31 14:29 Contents com.apple.quarantine 67 codesign and scptl seem to be happy though: $ codesign --verify -vvv /Applications/Maccy.app --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftObjectiveC.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftObjectiveC.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreImage.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreImage.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftXPC.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftXPC.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCore.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCore.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftAppKit.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftAppKit.dylib --prepared:/Applications/Maccy.app/Contents/Library/LoginItems/LaunchAtLoginHelper.app --validated:/Applications/Maccy.app/Contents/Library/LoginItems/LaunchAtLoginHelper.app --prepared:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.Downloader.xpc --validated:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.Downloader.xpc --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreGraphics.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreGraphics.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftMetal.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftMetal.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreData.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreData.dylib --prepared:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerConnection.xpc --validated:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerConnection.xpc --prepared:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerStatus.xpc --validated:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerStatus.xpc --prepared:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerLauncher.xpc --validated:/Applications/Maccy.app/Contents/XPCServices/org.sparkle-project.InstallerLauncher.xpc --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftos.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftos.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftDispatch.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftDispatch.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftDarwin.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftDarwin.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreFoundation.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreFoundation.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftQuartzCore.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftQuartzCore.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/Sparkle.framework/Versions/Current/. --validated:/Applications/Maccy.app/Contents/Frameworks/Sparkle.framework/Versions/Current/. --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftIntents.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftIntents.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftIOKit.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftIOKit.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreLocation.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftCoreLocation.dylib --prepared:/Applications/Maccy.app/Contents/Frameworks/libswiftFoundation.dylib --validated:/Applications/Maccy.app/Contents/Frameworks/libswiftFoundation.dylib /Applications/Maccy.app: valid on disk /Applications/Maccy.app: satisfies its Designated Requirement $ codesign --display -vvv /Applications/Maccy.app Executable=/Applications/Maccy.app/Contents/MacOS/Maccy Identifier=org.p0deje.Maccy Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=6460 flags=0x10000(runtime) hashes=191+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=fab018cde6fe6239b18e2a5a9055b9b6c0ca7ee2 CandidateCDHashFull sha256=fab018cde6fe6239b18e2a5a9055b9b6c0ca7ee2f1d34d9cb8e114a1f72b28b5 Hash choices=sha256 CMSDigest=fab018cde6fe6239b18e2a5a9055b9b6c0ca7ee2f1d34d9cb8e114a1f72b28b5 CMSDigestType=2 Launch Constraints: None CDHash=fab018cde6fe6239b18e2a5a9055b9b6c0ca7ee2 Signature size=8981 Authority=Developer ID Application: Alexey Rodionov (MN3X4648SC) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Aug 31, 2022 at 2:21:06 PM Info.plist entries=29 TeamIdentifier=MN3X4648SC Runtime Version=12.3.0 Sealed Resources version=2 rules=13 files=186 Internal requirements count=1 size=208 $ spctl -a -t exec -vvv /Applications/Maccy.app /Applications/Maccy.app: accepted source=Notarized Developer ID origin=Developer ID Application: Alexey Rodionov (MN3X4648SC) Other apps with login items that I downloaded with Safari and manually moved to /Applications seem to work properly. What could be wrong with Homebrew's installation process? Tested on 13.1 with M1 processor, homebrew 3.6.15

I have an Electron app that ships with some nested binaries. It is still correctly signing and notarizing, but some users are seeing a warning on Ventura. The app ships as a DMG. Because of some issues with path randomization, the first thing our app does is check if the app is running from /Applications and propmt to move . If the user double clicks on the app instead of moving it in the DMG's UI, they get this prompt. Once they move it to applications, they see a prompt "My App Name" was prevented from modifying apps on your Mac. Except my app was not prevented from modifying apps - it successfully moves to the /Applications directory. There is some other bizarre behavior associated with this: After seeing the warning, my app is added to "Privacy &amp; Security &gt; App Management" in settings with the box unchecked. However, future attempts to reproduce the bug above do not work untli this is removed from the list entirely. If I move the application out of the DMG to ~/Desktop, then start it, clicking 'move to applications' folder does not show the prompt What I have done to debug this: I think it has something to do with gatekeeper, because if I produce the DMG locally without downloading it from the internet I don't see the warning I've looked through console.app when the prompt shows up but haven't found much useful

I want to use NSTask to run a shell script that resides in Resouces directory. The script performs some operations on files in the app's Data directory.But I am concerned that Apple could refuse my app for some reasons. Can anyone confirm if this approach is safe. Thanks.

Hello! I have a baffling situation happening on two different computers in which Xcode (14.2.0, on MacOS 12.6.1) is not being able to attach a debugger. This is happening for completely-fresh-from-scratch apps, both for MacOS and iOS apps. In both cases, the app eventually launches, but Xcode is not able to debug. Following the error message's suggestion, I looked in Console.app and as best as I can tell the proximate cause for the issue is task_for_pid failing; this message is preceded by a number of errors from com.apple.dt.instruments.dtarbiter: Code validity check error: Error Domain=NSOSStatusErrorDomain Code=-67050 "(null)" So my working hypothesis is that something is preventing the application from launching "normally" and so the debugger can't attach as it normally would. Things I have tried: Removing DerivedData, rebuilding Making sure that "Developer Mode" is enabled (via DevToolsSecurity -enable) Ensuring that the resulting binary has the com.apple.security.get-task-allow entitlement, and that "Code Signing Inject Base Entitlements" is set to "Yes" Disabling Gatekeeper system-wide I have also spent a while looking around with codesign and spctl. To my (admittedly non-expert) eye, codesign's output looks about right: [~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % codesign -d -vvv --entitlements :- Build/Products/Debug/ContentView.app/ Executable=/Users/bedricks/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj/Build/Products/Debug/ContentView.app/Contents/MacOS/ContentView Identifier=org.bedrick.ContentView Format=app bundle with Mach-O thin (x86_64) CodeDirectory v=20500 size=1091 flags=0x10000(runtime) hashes=23+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=cf6f08586662c29420bf3ab7e673d0614b2c7717 CandidateCDHashFull sha256=cf6f08586662c29420bf3ab7e673d0614b2c771758ec9dce33fa7982fdab2267 Hash choices=sha256 CMSDigest=cf6f08586662c29420bf3ab7e673d0614b2c771758ec9dce33fa7982fdab2267 CMSDigestType=2CDHash=cf6f08586662c29420bf3ab7e673d0614b2c7717 Signature size=4785 Authority=Apple Development: Steven Bedrick (X8L6RQQBAR) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=Jan 9, 2023 at 2:03:55 PM Info.plist entries=19 TeamIdentifier=2E7A87Y536 Runtime Version=13.1.0 Sealed Resources version=2 rules=13 files=0 Internal requirements count=1 size=188 Warning: Specifying ':' in the path is deprecated and will not work in a future release &lt;?xml version="1.0" encoding="UTF-8"?&gt;&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;&lt;plist version="1.0"&gt;&lt;dict&gt;&lt;key&gt;com.apple.security.app-sandbox&lt;/key&gt;&lt;true/&gt;&lt;key&gt;com.apple.security.files.user-selected.read-only&lt;/key&gt;&lt;true/&gt;&lt;key&gt;com.apple.security.get-task-allow&lt;/key&gt;&lt;true/&gt;&lt;/dict&gt;&lt;/plist&gt; If I ask codesign to --verify my .app bundle, this is what I get: [~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % codesign -vvvv -R="notarized" --check-notarization -vvvv Build/Products/Debug/ContentView.app/ Build/Products/Debug/ContentView.app/: valid on disk Build/Products/Debug/ContentView.app/: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) [~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % So something does appear to be "up" with the signature/notarization, but I am not sure how to get more information about what the issue might be (turning up the command's verbosity does not give more information). Now, turning to spctl: [~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % spctl -a -v --raw Build/Products/Debug/ContentView.app/ Build/Products/Debug/ContentView.app/: rejected &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;assessment:authority&lt;/key&gt; &lt;dict&gt; &lt;key&gt;assessment:authority:flags&lt;/key&gt; &lt;integer&gt;0&lt;/integer&gt; &lt;/dict&gt; &lt;key&gt;assessment:remote&lt;/key&gt; &lt;true/&gt; &lt;key&gt;assessment:verdict&lt;/key&gt; &lt;false/&gt; &lt;/dict&gt; &lt;/plist&gt; So Gatekeeper is clearly "unhappy" with this file; I had thought that apps launched via Xcode itself were supposed to bypass Gatekeeper, but maybe that's not true? And in any event, I am able to launch the resulting .app file from the Finder without any issues. This is happening on two separate computers, so my next thought was that it might be some kind of issue with my Apple ID? But on a third computer my same Apple ID works just fine for signing and running apps for local development. As best as I can tell I've got them all configured the same way in terms of which certificate/team they are using, etc. though it is certainly possible that I messed that up somehow. They're all running the same version of Xcode and MacOS. One (possibly relevant) difference is that the two non-working machines are managed by my work's IT department, and my user there is part of an ActiveDirectory profile of some kind. The working machine is my own personal laptop. All three machines have Gatekeeper enabled (I tried turning it off system-wide and it did not fix it), and on all three machines my user is part of the "admin" and "_developer" groups, at least according to the groups command. I don't know what-all sort of remote management / security software they may have installed, is it possible that something along those lines could globally prevent task_for_pid attachment? Any thoughts, advice, debugging ideas, magical shell invocations, etc. would be most welcome. Thank you!

My application contains a binary which calls a shell script located in the "Resources" folder through the command: open -b com.apple.terminal '../Resources/myScript.sh' which opens the script in a Terminal window. This works on a M1 computer and on Intel macOS prior to Ventura. On an Intel Mac upgraded to Ventura 13.2 I get the error message: "myscript.sh" can’t be opened because (null) is not allowed to open documents in Terminal. Adding the entitlement &lt;com.apple.security.automation.apple-events&gt; had no effect. Since this works on macOS other than Ventura for Intel I don't see which hardening key or whatsoever is missing. What can I do to get rid of that error ? All the best

I'm currently having a project where we will distribute a package including a compiled binary. However when compiling it for OS X. We always get a warning when opening it. "{Libraryname} cannot be opened because developer cannot be verified". We have tried to sign it with our apple developer team certificates but without success. Tried following guides for Building mac OS apps and iOS apps but dosen't seem to apply for pure binaries as expected.

I'm developing a plugin for a 3rd party app that consists of a bundle with a custom file extension (not 'app', specifically.) I'm running into issues with getting the plugin to load when the host app starts. It works fine on the system the plugin is compiled on, but on any other machine I get the "apple can't check app for malicious software" dialog. spctl -vvv --assess --type exec &lt;my plugin&gt; shows: rejected (the code is valid but does not seem to be an app) Other plugins for the same app produce the same output from spctl. This makes sense - a plugin is not an app. Aside from that, all the signing, notarization and stapling steps outlined here (https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow) complete with no issues. Any ideas on how to get the plugin to load? How are shared libraries supposed to be signed and notarized, anyway? The documentation mostly assumes that people are interested in notarizing apps and there's very little mention of anything that's not an app. Thanks, Ori Pessach

Whenever I launch my system preference pane application i am getting console message (Only shows in Mac OS X Catalina):com.apple.xpc.launchd[1] (ouc.plist): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.com.apple.xpc.launchd[1] (ouc.plist[16059]): Service exited with abnormal code: 126Its runs the app but its take long time to run.Could anyone help how this generated and what ouc.plist is?

Hey there! I'm really desperate, like plenty of developers out there with the new notarization process. I read almost all threads about it with no luck. I'm trying to distribute our game and even passing all checks from Xcode and command line programs it's impossible to pass it with zip, 7zip, dmg or AirDrop. The problem of "cannot be opened because the developer cannot be verified" hits. The message is really misleading, the developer and app can be verified. We don't have any online tool or process to simulate the GateKeeper process and tell us exactly what's happening. I tried almost everything I saw on the internet. What is still shocking to me, is that I'm able to notarize and verify, send to App Store and the application cannot be opened on any other computer. Ideas? Help? Really appreciated!

Hello, I'm adding a camera extension to the existing application. The problem that it crashes with the following message in the console: Code has restricted entitlements, but the validation of its code signature failed. Unsatisfied Entitlements: However, it crashes under macOS 11.6 only. Interestingly, it works fine on other devices running macOS 12, 13 and even 11.6.1. I haven't tried it with older macOS versions, however I doubt it's going to work with them either. Is there a way to fix this? If you need any additional information, please let me know. codesign -d --entitlements :- /Applications/AppName.app <key>com.apple.security.device.camera</key> <true/> <key>com.apple.security.device.audio-input</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>7XXXXXXX.com.example.AppName</string> </array> security cms -D -i /Applications/AppName.app/Contents/embedded.provisionprofile <key>Entitlements</key> <dict> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.application-identifier</key> <string>7XXXXXXX.com.example.AppName</string> <key>keychain-access-groups</key> <array> <string>7XXXXXXX.*</string> </array> <key>com.apple.developer.team-identifier</key> <string>7XXXXXXX</string> </dict>

This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Library Loading Problems On macOS the dynamic linker is responsible for loading the dynamic libraries used by your process. There are two parts to this: When a process runs an executable, the dynamic linker loads all the libraries used by that executable, the libraries used by those libraries, and so on. A process may load libraries at runtime using APIs like dlopen and NSBundle. For information the dlopen and friends, see the dlopen man page. The dynamic linker works closely with the trusted execution system to ensure that it only loads appropriate libraries. A critical concern is dynamic library impersonation attacks. If your program references a library, you want the dynamic linker to load that copy of the library, and not some other copy installed by an attacker. The primary protection is library validation. If library validation is enabled on an executable, the trusted execution system only allows the process to load code signed by Apple or with the same Team ID as the executable. Library validation is enabled by the Hardened Runtime but you may opt out of it using the Disable Library Validation Entitlement (com.apple.security.cs.disable-library-validation) entitlement. IMPORTANT Leave library validation enabled. Only disable it if your app needs to load plug-ins from other third-party developers. Disabling library validation makes it harder to pass Gatekeeper. See Resolving Gatekeeper Problems Caused by Dangling Load Command Paths for the details. When the dynamic linker fails to load a library it includes an explanation in the crash report. For example: Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @rpath/libEtranger.dylib Referenced from: /Users/USER/*/LinkToEtranger.app/Contents/MacOS/LinkToEtranger Reason: … (terminated at launch; ignore backtrace) Application Specific Information: Library not loaded: @rpath/libEtranger.dylib Referenced from: … Reason: … This explanation is likely to be truncated by the crash reporting system. To see the full log, run the app from Terminal: % ./LinkToEtranger.app/Contents/MacOS/LinkToEtranger dyld[79650]: Library not loaded: @rpath/libEtranger.dylib Referenced from: …/LinkToEtranger.app/Contents/MacOS/LinkToEtranger Reason: tried: '…/LinkToEtranger.app/Contents/MacOS/../Frameworks/libEtr anger.dylib' (code signature in <E16EDD14-CE5A-33BC-9B06-554A3BC12C51> '…/LinkToEtranger.app/Contents/Frameworks/libEtranger.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '…/LinkToEtranger.app/Contents/MacOS/../ Frameworks/libEtranger.dylib' (code signature in <E16EDD14-CE5A-33BC- 9B06-554A3BC12C51> '…/LinkToEtranger.app/Contents/Frameworks/ libEtranger.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/usr/local/lib/ libEtranger.dylib' (no such file), '/usr/lib/libEtranger.dylib' (no such file) zsh: abort ./LinkToEtranger.app/Contents/MacOS/LinkToEtranger The Reason line is super long, so break it up by attempt: '…/LinkToEtranger.app/Contents/MacOS/../Frameworks/libEtranger.dylib' (…), '/usr/local/lib/libEtranger.dylib' (no such file), '/usr/lib/libEtranger.dylib' (no such file) Each entry starts with a place that the dynamic linker attempted to find library and then has text inside parentheses, like no such file, explaining what went wrong. Note The exact format of these messages varies from release-to-release of macOS. Many of these reasons are unrelated to the trusted execution system. For example, no such file means that the library isn’t present on disk. There are, however, three common trusted execution issues: Library validation Use of an old macOS SDK Restricted entitlements on library code For more information about the dynamic linker, see the dyld man page. Specifically, the DYLD_PRINT_SEARCHING environment variable is super useful when debugging library loading problems. Library Validation In any real world situation the Reason output from the dynamic linker is super long. To understand it better, break it up by attempt: '…/LinkToEtranger.app/Contents/MacOS/../Frameworks/libEtranger.dylib' (code signature in <E16EDD14-CE5A-33BC-9B06-554A3BC12C51> '…/LinkToEtranger.app/Contents/Frameworks/libEtranger.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/usr/local/lib/libEtranger.dylib' (no such file), '/usr/lib/libEtranger.dylib' (no such file) The dynamic linker looked in three different places: The app’s Frameworks directory /usr/local/lib /usr/lib The first one is the important one because its path matches the expected location of the library. And the dynamic linker has logged an excellent explanation of the problem: code signature in … '…/LinkToEtranger.app/Contents/Frameworks/ libEtranger.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs In summary, the dynamic linker didn’t load this copy of libEtranger.dylib because it’s not a system library (non-platform) and it has a different Team ID from the process’s main executable. A quick trip to codesign confirms this: % codesign -d -vvv LinkToEtranger.app … TeamIdentifier=SKMME9E2Y8 … % codesign -d -vvv LinkToEtranger.app/Contents/Frameworks/libEtranger.dylib … TeamIdentifier=VL9SQP756U … How you fix this depends on the nature of your product. If this library is installed as part of your product, re-sign the library with a signing identity associated with your Team ID. Do this even if you didn’t build the code yourself. After all, you were responsible for putting the library on the user’s machine, and its signature should reflect that. One other possibility is that you’re building a program that supports plug-ins and thus you need to load a plug-in that was signed by another third-party developer. In this case the fix is to disable library validation by signing your executable with the Disable Library Validation Entitlement entitlement (com.apple.security.cs.disable-library-validation). IMPORTANT Disabling library validation makes it harder to pass Gatekeeper. See Resolving Gatekeeper Problems Caused by Dangling Load Command Paths for the details. Use of an Old macOS SDK Another dynamic library load failure related to the trusted execution system looks like this: code signature in … '…/LinkToDodo.app/Contents/Frameworks/libDodo.dylib' not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to be at least ad-hoc signed. Note The cdhash in this message refers to a code directory hash. For more information on cdhashes, see TN3126 Inside Code Signing: Hashes This is harder to understand, not least because the library is actually signed: % codesign -d -vvv LinkToDodo.app/Contents/Frameworks/libDodo.dylib … Authority=Apple Development: … … The explanation can be found tucked away in Notarizing macOS Software Before Distribution, which says: Apple's notary service requires you to adopt the following protections: … Link against the macOS 10.9 or later SDK macOS 10.9 introduced important code signing improvements. The hardened runtime depends on those improvements. It confirms their presence by looking at the SDK that the code was built with. If the code was built with an old SDK, or has no record of the SDK it was built with, the hardened runtime refuses to load it. In this example, the LinkToDodo app was linked to a modern SDK but the libDodo.dylib has no record of the SDK it was built with: % vtool -show-build LinkToDodo.app/Contents/MacOS/LinkToDodo … cmd LC_BUILD_VERSION … sdk 12.3 … % vtool -show-build LinkToDodo.app/Contents/Frameworks/libDodo.dylib LinkToDodo.app/Contents/Frameworks/libDodo.dylib: % That explains the error: The process has the hardened runtime enabled. The hardened runtime requires that all code be built with the macOS 10.9 SDK or later. libDodo.dylib has no record of the SDK it was build with, so the trusted execution system blocks it from loading. The dynamic linker reports that in its explanation of the problem. The best fix is to rebuild the code from source with the latest tools. If you can’t do that right now, see Notarisation and the macOS 10.9 SDK for a workaround. IMPORTANT This is a short-term compatibility measure. Plan to rebuild this code from source as soon as possible. If you got the code from another third-party developer, make sure they’re aware of this issue. Finally, if you can only reproduce this problem in the field and have managed to snag a sysdiagnose log of it, look in the system log for a log entry like this: type: default time: 2022-05-20 13:12:11.185889 +0100 process: kernel category: <Missing Description> message: …/LinkToDodo.app/Contents/Frameworks/libDodo.dylib: Possible race detected. Rejecting. That’s one cryptic smoking gun! For general information about the system log, see Your Friend the System Log. Restricted Entitlements on Library Code The third dynamic library load failure related to the trusted execution system looks like this: … OS Version: macOS 11.6.5 (20G527) … Termination Reason: DYLD, [0x5] Code Signature Application Specific Information: dyld: launch, loading dependent libraries Dyld Error Message: Library not loaded: @rpath/OverlyEntitled.framework/Versions/A/OverlyEntitled Referenced from: /Users/USER/AppWithEntitlementLibrary.app/Contents/MacOS/AppWithEntitlementLibrary Reason: no suitable image found. Did find: …/AppWithEntitlementLibrary.app/Contents/MacOS/../Frameworks/OverlyEntitled.framework/Versions/A/OverlyEntitled: code signature invalid for '…/AppWithEntitlementLibrary.app/Contents/MacOS/../Frameworks/OverlyEntitled.framework/Versions/A/OverlyEntitled' … Note This crash report is from macOS 11. For… well… reasons… macOS 12 ignores entitlements on library code. However, this changed again in macOS 13, which will fail much like macOS 11 did. However, the code signature is valid: % codesign -v -vvv AppWithEntitlementLibrary.app/Contents/Frameworks/OverlyEntitled.framework AppWithEntitlementLibrary.app/Contents/Frameworks/OverlyEntitled.framework: valid on disk AppWithEntitlementLibrary.app/Contents/Frameworks/OverlyEntitled.framework: satisfies its Designated Requirement It also passes both of the tests outlined in the previous section: % codesign -d -vvv AppWithEntitlementLibrary.app … TeamIdentifier=SKMME9E2Y8 … % codesign -d -vvv AppWithEntitlementLibrary.app/Contents/Frameworks/OverlyEntitled.framework … TeamIdentifier=SKMME9E2Y8 … % vtool -show-build AppWithEntitlementLibrary.app/Contents/Frameworks/OverlyEntitled.framework/Versions/A/OverlyEntitled … sdk 12.3 … The issue is that the framework is signed with a restricted entitlement: % codesign -d --entitlements - AppWithEntitlementLibrary.app/Contents/Frameworks/OverlyEntitled.framework … [Dict] [Key] com.apple.developer.networking.vpn.api [Value] [Array] [String] allow-vpn Entitlements are only effective when applied to a main executable. Code that isn’t a main executable is called library code, and that includes frameworks, dynamic libraries, and bundles. Do not apply entitlements to library code. At best it’s benign. At worse, it causes a code signing crash like this. Note For details on what constitutes a main executable, see Creating Distribution-Signed Code for Mac The Entitlements on macOS section of TN3125 Inside Code Signing: Provisioning Profiles define restricted entitlement and makes it clear that, on macOS, every restricted entitlement claimed by an executable must be authorised by its provisioning profile. However, library code does not have an embedded provisioning profile: A shared library has no bundle structure, and thus can’t include a provisioning profile. Library code with a bundle structure, frameworks and bundles, could have a provisioning profile but most tools, including Xcode, do not embed one. So, the OverlyEntitled framework is claiming a restricted entitlement but that claim isn’t authorised by a profile and thus the trusted execution system tells the dynamic linker not to load it. To fix this, change your code signing setup so that only main executables claim entitlements. For detailed advice on that topic, see Creating Distribution-Signed Code for Mac. IMPORTANT The number one cause of this problem is folks signing their code with --deep. Don’t do that, for this reason and for the other reasons outlined in --deep Considered Harmful. Revision History 2022-12-13 Updated the note in the Restricted Entitlements on Library Code section to account for macOS 13 “going back to metric”. 2022-09-26 Fixed a broken link. 2022-06-13 Added the Restricted Entitlements on Library Code section. 2022-05-20 First posted.

I was aware of the new 'App Management' feature added in macOS Ventura, I am wondering if there is an API for a macOS app to request and grant this permission, instead of waiting for the push notification, change privacy settings, restart the app and try again.

I have an installer app which will download our macOS app from server (as zip) and extract it to the root folder of a USB flash drive. Both installer and the macOS app are code signed / notarized with the same Developer ID certificate and Team ID. What to expect? macOS Ventura should allow my installer to extract the app bundle to the root folder of the USB flash drive. What happened? macOS Ventura doesn't allow my installer to extract the app bundle to the root folder of the drive, App Management notification was triggered. It does allow my installer to extract the software to any subfolders on the USB drive. I am forcing my users to enable Full Disk Access before installing the software to their USB drive, this is not ideal. Is it a bug of Gatekeeper?

I have MacOS bundle application which I've signed, packed into dmg and notarized. When I upload and download the dmg, copy the app somewhere, it is rejected by gatekeeper: “my” cannot be opened because the developer cannot be verified. or “check-signature” cannot be opened because it is from an unidentified developer. Tested on Monterey and High Sierra. In past it worked, but my HDD crashed so I had to install OS and whole development environment again so now I'm trying with different xcode version (13.4.1) and some 3rd party c++ libraries are newer, but basically layout of the application is the same and also code signing post build script which calls codesign inside out. In the Contents/MacOS folder my application contains nested bundle app. When I omit that nested bundle and notarize the app, gatekeeper is happy, but I need that nested application. When I verify dmg, or extracted application, there is no problem: spctl -a -t exec -vvv my.app  my.app: accepted source=Notarized Developer ID origin=Developer ID Application: my company (L….) spctl -a -t exec -vvv my.app/Contents/MacOS/nested.app my.app: accepted source=Notarized Developer ID origin=Developer ID Application: my company (L….) codesign --verify --deep --strict -v my.app my.app: valid on disk my.app: satisfies its Designated Requirement I've also tried check-signature tool (ironically it is not notarized) ./check-signature my.app .my.dmg  (c) 2014 Apple Inc. All rights reserved. my.app: YES my.dmg: YES I've also checked the logs, I've found nothing suspicious. Mounting the DMG: assessment granted for my.dmg by Notarized Developer ID com.apple.message.domain: com.apple.security.assessment.outcome2 com.apple.message.signature2: bundle:UNBUNDLED com.apple.message.signature3: my.dmg com.apple.message.signature5: UNKNOWN com.apple.message.signature4: 3 com.apple.message.signature: granted:Notarized Developer ID Some log from finder about opening the app, then this from syspolicyd: assessment granted for .app by Developer ID com.apple.message.domain: com.apple.security.assessment.outcome2 com.apple.message.signature2: bundle:com.my com.apple.message.signature3: .app com.apple.message.signature5: 1.0 com.apple.message.signature4: 1 com.apple.message.signature: granted:Developer ID I've followed advices from other threads from this forum, but I cannot figure out anything. Any idea what else can I do to see what exactly is the problem? Thank you.

I'm developing a custom library that is loaded in a third-party software. The library is being built using CMake, and then signed using the codesign tool with a "Developer ID Application" certificate. The signing process works just fine, and I get the following output when I check for the correct signature: xxxxx@MacBook-Pro-JS Downloads % codesign -dv --verbose xxxxxx.so Executable=/Users/xxxxxx/Downloads/xxxxxx.so Identifier=xxxxxx Format=Mach-O thin (x86_64) CodeDirectory v=20400 size=8115 flags=0x0(none) hashes=248+2 location=embedded Signature size=8967 Authority=Developer ID Application: Binho LLC (VG9F9RW797) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=30 Sep 2022 at 17:56:49 Info.plist=not bound TeamIdentifier=VG9F9RW797 Sealed Resources=none Internal requirements count=1 size=176 I can also verify the signature with the following command: xxxxxx@MacBook-Pro-JS Downloads % codesign --verify --verbose xxxxxx.so xxxxxx.so: valid on disk xxxxxx.so: satisfies its Designated Requirement However, when I load it in the third-party software, I get the following OS prompt: "xxxxxx.so" can't be opened because Apple cannot check it for malicious software. This software needs to be updated. Contact the developer for more information. Note: the warning only shows on some systems, and not on others. Am I missing any step to avoid Apple from identifying my library as malicious software? Thanks in advance.