Trusted execution is a generic name for a Gatekeeper and other technologies that aim to protect users from malicious code.
General:
DevForums tag: Gatekeeper
Developer > Signing Mac Software with Developer ID
Apple Platform Security support document
Safely open apps on your Mac support article
Hardened Runtime document
WWDC 2022 Session 10096 What’s new in privacy covers some important Gatekeeper changes in macOS 13 (starting at 04: 32), most notably app bundle protection
WWDC 2023 Session 10053 What’s new in privacy covers an important change in macOS 14 (starting at 17:46), namely, app container protection
WWDC 2024 Session 10123 What’s new in privacy covers an important change in macOS 15 (starting at 12:23), namely, app group container protection
Updates to runtime protection in macOS Sequoia news post
Testing a Notarised Product DevForums post
Resolving Trusted Execution Problems DevForums post
App Translocation Notes DevForums post
Most trusted execution problems are caused by code signing or notarisation issues. See Code Signing Resources and Notarisation Resources.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Gatekeeper
RSS for tagGatekeeper on macOS helps protect users from downloading and installing malicious software by checking for a Developer ID certificate from apps distributed outside the Mac App Store.
Posts under Gatekeeper tag
51 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
Hi,
I develop a Mac application, initially on Catalina/Xcode12, but I recently upgrade to Monterey/Xcode13. I'm about to publish a new version: on Monterey all works as expected, but when I try the app on Sequoia, as a last step before uploading to the App Store, I encountered some weird security issues:
The main symptom is that it's no longer possible to save any file from the app using the Save panel, although the User Select File entitlement is set to Read/Write.
I've tried reinstalling different versions of the app, including the most recent downloaded from TestFlight. But, whatever the version, any try to save using the panel (e.g. on the desktop) results in a warning telling that I don't have authorization to record the file to that folder.
Moreover, when I type spctl -a -t exec -v /Applications/***.app in the terminal, it returns rejected, even when the application has been installed by TestFlight.
An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app returns a valid signature. I'm lost...
It suspect a Gate Keeper problem, but I cannot found any info on the web about how this system could be reset. I tried sudo spctl --reset-default, but it returns This operation is no longer supported...
I wonder if these symptoms depend on how the app is archived and could be propagated to my final users, or just related to a corrupted install of Sequoia on my local machine. My feeling is that a signature problem should have been detected by the archive validation, but how could we be sure?
Any idea would be greatly appreciated, thanks!
I have a .NET 6 application that runs in the background. The installer is a .pkg file built using a third-party tool called "Packages".
All .dylib and executable files are codesigned before packaging. The resulting .pkg file is notarized.
The app uses these entitlements:
com.apple.security.cs.allow-jit
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.disable-library-validation
The app is built on a macbook Air 2015 running macOS 12.6 and it works without issues on that machine.
On a macbook Pro M3 running macOS 14.6.1 the app fails to run even though the installation itself is successful.
The only logs that I was able to find are related to syspolicyd (4 warnings):
Unable to apply protection to app: 45, PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null))
Failed to register app bundle for protection: 45, PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null))
scan failed, finishing evaluation : PST: (vuid: A78FF6C2-08D5-4DCC-B946-8836251AA0E7), (objid: 1873967), (team: (null)), (id: (null)), (bundle_id: (null))
Terminating process due to Gatekeeper rejection: 95158,
Unfortunately, verification commands such as
sudo codesign --verify --deep --strict -vvv MyApplication.App
spctl -a -vvv -t install MyApplicationInstaller.pkg
do not indicate any issues.
Are there any additional steps that need to be performed in order for my app to work properly on newer machines?
I have something with a new individual on my team I've never seen before. They checked out our code repository from git and now anytime they try to open a .json file that is legitimately just a text file, GateKeeper tells them it cannot verify the integrity of this file and offers to have them throw this file away. I've seen this with binaries, and that makes sense. I removed the com.apple.quarantine extended attribute from all executable files in our source tree, but I've never seen GateKeeper prompt on text files. I could remove the extended attribute from all files in our source tree, but I fear the next time he pulls from git he'll get new ones flagged. Is there someway around this? I've never personally seen GateKeeper blocking text files.
We are using SHC to compile on macOS to convert the .sh script to a binary file. This binary file is then digitally signed by the Apple developer account and then notarised. After that, it will work on the same system where we follow this process. But if we share this file to another system, then it gets quarantined (com.apple.quarantine) while downloading.
Is there any way to prevent it by getting quarantine on another system or something I'm missing, any clues?
I have built a flutter desktop app and I notarized it. I have to distribute it directly as I cannot turn on App Sandboxing due to the functions included in the application.
I created a build of the app from Xcode and then uploaded it for notarization and it was successfully notarized.
If I compress that app into a .zip and share it over the internet, it successfully opens on any computer.
But when I create a dmg using appdmg from npm and I try to distribute it, it does not open and shows me the option to either move to bin or cancel.
When I notarize the dmg using the command:
xcrun notarytool submit "YourApp.dmg"
--apple-id "email"
--password "app-specific-password"
--team-id "YOUR_TEAM_ID"
--wait
It notarizes successfully.
I have also done:
xcrun stapler staple "YourApp.dmg"
And validated it but it does not seem to work when I distribute it over the internet by uploading on my website.
It is a bit strange that when I distribute the notarized app, it does not show any error when distributed over the internet by uploading on my website and then downloading but for a notarized dmg, which is properly signed, it gives that error that wether move to bin or do nothing.
Would love someone's help on this!
I recently got some plugins from Universal Audio, and have licensed them properly through both UA and iLok manager. Whenever I try to load up the plugins (specifically from UA) in GarageBand, it first says that
"NSCreateObjectFileImageFromMemory-p47UEwps” because the developper can not be verified.
After clicking either 'show in finder' or 'okay', it opens the plugin in a form without its GUI and showing that it is not licensed (even though it is). It also displays error code 100001. I have tried only some basic stuff to troubleshoot like restarting the DAW/my computer and reinstalling/relicensing the softwares. I don't know if the macOS version has anything to do with it but for some reason I just can't get it to work.
Hi fellow developers,
I built Video Restore AI which uses a number of models with CoreML on macOS to provide simple one-blick video upscaling and colorization. After uploading my archive, I received the following notification through email.
ITMS-91109: Invalid package contents - The package contains one or more files with the com.apple.quarantine extended file attribute, such as “{com.kammerath.VideoRestore.pkg/Payload/Video Restore AI.app/Contents/Resources/ECCV16Colorize.mlmodelc/weights/weight.bin}”. This attribute shouldn’t be included in any macOS apps distributed on TestFlight or the App Store. Starting February 18, 2025, you must remove this attribute from all files within your macOS app before you can upload to App Store Connect.
How do I deal with this? Is there a way to get Apple to just accept the model contents or do I need to convert it again with coremltools?
Many thanks in advance!
Jan
I built Mac app with Electron-forge and sign and notarize my app with Developer ID Application Certification and @electron/osx-sign, @electron/notarize module.
I built my app on macOS Sonoma 14.7.
Then I ran the built app on other mac with "App Store and identified developers" Gatekeeper of macOS version 12.7.3 And it worked well.
But when I ran it on another mac PC of macOS Sonoma 14.4.1, it said my app is damaged.
Why does it happen and How can I solve this issue?
Hi, I am a long time programmer in C#, and newer to Rust, and a rookie to MacOS 15.1.
Over the past few days I have made numerous attempts to run a Rust GUI binary that I compiled on Mac.
Here are some examples of things I have tried using.
Executable compiled in M1 mac not running on Apple Silicon Mac - help - The Rust Programming Language Forum
And here....
How to run unsigned apps in macOS 15.1
Also here... "sudo spctl --master-disable"
There are many more that I have tried.
I also tried moving the binary from my developer folder to the Application folder and running....
xattr -r -d com.apple.quarantine /Applications/csv
Note that "csv" is the name of my binary.
You have probably seen this 100 times, so can you point me to me to something that allows my Rust binaries to run under MacOS?
PS The Rust program code works just fine under Linux. I can either type Cargo Run and run the binary from the Terminal or go directly to the executable and double click on it to open the GUI application. The only thing that MacOS lets me do it open the GUI from the Terminal. Commander One says that I do not have the proper credentials to open the file directly. Finder also does not allow me to open the binary directly.
Thanks, Jim
I am working on releasing my macOS arm64 app. My problem is that after the user downloads the dmg, double-clicking my.app in the dmg, a Gatekeeper pop-up box will appear with a warning that the developer cannot be verified.
Question: Can an application signed with "com.apple.security.cs.disable-library-validation" be published as trusted?
If yes, what steps have I missed?
If not, can I get an official response from Apple?
(Because I referred to this post, it seems to mention that it is possible to publish trusted software.I have looked up similar questions on the forum and tried many things, but nothing works. )
Here are my steps:
Use the codesign to sign my.app. Because my app needs to access third-party dynamic libraries, entitlements.plist contains a "com.apple.security.cs.disable-library-validation". After the "codesign -dvvv" check, the signature was successful.✅
Use the "xcrun notarytool" command to notarize my app, and the status is displayed as accepted.✅
Use "xcrun stapler staple" to attach the notarization to my app, and it returns success.✅
Use the "spctl -a -v " command to verify whether my app has passed Gatekeeper, and it returns that it has passed.✅
Then I packaged my.app into a dmg, and then attached the notarization mark to the dmg, which was successful.✅
I completed the above steps and distributed the dmg. When I downloaded the dmg as a user test and double-clicked my.app in it, the Gatekeeper pop-up box still appeared, and the developer cannot be verified.❌
Adobe says that Animate works with the latest Mac OS.
When I publish apps with Animate, they work on my computer.
With a self-signed certificate, they work on some older Mac OS versions, but not on the 2 most recent.
How can I test my apps on others' Mac computers?
Robert
Hello I build an application in Xcode for MacOS. But the exported app I cannot open on different Mac systems. I get the message 'The application X can't be opened'. I can only run the application on the Mac where Xcode is installed.
I used different signing certificates: Apple Distribution, Developer ID application (this should be the one), Mac App Distribution.
I archive the application, then use Direct Distribution, then after complished the notary service, I export the app.
I am creating a macOS app with the following requirements:
Automatic Startup: After initial installation, the app should automatically start, even after the OS restarts.
Notarized Installation: The installation package (.pkg) should be notarized to avoid user have to make security exception.
In my current setup I’ve created a script, ci_scripts/ci_post_xcodebuild.sh, which uploads the package file $CI_APP_STORE_SIGNED_APP_PATH/<appName>.pkg to GitHub via Xcode Cloud. While I can successfully download the app, I’m encountering two main issues:
Notarization (I assume): I’m unsure how to get Xcode Cloud to notarize the .pkg file. Currently, upon opening the .pkg file for the first time, users have to go to System Settings > Privacy & Security to allow an exception for the package, after which installation proceeds successfully on second try. I’d like to automate the notarization process to eliminate this extra step.
Adding Additional Files to PKG installer: My current .pkg file only includes the app binary. I need to configure Xcode Cloud to include a postinstall script and a launchd daemon configuration file within the package. This would ensure that necessary files are set up on installation and that the app is properly registered as a launch daemon.
Hi, my app's direct distribution archive is stuck at "In progress" state in Organizer window.
What is wrong with it? What should I do?
Thank you.
In the past, I used to export a developer-signed test version of my macOS app in Xcode, create a zip archive from the Finder, upload it to my website and share the link to the testers. The last time I did this with macOS 14 the tester was still able to download the test app and run it.
But it seems that with macOS 15 the trick to open the context menu on the downloaded app and click Open to bypass the macOS warning that the app couldn't be checked when simply double-clicking it, doesn't work anymore. Now I'm always shown an alert that macOS couldn't check the app for malware, and pushes me to move it to the bin.
In this StackOverflow topic from 10 years ago they suggested to use ditto and tar to compress and uncompress the app, but neither worked for me.
How can I share macOS apps that I signed myself with testers without physically handing them a drive containing the uncompressed app?
Hi all,
I found an issue by chance where, when we copy an .app bundle (a large one), Gatekeeper can choose to try to scan the app before the file copying finishes (without the app having been launched). This of course fails, and then the app can't open because "it's damaged", even though spctl and codesign checks of the completed copied app come out fine. Then Gatekeeper remembers this setting forever, not rescanning the app.
I'm wondering if anyone else has seen this happen and if so, if there's a best practice for keeping Gatekeeper's hands off until the copy is done?
I imagine copying into a folder not named .app, then renaming it might work, or maybe saving the plist or main binary copy until last, although both require a more complex copy operation.
Maybe there's a more elegant way?
Thanks!
We get a "The application "Finder" does not have permission to open "(null)“" error message in macOS 15.1 when trying to open unsigned applications.
Is this a known bug in macOS 15.1 ? If so any indications of whether it will be fixed in the future.
In macOS 15.0.1 the workaround for launching unsigned applications still worked.
Hello,
I have an application which uses a helper[1] to download[2] files. When files download is a DMG and user mounts the image to run the application from this DMG it doesn't pass Gatekeeper. It presents the "Application XYZ.app can't be opened.".
Same file downloaded via Safari shows a different dialog, the "XYZ.app is an app downloaded from the internet. Are you sure you want to open it?"
In the system log I see this line:
exec of /Volumes/SampleApp/SampleApp.app/Contents/MacOS/SampleApp denied since it was quarantined by Download\x20Helper and created without user consent, qtn-flags was 0x00000187
The application is running sandboxed and hardened, the main application has com.apple.security.files.downloads.read-write entitlement. Everything is signed by DeveloperID and passes all checks[3].
I tried to check the responsible process[4] of the helper. Then trivial stuff like download folder access in System Settings/Privacy & Security/Files & Folders. Everything seems to be fine.
For what it worths the value of quarantine attribute is following:
com.apple.quarantine: 0087;6723b80e;My App;
The Safari downloaded one posses:
com.apple.quarantine: 0083;6723b9fa;Safari;02162070-2561-42BE-B30B-19A0E94FE7CA
Also tried a few more ways and got to 0081 with Edge and 0082 with a sample app with similar setup. Not sure if that has any meaning.
What could I be doing wrong that Gatekeeper right away refuses to run the application from DMG instead of showing the dialog like in other cases?
[1] The executable is in application bundle located in Contents/Helpers/DownloadHelper.app in the main application bundle.
[2] Nothing fancy, curl + regular POSIX file operations
[3] codesign, syspolicy_check, spctl
[4] launchctl procinfo pid
I am packaging an app with QtWebEngine in it, after codesign the app and the QtWebEngine Framework, the app can run properly.
The codesign result is:
valid on disk
staisfies its Designated requirements
Then I notarized and stapled the dmg file, after the dmg installed on Mac, gatekeeper still failed the check.
Here is the result for spctl:
spctl -a -t open -vvv --context context:primary-signatue Remote\ Graphics\ Workstation_.dmg
Remote Graphics Workstation_.dmg: rejected
source=Insufficient Context
Need help to identify the codesign process and the root cause why gatekeeper fail here, thanks.
We have a native ARM64 application. The application is a development environment and native compiler for the language Common Lisp. CL has a foreign function interface, which allows loading of .dylib files into CL and calling functions in them from CL. For this reason, we add certain entitlements. See below.
It is notarized and installed on macOS 14.7. When I run spctl on it I get this:
$ spctl --assess -v /Applications/AllegroCL64.app
/Applications/AllegroCL64.app: rejected (the code is valid but does not seem to be an app)
That’s before I run it. Which is odd because the app is notarized. When I run the app, it asks for a license file and installs it into /Applications/AllegroCL64.app/Contents/Resources/ and after that, the spctl shows this:
$ spctl --assess -v /Applications/AllegroCL64.app
/Applications/AllegroCL64.app: a sealed resource is missing or invalid
I assume the mere act of copying the license (a file called devel.lic which is a small text file) is causing this. Why does it say it “does not seem to be an app”?
This self-modification of the files in the Contents/Resources directory is a huge feature. We allow downloading of patches, which add features and fix bugs in the product. Is this going to be a problem, going forward? I don’t remember seeing this result from spctl before and I have a feeling it’s a new , due to tightening of security policies, etc.
All of this is quite worrying to us.
More details of the app:
$ codesign -vvvv mlisp
mlisp: valid on disk
mlisp: satisfies its Designated Requirement
$ codesign -d --entitlements - /Applications/AllegroCL64.app
Executable=/Applications/AllegroCL64.app/Contents/MacOS/AllegroCL64
[Dict]
[Key] com.apple.security.cs.allow-dyld-environment-variables
[Value]
[Bool] true
[Key] com.apple.security.cs.allow-jit
[Value]
[Bool] true
[Key] com.apple.security.cs.disable-library-validation
[Value]
[Bool] true
[Key] com.apple.security.get-task-allow
[Value]
[Bool] true
$
Other details:
The app was built with the Command Line tools version 2395 on macOS 12.x.