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 Gatekeeper Problems Gatekeeper strives to ensure that only trusted software runs on a user’s Mac. It’s important that your code pass Gatekeeper. If not, you’re likely to lose a lot of customers, and your users’ hard-won trust. There are four common Gatekeeper problems: App blocked by a dangling load command path Broken code signature Lack of notarisation Command-line tool blocked by Gatekeeper The first problem is by far the most common. For the details, see Resolving Gatekeeper Problems Caused by Dangling Load Command Paths. For general information about Gatekeeper, read Apple > Developer > Signing Mac Software with Developer ID and Apple > Support > Safely open apps on your Mac. IMPORTANT This post focuses on Developer ID-signed code. Gatekeeper should not block App Store apps. If an app downloaded from the App Store fails to run, it’s likely to be some other trusted execution issue. For more about this, read Resolving Trusted Execution Problems. Verify Your Signature A good first step in any Gatekeeper investigation is to verify that your code is signed correctly. Use the codesign tool for this: % codesign -v -vvv --strict --deep MyApp.app The -vvv options increase verbosity to the point where codesign will give you useful diagnostics. For example: % codesign -v -vvv --strict --deep "Munged.app" Munged.app: a sealed resource is missing or invalid file added: …/Munged.app/Contents/Resources/names/Adam.txt file modified: …/Munged.app/Contents/Resources/names/Morgan.txt file missing: …/Munged.app/Contents/Resources/names/Rhonda.txt This app was changed after it was signed in three different ways: Adam.txt was added. Morgan.txt was modified. Rhonda.txt was removed. You might see some results that make no sense. For example: Start with an app with a valid code signature: % codesign -v -vvv --strict --deep "NotNormal.app" NotNormal.app: valid on disk NotNormal.app: satisfies its Designated Requirement Use the Finder to create a zip archive (File > Compress). Use the Finder to unpack that archive. Check the code signature of the unpacked file: % codesign -v -vvv --strict --deep "NotNormal 2.app" NotNormal 2.app: a sealed resource is missing or invalid file added: …/NotNormal 2.app/Contents/Resources/names/Zoë Schrödinger.txt file missing: …/NotNormal 2.app/Contents/Resources/names/Zoë Schrödinger.txt There are two things to note here. First, just compressing and decompressing the app broke its code signature. Weird! Second, look at the error messages. It seems that the Zoë Schrödinger.txt file is was both added and removed. Weirder! To see what’s going on here you have to look at a hex dump of the file name: % ls "NotNormal.app/Contents/Resources/names" | xxd 00000000: 5a6f c3ab 2053 6368 726f cc88 6469 6e67 Zo.. Schro..ding 00000010: 6572 2e74 7874 0a er.txt. % ls "NotNormal 2.app/Contents/Resources/names" | xxd 00000000: 5a6f 65cc 8820 5363 6872 6fcc 8864 696e Zoe.. Schro..din 00000010: 6765 722e 7478 740a ger.txt. The names are not the same! The app started out with the ë in precomposed form and the ö in decomposed form. Compressing and decompressing the app converted the ë to its decomposed form, and that change broke the code signature. Programs that deal with Unicode are expected to ignore differences in normalisation. Sadly, Apple’s code signing implementation missed that memo (r. 68829319). For more details see this post but the executive summary is that it’s best to stick to ASCII when naming files in a bundle. Identify a Notarisation Problem Gatekeeper requires that your app be notarised. If not, it will block the execution of your app with a generic, user-level message. If you find your app blocked by Gatekeeper, check if this is a notarisation issue by looking in the system log for an entry like this: type: info time: 2022-05-11 14:57:21.812176 -0700 process: syspolicyd subsystem: com.apple.syspolicy category: default message: ticket not available: 2/2/8b7410713591e6c79ea98f0132136f0faa55d22a Note If the ticket details show as <private>, enable private data in the system log. For information on how to do that, see Recording Private Data in the System Log. For general information about the system log, see Your Friend the System Log. The long hex number is the code directory hash, or cdhash, of the offending code. In this example, it’s the cdhash of the app itself: % codesign -d -vvv /Applications/NotNotarised.app … CDHash=8b7410713591e6c79ea98f0132136f0faa55d22a … However, in some cases it may be the cdhash of some library referenced by the app. For more information about cdhashes, see TN3126 Inside Code Signing: Hashes. Resolve a Notarisation Problem The obvious cause of this problem is that you haven’t notarised your app. For information on how to do that, see Notarizing macOS Software Before Distribution. If you have notarised your app and yet you still see this problem, something more subtle is happening. For example, your app might reference a dynamic library that wasn’t seen by the notary service. To investigate this: Fetch the notary log for your app. For advice on that, see Fetching the Notary Log. Confirm that the notary log matches the app you installed. Look in the notary log for the sha256 property. Its value is a SHA-256 hash of the file received by the notary service. Check that this matches the SHA-256 hash of the file you used to install your app. If not, see Hash Mismatch, below. Search the notary log for the cdhash value from the Gatekeeper log message. If the notary log doesn’t contain that cdhash, that code wasn’t included in the notarised ticket. It’s possible that you failed to submit the code to the notary service, that it was switched out with a different version after you notarised your app, that it was package in some way that the notary service couldn’t see it, or that something went wrong within the notary service. Hash Mismatch If you stapled your notarised ticket to the file used to install your app then the hashes in step 2 of the previous section won’t match. What to do depends on the file type: If the file used to install your app was a zip archive (.zip), you definitely have the wrong file. Zip archives don’t support stapling. If the file used to install your app was a signed disk image (.dmg), compare the disk image’s cdhash with the cdhash for the disk image in the notary log. If those match, you know you’re working with the same disk image. To dump a disk image’s cdhash, run the codesign tool as follows: % codesign -d -vvv DISK_IMAGE … CDHash=d963af703ac2e54af6609e9ad309abee7b66fae2 … Replace DISK_IMAGE with the path to your disk image. If the file used to install your app was a disk image but it wasn’t signed, switch to a signed disk image. It’s generally a better option. If the file used to install your app was an installer package (.pkg), there’s no good way to know if this is the correct package. In this case, modify your notarisation workflow to retain a copy of the file before it was modified by stapler. Tool Blocked by Gatekeeper If your product includes a command-line tool, you might notice this behaviour: When you double click the tool in Finder, it’s blocked by Gatekeeper. When you run the tool from within Terminal, it works. This is a known bug in macOS (r. 58097824). The issue is that, when you double click a tool in the Finder, it doesn’t run Gatekeeper’s standard execution logic. Rather, the Finder passes the tool to Terminal as a document and that opens a window (and associated shell) in which to run that document. This triggers Gatekeeper’s document logic, and that logic always blocks the tool. There are two ways around this: Embed your tool in an application. If the user runs the application first, Gatekeeper runs its normal application check. If the user allows the app to run, Gatekeeper records that decision and applies it to the app and any code within the app, including your tool. Install your tool using an installer package. When the user goes to install the package, Gatekeeper checks it. Assuming that check passes, Gatekeeper does no further checks on the content it installed. Revision History 2022-05-20 Added the Verify Your Signature section. Made other minor editorial changes.

I have an application which has .py files inside it (it's a developer tool and the python executable must be provided by the user). This means that when the user executes the application .pyc files are generated inside it (it's not possible to pre-generate those because the user can select the python interpreter he wants to use and having the .pyc for all existing python interpreters is unwieldy). So, I can sign and execute the application and all works well initially, but after the user executes code the notarization is no longer valid due to the pycache and .pyc files generated internally. Is there a way out to make the notarization work in this scenario?

I've discovered that some of my third party intel dylibs are using the old LC_VERSION_MIN_MACOSX, which I'm pretty sure are causing library loading problems. My reasoning is that the arm versions all use the new format and works. The intel version works without signing and notarisation, but not when signed and notarised. See: https://developer.apple.com/forums/thread/127450 "The LC_VERSION family of load commands are no longer emitted when targeting the latest versions of the operating systems. Those commands are superseded by LC_BUILD_VERSION." https://developer.apple.com/forums/thread/659964 Just wondering what the incantation is to change from the old to the new so that: myThirdPartyPlugin.dylib: Load command 8    cmd LC_VERSION_MIN_MACOSX  cmdsize 16  version 10.7    sdk 10.15.4 becomes something like: myThirdPartyPlugin.dylib: Load command 8    cmd LC_BUILD_VERSION  cmdsize 32  platform MACOS   minos 12.0    sdk 12.3   ntools 1    tool LD  version 820.1 Thanks in advance for your time and response. Stew

I'm trying to overcome a problem by changing the build versions within some third party dylibs. See https://developer.apple.com/forums/thread/726412. However, I'm getting an error when I run the command: vtool -set-build-version macos 12.0 12.0 -replace -output "/Volumes/Data/Projects/MyApp/Pharo/Builds/1.0.0/Bundle/intel64/MyApp.app/Contents/MacOS/PluginsFixed/libUnixOSProcessPlugin.dylib" "/Volumes/Data/Projects/MyApp/Pharo/Builds/1.0.0/Bundle/intel64/MyApp.app/Contents/MacOS/Plugins/libUnixOSProcessPlugin.dylib" The error is: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/vtool error: mkstemp: No such file or directory. It looks like it is failing when creating a temporary file, so maybe it is a configuration problem? This is my last hurdle with the whole notarization, codesigning journery, and any help is very much appreciated!

I'm using App Wrapper on my Mac to codesign and notarize my app, but I get an error when it uploads to Apple: " failed Your Apple ID account is attached to other providers. You will need to specify which provider you intend to submit content to. Please contact us if you have questions or need help. (1627)" I've never had this problem before. I am the only one in my company, so I don't know why the account is attached to other providers. I called Apple support and they had no idea and suggested I contact Ohanaware who makes App Wrapper. He didn't know what it was either. Anyone have any ideas? All my certificates are current and I've deleted any that were expired. I did notice that when evaluating the certificates, it says "No root certificate found." Could that be the problem? And how do I fix this?

We submit for notarization using: /usr/bin/xcrun notarytool submit '/tmp/notarytool_our_app.zip' --keychain-profile notarytool-TEAMID --wait --output-format plist --timeout 2h --keychain /Users/admin/teamid.keychain Occasionally it fails with this error: Error: MultipartUploadError(error: HTTPClientError.readTimeout, completedParts: [SotoS3.S3.CompletedPart(eTag: Optional(""f838a70fa4e9b4bf1a0c075eb931fcb8""), partNumber: Optional(1)), SotoS3.S3.CompletedPart(eTag: Optional(""7aa16c155f47b9d0704d99bc9a59db4c""), partNumber: Optional(2))]) What can be the reason for this? Upload size is 700-800MB. Seems to be som e upload issue to AWS S3 storage. Thanks

I'm signing a small command line TCP listener for Mac M1 which usually signs and notarizes correctly using the following command: codesign --sign $IDENTITY --options runtime --timestamp server/executable In order to enrich the features of our listener we may need to load JVM library from Oracle, in order to be allowed to load a third party dyamic library I've introduced an entitlements plist file called macos-entlist.plist as follows: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.security.cs.allow-jit</key> <false/> <key>com.apple.security.cs.allow-unsigned-executable-memory</key> <false/> <key>com.apple.security.cs.disable-executable-page-protection</key> <false/> <key>com.apple.security.cs.allow-dyld-environment-variables</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.get-task-allow</key> <false/> </dict> </plist> And changed my codesign command as follows: codesign --sign $IDENTITY --entitlements macos-entlist.plist --options runtime --timestamp server/executable After adding the entitlements feature to my codesigning and notarization logic my ZIP file still passes the notarization phase but when I try to run executable I get an error message saying that executable cannot be opened because the developer cannot be verified. The issue happens regardless the contents of macos-entlist.plist (eg: even setting all the values to false I still get the error) it seems that that the mere introduction of the parameter --entitlements macos-entlist.plist causes the executable to not be valid anymore despite the fact that the notarization phase succeeds. Curiously other command line executable files in my ZIP signed with the same codesign command are still running fine. Do you have any suggestions on how I can correctly introduce entitlements?

How to sign and notarize a kext? Any body could help me to finish it? I already wrote a apply to enable my develop account kext sign ability,but i dose not recieve any response. Help!

I am trying to modify an existing bundle so that I can notarize it. Here its organisation: graps.app Contents MacOS prelaunch &lt;-- main applauncher grasp &lt;-- auxiliary binary calling the libraries Here the original DYLD_LIBRARY_PATH: DYLD_LIBRARY_PATH="." DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/Applications/MATLAB/MATLAB_Runtime/v911/runtime/maci64" DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/Applications/MATLAB/MATLAB_Runtime/v911/bin/maci64" DYLD_LIBRARY_PATH="$DYLD_LIBRARY_PATH:/Applications/MATLAB/MATLAB_Runtime/v911/sys/os/maci64" export DYLD_LIBRARY_PATH and the RPATHs that mimic it: install_name_tool -add_rpath "/." grasp install_name_tool -add_rpath "/Applications/MATLAB/MATLAB_Runtime/v911/bin/maci64" grasp install_name_tool -add_rpath "/Applications/MATLAB/MATLAB_Runtime/v911/runtime/maci64" grasp install_name_tool -add_rpath "/Applications/MATLAB/MATLAB_Runtime/v911/sys/os/maci64" grasp install_name_tool -add_rpath "/Applications/MATLAB/MATLAB_Runtime/v911/extern/bin/maci64" grasp Note that it is not enough to add RPATHs to the auxiliary binary "grasp". They must also be added to the main binary "prelaunch". But why ? 1- Unsigned application using DYLD_LIBRARY_PATH set RPATHs set DYLD_LIBRARY_PATH not set DYLD_PRINT_LIBRARIES ### App running ### 2- Unsigned application with lib tracking set RPATHs set DYLD_LIBRARY_PATH set DYLD_PRINT_LIBRARIES ### App hangs after loading 894 libraries (MatLab has more than 3000 libs and uses many macOS libs) ### The terminal output is a total of 119594 characters. ### Is this more than allowed by `DYLD_PRINT_LIBRARIES`? ### As a consequence the check cannot be completed. Too bad !!! 3- Unsigned application using RPATHs set RPATHs not set DYLD_LIBRARY_PATH set or not DYLD_PRINT_LIBRARIES ### Error: Could not find version 9.11 of the MATLAB Runtime. ### Attempting to load libmwmclmcrrt.9.11.dylib. &lt;-- it does not say "not found"! 307 libs are loaded before this error message occurs 59 are MatLab libs all from /bin/maci64 but the following one is from /runtime/maci64 libmwmclmcrrt.9.11.dylib is the 13th lib loaded and the 6th MatLab one: dyld: loaded: &lt;11D060E5-13C3-34EE-96C9-A7EA2A7E34B3&gt; /Applications/MATLAB/MATLAB_Runtime/v911/runtime/maci64/libmwmclmcrrt.9.11.dylib Note that MacOS does not say "not found" Thus RPATH does not seem to behave exactly as DYLD_LIBRARY_PATH did but why? How can "ignoring DYLD_LIBRARY_PATH" break a library loading ? How can I debug this ? This is very disappointing since, otherwise, the application would easily sign and notarize. I have exhausted all the tracks I knew and found on the internet. Alain

This is a solved problem, but a detail not in any docs I could find and I could only get answered from support. Figured I'd add it to the index.App-specific passwords are not supported with Managed Apple ID created through Business Manager. You will simply not see the option to create an app-specific password even if you do have two-factor authentication turned on.

My company is used to sign and notarize our software using altool and more recently notarytool. Our application is built as an .app bundle which is then distributed as a .dmg file. A few days ago the notary step started failing with this error : "The signature of the binary is invalid.". This referred to the main binary of our application. Of course, the bundle had just been signed with codesign which reported that everything was in order. Nothing had changed in this binary so we started investigating the code signing toolchain, our dev cerficate, changes in the Apple notarization policy, etc ... all this cost us a lot of time for nothing. Finally the tracked down the issue : a file with non-ascii filename had been introduced in the bundle. I can reproduce the issue simply by putting an empty file named "é.txt" in the bundle. So this either a bug in notarytool (.app and .dmg are supposed to support non-ascii characters, aren't they ?) or a known limitation but in that case the error message should be changed. So please, I kindly ask that Apple : investigates the issue and fixes it if utf-8 support is expected (or at least latin-1). improves the errors messages ; a binary signing issue has nothing to do with filename encoding issue. It is totally misleading. puts in place regression tests so that this does not happen again ; I believe that most apple users use a non-ascii language. Unicode filenames have been around since the 90's. This should be tested. Best regards

We have been using xcrun notarytool submit "OurPackage.dmg" --apple-id "ourid" --password "ourpassword" --team-id "ourteamid" --wait for about 6 months and it has almost always worked. About a week ago this stopped being true. We do this with about a dozen configurations as part of our nightly build and it now randomly fails on one of the configurations every night. The errors look like: Error: HTTP status code: 500. Internal Server Error Request ID: JUVIR5QCGI4NZPPQ7FWYAH6H3Y.0.0 Please try again at a later time. ERROR Notarization failed even though it claims Successfully uploaded file id: abc0e1ee-b945-4611-a086-7a4b8066db8c Is this a known problem that is being addressed? If so when can we expect it to be fixed?

Hi everyone, I am currently facing troubles to notarize the MacOS app I distribute to our customer. I successfully signed my executable and the dmg that packages it with my Apple Developer certificate. I then successfully submitted a notarization ticket for my dmg by using "xcrun notarytool submit" command line. Nevertheless when reading the log, my notarization fails because of the following error in the json output: { "severity": "error", "code": null, "path": "MyDMG.dmg/MyApp.app/Contents/Resources/sklearn/.dylibs/libomp.dylib", "message": "The binary is not signed with a valid Developer ID certificate.", "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721", "architecture": "i386" } When running codesign -dv MyApp.app/Contents/Resources/sklearn/.dylibs/libomp.dylib I see indeed that the existing signature seems to lack some valid elements (Team ID...): Identifier=libomp-55554944b4aef647421b3b93bf0a9f6317d56c44 Format=Mach-O universal (i386 x86_64) CodeDirectory v=20400 size=4104 flags=0x2(adhoc) hashes=122+2 location=embedded Signature=adhoc Info.plist=not bound TeamIdentifier=not set Sealed Resources=none Internal requirements count=0 size=12 I tried to sign it with my Apple Developer certificate with codesign using the "-f" option to erase the existing signature but it seems like it is impossible because I get the following error: dist/dmg/Vib3s.app/Contents/Resources/sklearn/.dylibs/libomp.dylib: library validation flag cannot be used with an i386 binary When I check again the file the signature indeed didn't change. I also tried using an entitlements.plist file and setting the com.apple.security.cs.disable-library-validation option to true doesn't work. Would you guys know the proper way to proceed to successfully notarize my app please?

Hi, We have moved to the new notarytool for uploading files to Apple for Notarization. Our package is around 2.8 GB and we are uploading a single dmg file to Apple servers. It takes between 40-60 minutes to upload and provide the status. Not sure whether it is a problem with our network or not. I have checked with our network department whether our network has access to notary-submissions-prod.s3-accelerate.amazonaws.com. They confirmed that it has access through port 80 or 443. I don't see upload speed difference between old and new tool. Please help me to identify why I don't get the improvement in upload speed. regards Prema Kumar

Hello, this is my first post here, I hope I am not asking what is considered to be common knowledge. After a long and very frustrating day, I have found out why copying out my (correctly signed and notarised) MyProg.app from the (correctly signed and notarised) enclosing DMG breaks it ("Is damaged and can't be opened"): it seems that D&D or C&P from Finder does something to destroy the notarisation. spctl --ignore-cache --assess -vvvv MyProg.app after I copy MyProg.app out of the DMG using FInder gives MyProg.app: a sealed resource is missing or invalid If I copy MyProg.app from the DMG container into another directory by "cp -R" or "ditto" instead of D&D or C&P in Finder, everything works as it should and the notarisation is not broken. Is there a way to copy MyProg.app out of the enlocing DMG and keep the notarisation without resorting to command line? Dropping down to command line is not a problem for me, but it is for quite a few of my users - not everybody is comfortable with command line, and debugging what they did wrong sometimes turns out to be quite a futile undertaking.

Hi All, Trying to validate some altool credentials, produces this error message. "Failed to get authorization for username '&lt;username/&gt;' and password with errors:( "Error Domain=NSCocoaErrorDomain Code=0 "Status code: 0" UserInfo={NSLocalizedDescription=Status code:0, NSLocalizedFailureReason=The auth server returned a bad status code.}") This is returned when altool is called in the following way. xcrun altool --notarization-history 0 -u &lt;username/&gt; -p &lt;password/&gt; --output-format xml macOS 11.2.3 and Xcode 12.5 Things that have been tried already. Making sure the Apple system status page shows no issues. Different networks. Checked to see if any agreements need to be "activated". Recreated the app-specific password multiple times. Any other suggestions? @Quinn - Hi Quinn, it's Sam Rowlands (again) and this is with another App Wrapper customer experiencing this issue (so not me directly).