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
50 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
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.
App is signed, notarized and stapled, I send that dmg file with file transfer tool, it can open correctly on other mac without any warning or error. However, if I send that dmg file through IM to the same mac, it will produces the "cannot check it for malicious software" error.
I check the transfered dmg with spctl -a -t open -vvv --context context:primary-signature MyApp.dmg, it show source=Notarized Developer ID; origin=***
How can I resolve this issue?
Hi,
I've recently observed a sudden increase in support requests for one of my apps on the Mac App Store, reporting the error " is damaged and can't be opened. Please re-download it from the Mac App Store", all on different systems: macOS 12, macOS 13, and macOS 15 Sequoia.
Re-downloading does not resolve the issue most of the time.
One user reported that being connected to the internet resolved it - perhaps this is an OCSP issue again?
I myself cannot reproduce this issue.
Has there been a change in code-signing recently? Have some certificates changed? Anything else I should be aware of?
What is the best course of action to have users take who experience this, when re-downloading the app from the Mac App Store does not work?
Thank you,
– Matthias
I have tried to manually install binaries using Finder by clicking and dragging from the Desktop into "/usr/local/bin/". The binaries come with a collection of frameworks etc. All the binaries are adhoc signed. macOS asks for Admin credentials which is fine. But then, when I execute the binaries in Terminal, Gatekeeper shows the now expected "'[binary"] Not Opened Apple could not verify ........" etc. It shows that dialog for every component and requires user input 2-3 times to allow each component of which there are perhaps dozens.
BUT, none of that happens if I install those binaries using AppleScript. So, it might have a call like this:
do shell script "curl -L " & download_URL & " -o " & download_binary_zip with administrator privileges
do shell script "unzip -o " & download_binary_zip & " -d " & usr_bin_folder with administrator privileges
The resulting installs work perfectly.
Is this intended ? Using both install methods requires Admin credentials. Why does using a script work but using Finder does not ?
Hey all,
I am working on my self updater and I am hitting an error replacing my binaries. Basically, when there is a new release my self updater checks and prompts the user to update. When the user accepts to update my applicaiton will download the .zip for the specified version and for the operating system, which is darwin in this case. Then, once the .zip has been download I use ditto to replace the existing binaries, but I am hitting the error "Operation not permitted" on darwin.
Here is my code for updating:
// Download zip of latest version (Works)
homeDir, _ := os.UserHomeDir()
downloadPath := filepath.Join(homeDir, "Downloads", "tooler.zip")
err := exec.Command("curl", "-L", "-H", "Accept: application/octet-stream", "-H", "Authorization: Bearer REMOVED_TOKEN", "-H", "X-GitHub-Api-Version: 2022-11-28", release.AssetURL, "-o", downloadPath).Run()
if err != nil {
return fmt.Errorf("binary update failed during curl: %v", err)
}
// get executable path for where we need to replace (Works)
cmdPath, err := os.Executable()
appPath := strings.TrimSuffix(cmdPath, "tooler.app/Contents/MacOS/tooler")
if err != nil {
appPath = "/Applications/"
}
// Cleanup zip after everything executes
defer func() {
err = exec.Command("rm", downloadPath).Run()
if err != nil {
// return fmt.Errorf("binary update failed during removal: %v", err)
}
}()
// Replace .app contents, but hits "operation not permitted" (Does not work)
cmd := exec.Command("ditto", "-xk", downloadPath, appPath)
var out bytes.Buffer
var stderr bytes.Buffer
cmd.Stdout = &out
cmd.Stderr = &stderr
err = cmd.Run()
if err != nil {
return fmt.Errorf("binary update failed during ditto: %v \n Args: %v \n CmdPath: %v \n AppPath %v", stderr.String(), cmd.Args, cmdPath, appPath)
}
return nil
The first message before the line break is my application logging where the failure was and the rest of "ditto:" messages are the errors output by ditto.
Update failed: binary update failed during ditto:
ditto: /Applications//tooler.app/Contents/_CodeSignature/CodeResources: Operation not permitted
ditto: /Applications//tooler.app/Contents/MacOS/tooler: Operation not permitted
ditto: /Applications//tooler.app/Contents/Resources/icons.icns: Operation not permitted
ditto: /Applications//tooler.app/Contents/Info.plist: Operation not permitted
Here are my entitlements
<?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.app-sandbox</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.network.server</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.security.files.downloads.read-write</key>
<true/>
</dict>
</plist>
Could this ditto error that the operation is not permitted be related to my entitlements? My .app is signed and notarized before distribution. I am able to download the zip, unzip and run the application without problems other than when I try to run the self update and it fails due to "operation not permitted".
Hello all,
I am building a macOS application that I codesign and notarize for distribution. I am able to download my zip, unzip and run my application successfully, but when I attempt to update to a new version I hit an error with ditto that "operation not permitted" when attempting to replace my .app with the new version.
For example, here is a sample output of the failure:
Update failed: binary update failed during ditto:
ditto: /Applications//tooler.app/Contents/_CodeSignature/CodeResources: Operation not permitted
ditto: /Applications//tooler.app/Contents/MacOS/tooler: Operation not permitted
ditto: /Applications//tooler.app/Contents/Resources/icons.icns: Operation not permitted
ditto: /Applications//tooler.app/Contents/Info.plist: Operation not permitted
My application code updates the user to a new version by executing a curl command to download the versions zip and then uses ditto to unzip. I am able to successfully download the zip with the curl command and remove the file with the rm command, but when I try to use ditto to copy and replace my application contents it fails. Here is my application code that does that (The directories are correct for the application and the zip is downloaded):
// Download the zip (Works)
homeDir, _ := os.UserHomeDir()
downloadPath := filepath.Join(homeDir, "Downloads", "tooler.zip")
err := exec.Command("curl", "-L", "-H", "Accept: application/octet-stream", "-H", "Authorization: Bearer REMOVED_TOKEN", "-H", "X-GitHub-Api-Version: 2022-11-28", release.AssetURL, "-o", downloadPath).Run()
if err != nil {
return fmt.Errorf("binary update failed during curl: %v", err)
}
// Get the executeable path (Works)
cmdPath, err := os.Executable()
appPath := strings.TrimSuffix(cmdPath, "tooler.app/Contents/MacOS/tooler")
if err != nil {
appPath = "/Applications/"
}
// Cleanup function to remove the downloaded .zip (Works)
defer func() {
err = exec.Command("rm", downloadPath).Run()
if err != nil {
// return fmt.Errorf("binary update failed during removal: %v", err)
}
}()
// Update application contents (This fails from the operation not permitted)
cmd := exec.Command("ditto", "-xk", downloadPath, appPath)
var out bytes.Buffer
var stderr bytes.Buffer
cmd.Stdout = &out
cmd.Stderr = &stderr
err = cmd.Run()
if err != nil {
return fmt.Errorf("binary update failed during ditto: %v \n Args: %v \n CmdPath: %v \n AppPath %v", stderr.String(), cmd.Args, cmdPath, appPath)
}
return nil
Also, here are my entitlements:
<?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.app-sandbox</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.network.server</key>
<true/>
<key>com.apple.security.files.user-selected.read-write</key>
<true/>
<key>com.apple.security.files.downloads.read-write</key>
<true/>
</dict>
</plist>
Anyone have any ideas on why the ditto command won't let me update the application contents and returns operation not permitted?
I've successfully uploaded my macos app to tesflight (it's a game based on Unreal Engine5). It has passed all checks and is now in testflight, but when i launch it it says
"The application can't be opened. -10673"
And pops up another windown : "The beta app, , is no longer available. The provisioning profile is invalid"
The provisioning profile doesn't specify OS versions - it's signed with distribution and installation certificates for AppStore.
What would cause this? How can I fix this?
MacOS version 14.5
Due to changes in macOS 15 Sequoia with respect to container privacy/privileges, I have observed warnings with one of my apps (non-sandboxed) when its subsidiary crash reporter process tries to access the host app's data folder.
I THINK I've worked around this issue by granting the crash reporter and the host app access to the same application group. I'm not 100% sure how all this works except that the problem went away :)
The problem is, once the problem goes away on a given system, it goes away for good! Even with subsequent attempts to open a version of the app before the fix was in place, the system warning is not presented. I've tried to reset SystemPolicyAppBundles on the app via tccutil, but it makes no difference.
Using the wisdom from one of Quinn's posts (https://developer.apple.com/forums/thread/706442) I set up a log stream invocation to try to gather clues, and I notice that when I launch my app now, I see messages like:
Found provenance data on process: TA(82542d1beaf132a6, 2), 51084
Process was already in provenance sandbox, skipping: 51084, TA(82542d1beaf132a6, 2)
I suspect this "provenance" may reflect the change in how the system treats my application.
First: I wonder if it's a bug that any change in "provenance" should retroactively apply to versions of the app before the change was made. Second, I wonder if there's some way to RESET this provenance so that I can reproduce the bug again? I might be able to reproduce it by changing the bundle ID for the app but for purposes of testing against existing, shipped versions of the app, I'd love to be able to reset things for sanity-checking.
I am working with a compiler that produces native binaries, It's really meant for servers so it's not integrated with Xcode or the Xcode build system. As such the output binaries get the default ad-hoc signatures the linker makes.
After (re)compiling such a binary, there is a delay whilst running it. This is because macOS notices it's an unknown binary and goes off to ask notarization servers/Xprotect if it's known malware. Fine, I understand the need for this and why it happens.
From the logs it's clear that macOS is now tracking the "provenance" of binaries. This means where they came from. This raises the question of whether it could know that my local dev binaries are coming from this compiler, if it was in turn properly signed and notarized. And if so, whether there is some security policy I could set to say "if binary X produces binary Y, then trust Y".
Yes I know this would be a security exploit if it were done that way by default, but I am willing to take the risk of special malware that compiles itself first using this special compiler that isn't installed by default then runs the output, as presumably any such malware would be so targeted Xprotect/notarization wouldn't know about it anyway.
The provenance mechanism is some internal security thing and isn't documented, but I'm curious if anyone knows more about it and whether it's usable for this? Or alternatively if there's a way to stop macOS doing these slow checks for certain binaries e.g. under specific paths?
I have signed and notarized a single executable file command line tool developed outside Xcode, and distributed outside of the App store by way of a download from a website as follows below, but nevertheless gatekeeper blocks running the tool with the usual message, just like without signing or notarization.
If I remove the com.apple.quarantine xattr, the tool runs as it should without gatekeeper interference, as expected.
I have browsed countless posts here, with similar issues, but in the end I can't find what's wrong with the process.
From what I gather, as long as the target Mac is connected to the Internet, stapling should not be required (I do understand I can't staple a single file executable command line tool), although Gatekeeper would be expected to complain in the case of the first run being done without Internet connection.
The certificate is a "Developer Id Application" certificate, installed and valid on the machine doing the signing.
It is unclear to me what the distinction is between "Developer Id Application" and "Developer Id Installer" certificates, but it's confusing that using -t install with spctl will actually accept the app.
The app is open source and available on GitHub (although the full distribution packaging is done in a separate build environment with some additional logic). The app used below as the target for signing and notarization is available to download from https://www.axantum.com/ in a .tar.gz archive.
Here follows a log of commands and output:
XecretsCli.plist: (This was necessary to add to the signing to avoid corruption of the executable by the code signing)
codesign -s GCXRMT5SQC -f --timestamp -s 0CF6800E595AA6DE9EBB905066619A9BFDD17A77 --entitlements XecretsCli.plist -o runtime XecretsCli
codesign -d -vvv --entitlements :- XecretsCli
Executable=/Users/svante/Downloads/XecretsCli-Osx-2.3.567 3/XecretsCli
Identifier=XecretsCli
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=271478 flags=0x10000(runtime) hashes=8473+7 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=d3a8216fcb22b4a4af7bd0157ecc3d2b6be9f9b2
CandidateCDHashFull sha256=d3a8216fcb22b4a4af7bd0157ecc3d2b6be9f9b20c9e3c17e107f08c7ae75c5a
Hash choices=sha256
CMSDigest=d3a8216fcb22b4a4af7bd0157ecc3d2b6be9f9b20c9e3c17e107f08c7ae75c5a
CMSDigestType=2
CDHash=d3a8216fcb22b4a4af7bd0157ecc3d2b6be9f9b2
Signature size=8987
Authority=Developer ID Application: Axantum Software AB (GCXRMT5SQC)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jun 20, 2024 at 13:26:05
Info.plist=not bound
TeamIdentifier=GCXRMT5SQC
Runtime Version=13.1.0
Sealed Resources=none
Internal requirements count=1 size=172
Warning: Specifying ':' in the path is deprecated and will not work in a future release
codesign -v -vvv --strict --deep XecretsCli
XecretsCli: valid on disk
XecretsCli: satisfies its Designated Requirement
zip XecretsCli.zip XecretsCli
adding: XecretsCli (deflated 63%)
xcrun notarytool submit "XecretsCli.zip" --keychain-profile "Notarize" --wait
Conducting pre-submission checks for XecretsCli.zip and initiating connection to the Apple notary service...
Submission ID received
id: e5990902-3101-42de-a1a6-b9ea40b944b8
Upload progress: 100.00% (12.4 MB of 12.4 MB)
Successfully uploaded file
id: e5990902-3101-42de-a1a6-b9ea40b944b8
path: /Users/svante/Downloads/XecretsCli-Osx-2.3.567 3/XecretsCli.zip
Waiting for processing to complete.
Current status: Accepted........
Processing complete
id: e5990902-3101-42de-a1a6-b9ea40b944b8
status: Accepted
spctl -a -vvv XecretsCli
XecretsCli: rejected (the code is valid but does not seem to be an app)
origin=Developer ID Application: Axantum Software AB (GCXRMT5SQC)
spctl -a -vvv -t install XecretsCli
XecretsCli: accepted
source=Notarized Developer ID
origin=Developer ID Application: Axantum Software AB (GCXRMT5SQC)
Trying to run the executable:
"XecretsCli" can't be opened
because the identity of the
developer cannot be confirmed.
Your security preferences allow
installation of only apps from the App
Store and identified developers.
Chrome downloaded this file today at
10:37.
OK
I developed an app including driver extension. So I tried to distribute it to users. Of course, it works fine in my Mac. I pressed "direct distribution" through the distribution menu in xcode, but the error occurred as below. I also checked that distribution are fine with TestFlight(internally), checked unregistered mac device. I can't figure out what's wrong, so I'm asking for help.
Thank you.
(Skippable) Backstory:
I have an app that customers initially install by:
Going to our website in a browser,
downloading a (notarized) disk image,
mounting it,
opening the (Developer ID-signed) installer package therein, and
following the prompts to completion.
Once installed, this app has a button you can click that will check for updates and possibly install them. When you click this button:
Our app contacts an HTTPS API on our servers to see if there is an update
If there is an update, the API responds with a download URL to the aforementioned notarized disk image, and the SHA-512 hash of the disk image
Our app downloads the disk image, and verifies the SHA-512 hash of the download
Our app mounts the DMG
Our app uses /usr/sbin/pkgutil --check-signature (although I do hope to switch to SecStaticCodeCheckValidity() in the future) to verify that
the OS thinks that the installer package is properly signed, and also that
the organization unit on the leaf certificate for the code signing key used to sign the installer is exactly equal to our Apple Team ID
Our app uses /usr/sbin/installer -package ... -volinfo to verify that the installer package thinks it can install onto the host
Our app uses /usr/sbin/installer -package ... -target / to install the software update
For 98%+ of our users, this update process works great. For a tiny portion of users, we're seeing that hdiutil reports that it failed to attach the disk image. For the even tinier portion of users from whom we have obtained debug logs, one of the errors we've seen is "not recognized"; however, I don't know if that's the most common error, due to the small sample size.
Before I get much further, I think it's prudent to acknowledge that the above system we're using today is pushing a decade old now, and it's probably wise to verify the foundations.
So...
For a Developer-ID-signed macOS app that is distributed outside the Mac App Store using an installer package, what is the "best" container/packaging system for an automated system to obtain and consume the installer package with the goal of a user-initiated self-update? For example:
Notarized disk image (and failures to attach the image need to be bug reports to Apple)
Just the installer package (If I understand correctly, this is bad because it bypasses the automatic propagation (normally performed by macOS) of the DMG's notary ticket to the pkg, right?)
Something else?
Secondly, what are some common developer mistakes to avoid? For example, these come to mind:
When saving the DMG to disk, explicitly enable quarantine on the DMG, so that macOS runs appropriate security checks as intended (is this correct?)
When running the installer package, do not use low-level tools (like cp) to copy the pkg out of the DMG, because macOS won't be able to automatically find the notary ticket when the pkg is installed (is this correct?)
Anything else?
Additional context:
We currently support macOS 10.13+, but we will soon support only macOS 10.15+.
Thank you!
I got the python app notarized and downloaded it fine.
However, if you are caught by Gatekeeper and open the information window, you will see a lock and even if you enter the password to open the lock, it will not work.
xattr -d com.apple.quarantine ./test.app
You have to exclude it from the gatekeeper directly.
I wonder if the downloaded app is unavoidable... or if there is another way.
I have an installation workflow that works by a user double clicking on the mpkg and going through the prompts to install some software. Within the postinstall of the mpkg, /usr/sbin/installer -pkg "path_to_pkg" -target / is done to install additional software.
The software contained in the mpkg contains system extensions and installs without issue.
The software contained in the pkg file also contains system extensions and a prompt with this message displayed.
"XSoftware" is damaged and can't be opened. You should move it to the Trash
This file was downloaded on an unknown date.
This is causing issues with the system extension being installed from XSoftware.
Curiously enough, when I run /usr/sbin/installer -pkg "path_to_pkg" -target / manually in a terminal window it works successfully and XSoftware is able to install the System Extensions and run properly.
I've used the pkgutil --check-signature to check the notarization and signing and it looks correct.
This is my dmg structure:
dmg
|
mpkg
data_folder
|
pkg
Any suggestions or help would be greatly appreciated. I can provide more details if neccessary.
Hi, we have an app that has been in development since Catalina and ever since Sonoma came out we noticed that when executing our pkg installer the application is installed correctly but the postinstall script is not executed.
The weird thing is that if I run the pkg for the first time the postinstall does not execute BUT if I run it again then it DOES!!
Looking through the logs I found these ones that confirm the execution of the script is being blocked. We haven't changed anything in the way we build the installer so I'm not quite sure how to fix this.
2024-04-25 16:29:51.570662-0300 0x1c62 Error 0x0 308 0 syspolicyd: [com.apple.syspolicy.exec:default] Unable (errno: 2) to read file at <private> for pid: 784 process path: <private> library path: (null)
2024-04-25 16:29:51.570662-0300 0x1c62 Error 0x0 308 0 syspolicyd: [com.apple.syspolicy.exec:default] Terminating process due to Malware rejection: 784, <private>
2024-04-25 16:29:51.570679-0300 0x1d13 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Sleep interrupted, signal 0x100
2024-04-25 16:29:51.570682-0300 0x1d13 Default 0x0 0 0 kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: 784, /private/tmp/PKInstallSandbox.m5Av3O/Scripts/com.mycompany.myapp.pkg.BSOjtt/postinstall
The app as well as the installer are both signed, notarized and stapled. Here you can see the script which just simply executes the app.
#!/bin/bash
echo "Running postinstall"
/Applications/myapp.app/Contents/MacOS/myapp --load-system-extension &
exit 0
Any help would be much appreciated. Thanks!
Hi everyone,
Has this every happened to you? If so, how did you resolve it?
Submitting my app for review, I got the following rejection:
Guideline 2.4.5(ii) - Performance
The package currently available in App Store Connect cannot be installed and may be corrupted.
Next Steps
Please rebuild your application and upload a new version. If this issue continues, please contact Apple Developer Technical Support for help investigating the issue.
DTS referred me back to app review:
We are unable to help you resolve this matter. Please circle back with the App Review team for assistance.
I'm building the .pkg with productbuild:
xcrun productbuild --product WFH\ Phone\ Webcam.app/Contents/Info.plist --component WFH\ Phone\ Webcam.app /Applications --sign "3rd Party Mac Developer Installer: Mansour Moufid (42A2D88R9U)" --timestamp WFH\ Phone\ Webcam.pkg
and uploading it with altool:
xcrun altool --username "..." --password "..." --validate-app --file WFH\ Phone\ Webcam.pkg --type osx
xcrun altool --username "..." --password "..." --upload-app --file WFH\ Phone\ Webcam.pkg --type osx
The .pkg signature looks fine:
xcrun pkgutil --check-signature WFH\ Phone\ Webcam.pkg
Package "WFH Phone Webcam.pkg":
Status: signed by a developer certificate issued by Apple (Development)
Signed with a trusted timestamp on: 2024-04-29 14:11:27 +0000
Certificate Chain:
1. 3rd Party Mac Developer Installer: Mansour Moufid (42A2D88R9U)
Expires: 2025-03-13 20:11:55 +0000
SHA256 Fingerprint:
CB 8A 12 1D 4D 16 29 27 08 30 07 1C 6C F6 1C F4 85 6E AE F1 B1 34
68 F7 81 6D C3 3B 1B 8C 5D 32
------------------------------------------------------------------------
2. Apple Worldwide Developer Relations Certification Authority
Expires: 2030-02-20 00:00:00 +0000
SHA256 Fingerprint:
DC F2 18 78 C7 7F 41 98 E4 B4 61 4F 03 D6 96 D8 9C 66 C6 60 08 D4
24 4E 1B 99 16 1A AC 91 60 1F
------------------------------------------------------------------------
3. Apple Root CA
Expires: 2035-02-09 21:40:36 +0000
SHA256 Fingerprint:
B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED 7E 2C
68 C5 BE 91 B5 A1 10 01 F0 24
The app's signature also checks out:
codesign --strict --deep --verbose --verify WFH\ Phone\ Webcam.app
WFH Phone Webcam.app: valid on disk
WFH Phone Webcam.app: satisfies its Designated Requirement
I have no idea what "cannot be installed and may be corrupted" means and app review is not responding to my request for more information...
I have two apps written in MAUI Mac Catalyst Framework -- one is main app, second is app updater. My updater works this way: it is located in the same directory as main app: firstly it deletes MainApp.app/Contents folder, then unzips new Contents folder that was downloaded from server.
I added NSUpdateSecurityPolicy dictionary as in https://developer.apple.com/documentation/bundleresources/information_property_list/nsupdatesecuritypolicy and create application like . It looks that I wrote everything fine
pkgbuild --install-location '/Library/Application Support/First' --root root --ownership preserve # aslo signing, etc
But on user's macOS, system does not allow to delete Contents folder: I have IO_Access denied exception. Can it be because main app is sandboxing or something else?
What I can do wrong? Thanks a lot in advance!