Our updating process is a launchd daemon that will download zipped bundle directories that contain resources to be used for updating. One of the bundles is an app that has a tool that is executed to perform the updating after all of the bundles have been downloaded. We are finding that on Sonoma starting in version 14.1 the zip extraction of the bundle containing the executable now is blocked on about 1 in 7 computers when the bundle directory itself is being created. <redacted>Updater <subsystem> Error during Extract state: Error Domain=<our error domain> Code=2001 "filesystem error: in create_directories: Operation not permitted ["/Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle"]" UserInfo={NSLocalizedDescription=filesystem error: in create_directories: Operation not permitted ["/Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle"]} We have seen the following error just preceding the above on some of these failures: <date> Error 0x45c755 184 0 sandboxd: tcc_server_message_request_authorization(kTCCServiceSystemPolicyAppBundles) failed: Error Domain=kTCCErrorDomain Code=2 "missing 'auth_value' in reply message" UserInfo={NSDescription=missing 'auth_value' in reply message} <date> Error 0x0 184 0 sandboxd: [com.apple.sandbox.reporting:violation] System Policy: <redacted>Updater(1431) deny(1) file-write-create /Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle Violation: deny(1) file-write-create /Library/Caches/<reverse-DNS name>/<redacted>Installer.bundle I believe that the kTCCServiceSystemPolicyAppBundles failure occurs because TCC has determined that our Updater does not have permission to modify the Installer.bundle. Both the Updater and Installer.bundle have been signed by the same Apple Developer certificate (with the same team id). The Updater has been using this same procedure successfully but starts failing after the update to Sonoma v14.1. When this failure occurs, the updater has been able to extract the other resource-only bundles (no executables) that precede it. Computers that have this failure show the updater in the System Settings > Privacy & Security > Full Disk Access list as disabled. The computers that do not see this failure, do not have the updater listed in Full Disk Access. This has been raised as Feedback #FB13359407 What is the recommended way that an updater is supposed to create a new copy of an application without running into these TCC errors? Would extracting the app bundle as a directory without the .bundle extension and then renaming the directory to add the .bundle extension be a reasonable approach? BTW: The above approach does seem to work on Sonoma v 14.1 At what point does an app become subject to kTCCServiceSystemPolicyAppBundles? Is it is just a directory with a .app or .bundle extension or when a bundle structure exists that a signing check can validate?

Have been working on a Java Open Source project for 8 years with the last 2+ years on a cross-platform desktop GUI for it with a separate updater. The self-contained application runs on Linux and Windows - now I'm trying to figure-out Mac. Have had a Macbook Pro 13" Late 2013 Retina running Big Sur 11.7.10 for 3 weeks. Very new to Apple, but a retired 48-year engineer trying to support MacOS for the first time. Building with Ant and appbundler task, https://github.com/TheInfiniteKind/appbundler, then creating a DMG with DMG Canvas, https://www.araelium.com/dmgcanvas. Deliberately supporting older systems due to the nature of this data management and back-up application. It's been adapted to the MacOS look 'n feel. Questions: If I sign-up as an Apple Developer and pay the fee will this 2013 Macbook Pro still be able to sign DMG files - that will work on the latest MacOS - after the end-of-support in December 2023? For a updater: Should both the main application and separate updater both be signed? The basic process is: Download updater into system temp folder, prepare and execute updater, stop desktop application, updater downloads new version, prepares and copies update to installed location, then restarts desktop application and ends the updater. I'm old and have setup this Open Source project and web site so that it can be passed-off to others when I stop, one way or another. Can the developer account or certificate credentials be transferred to someone else at that time? Guidance for a noob would be appreciated. Thank you for your time. The project, not released yet: https://github.com/Corionis/ELS/tree/Version-4.0.0

I've built an app in Electron. I am in the process of preparing to release the app on my website as a free download. Since the app is free, I'm not really looking to spend a ton of money on security certificates. I can get the app to work on Windows by clicking through the Windows Defender, but I cannot run it at all on Mac even after disabling Gatekeeper. So my question is... Is it possible for me to get a certificate for my Electron app through the apple developer program. Keep in mind I have never touched the apple developer ecosystem. Avoiding subscriptions for this app's security certificates is what I am looking for. As that is all I have seen as options online so far. Any other suggestions are more than welcome! Thanks in advance!

I have a toy application that uses CMake to generate a .dmg that contains a simple c++ binary that prints "codesignTest". The binary gets signed by CMake, and I manually sign the .dmg. I am using the "Unix Makefiles" generator, and am signing with a Developer ID Application certificate with a Private Key. Despite this, I still get an "App is damaged and can't be opened" error when running the binary on a secondary test MacOS machine. I've created a github repository with instructions on how to reproduce this problem, and I've copy/pasted the binary's signature below. Is there anything invalid with my signature? Thank you. cisl-ridgeland:~ pearse$ codesign -dv --verbose=4 /Applications/codesignTest.app/Contents/MacOS/codesignTest Executable=/Applications/codesignTest.app/Contents/MacOS/codesignTest Identifier=codesignTest Format=bundle with Mach-O thin (arm64) CodeDirectory v=20400 size=496 flags=0x0(none) hashes=10+2 location=embedded VersionPlatform=1 VersionMin=786432 VersionSDK=787200 Hash type=sha256 size=32 CandidateCDHash sha256=df158907d48f1eb3f5ef7b145d43d114bff0c6c3 CandidateCDHashFull sha256=df158907d48f1eb3f5ef7b145d43d114bff0c6c3e2564197c4a69594500f7f66 Hash choices=sha256 CMSDigest=df158907d48f1eb3f5ef7b145d43d114bff0c6c3e2564197c4a69594500f7f66 CMSDigestType=2 Executable Segment base=0 Executable Segment limit=16384 Executable Segment flags=0x1 Page size=4096 Launch Constraints: None CDHash=df158907d48f1eb3f5ef7b145d43d114bff0c6c3 Signature size=9045 Authority=Developer ID Application: University Corporation for Atmospheric Research (DQ4ZFL4KLF) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Nov 1, 2023 at 9:43:36 AM Info.plist=not bound TeamIdentifier=DQ4ZFL4KLF Sealed Resources=none Internal requirements count=1 size=172

Hello, I have made a basic c program and i have compiled it with gcc. This program has not been signed (i didn't run codesign). When i am trying to run this program from terminal, i don't get any Gatekeeper popup. My first question is... why ? I have create a SwiftUI project with Xcode (Xcode 15). I have set signing settings to "Sign to run locally" (by the way, can you tell me how i can disable signing in Xcode ?) I have opened terminal and i have changed current directory to ~/Library/Developer/Xcode/DerivatedData/..../Products/Debug/MyApp.app/Contents/MacOS folder. Now i get a gatekeeper confirmation popup if run "./Myapp" from terminal. My second question is... Why ? Does that mean Gatekeeper only checks signed binaries ? Thanks

I have created a .Net MAUI application that I have written for Windows and MacCatalyst. In my entitlements.plist I have com.apple.security.app-sandbox = no. <PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net7.0-maccatalyst|AnyCPU'"> <MtouchLink>SdkOnly</MtouchLink> <EnableCodeSigning>True</EnableCodeSigning> <EnablePackageSigning>true</EnablePackageSigning> <CreatePackage>true</CreatePackage> <CodesignKey>Developer ID Application: xxxxxxxxxx</CodesignKey> <CodesignProvision>xxxxxxxx</CodesignProvision> <CodesignEntitlements>Platforms\MacCatalyst\Entitlements.plist</CodesignEntitlements> <PackageSigningKey>Developer ID Installer: xxxxxxxxx</PackageSigningKey> <UseHardenedRuntime>true</UseHardenedRuntime> <RuntimeIdentifier>maccatalyst-arm64</RuntimeIdentifier> <MtouchInterpreter>-all</MtouchInterpreter> </PropertyGroup> I have a 3rd party executable that I manually codesigned: codesign --force --verify --verbose --sign xxxxxx 3rdpartyApp --timestamp --deep --options runtime Then I build the application in Visual Studio Mac. Everything is codesigned, etc. After building I am able to successfully notarize the pkg and then staple the the notarization to it. When I take that pkg and install it in a test environment, everything installs fine, no warning. I am able to start my application and do what I need to do But when it tries to run that 3rd party executable, it just fails. At first I checked exec permissions. I chmod it to +x. within the .app container and also all the way at the beginning, and rebuilt the application, resigned, re-notarized, etc. I am working to get some logging out to see why it failed, but having an issue with that at the moment. In the meantime I have taken the non-notarized pkg, forced the install in the test environment and the 3rd party executable runs successfully. So it seems the notarization process is causing this child process to fail?

Hi Team, I am unable to run the chrome driver exe when running automated tests using IntelliJ Idea and getting the following error Regards, Akshay

I have a macOS app that I have been distributing for free outside the app store for more than 15 years, without notarization, without sandboxing, and without hardened runtime, all with no problems. If I understand correctly, macOS will soon be modified so that it will not launch any developer-distributed apps that are not notarized. Notarization will require both hardened runtime and sandboxing, and unhappily, my app will not run when notarized -- I have added sandboxing and hardened runtime, than gotten it notarized and tried -- and that is because it will not run when sandboxed. Thus I have two questions: Will there be some means, that I perhaps have missed, for my users to run my app as is, in un-notarized form with no sandboxing and no hardened runtime? (Assume that they are willing to click "Okay" on any macOS popups of the form "Abandon hope, all ye who enter here.") Perhaps I have missed something about the signing or distribution process ... ? If not, is there some entitlement I can obtain to allow my app to run when sandboxed? Perhaps the question is even "Should there be such an entitlement?" And to that end, I must now explain why it cannot run sandboxed: My app is a parallel processing system: To work properly it must open multiple copies of itself -- that's right, there will be multiple instances of the app window visible on the console, distinguished by tint, title and location so the user can tell which is which, and multiple app badges in the dock, similarly distinguished. Doing so is easy -- I use the c++ "system" function to call the Unix executable that is buried within the ".app" folder, passing it a command tail whereby the launched copy can tell how to distinguish itself. I build up the text string for the call piece by piece, but the result looks rather like this: system("&lt;path-to-my-app&gt;/MyApp.app/Contents/MacOS/MyApp -tail-item-1 -tail-item-2 ... &amp;"); The app is written in mixed C++ and Objective C. The usual "Main.mm" file contains the entry point for the program, a "main()" function that does nothing but call "NSApplicationMain()", but I have added code to "main()" that runs before the call of NSApplicationMain(). That code uses C function "getopt()" to look for the extra command-tail items. If any are present, the app acts appropriately -- generally assigning non-default values to global variables that are used later in initialization. The first instance of the app that is called -- presumably by the user mousing on an icon somewhere -- knows by the absence of extra command-tail items that it is the first one launched, and thus knows to launch multiple additional instances of itself using this mechanism. The launched instances know by the presence of extra command-tail items that they are not the first one launched, and act differently, based on the command-tail items themselves. All this has been working fine for over a decade when the app is not sandboxed and does not have a hardened runtime. For what it is worth, the app will run with hardened runtime, provided the option "Disable Executable Memory Protection" is checked. Furthermore, when it is also sandboxed and I open it with no extra copies of itself launched (the number to launch is a preferences option), that single app instance runs fine. I have instrumented the code, and what seems to be happening is that the system call to launch another app returns zero -- implying it succeeded -- but has no effect: It is as if someone had special-cased "system" to do nothing, but to report success nonetheless. That is an entirely reasonable feature of a hardened runtime -- allowing arbitrary system calls would be a security disaster looking for a place to happen. The point is that my app would not be making an arbitrary system call -- it would be trying to open one specific app -- itself -- which would be sandboxed with a hardened runtime, and notarized. That is not likely to be a huge security problem. Incidentally, not all system calls fail this way -- I can do system("osascript -e 'tell app \"Safari\" to activate';"); or system( "open -a \"Safari\" &lt;path to a help file located in MyApp's Resources&gt;"); with impunity. Also incidentally, using AppleScript to launch another copy of MyApp from within itself doesn't do what I want: The system notices that MyApp is already running and just makes it active instead of launching a new copy, and there is no way to pass in a command tail anyway. I don't wish to appear to be advertising, so I won't identify my app, but a little more detail might be useful: It is a parallel program interpreter. The language implemented is the "Scheme" dialect of Lisp. Each instance running is a complete read/eval/print loop embedded in an application window where the user can read and type. The first instance of the app launched mmaps a large memory area for the Lisp system's main memory: That works kind of like a big heap in more conventional programs. It is not executable code, it contains Lisp data structures that an application instance can access. The other instances launched use the same mmapped area. The shared memory has lots of lock bits. I use low-level "lockless coding" -- hand-coded assembler with the Intel "lock" prefix or the more complicated arm64 stuff -- to keep simultaneous access by different app instances from corrupting the shared memory. Parallel Scheme has many uses, which include debugging and monitoring of running Scheme programs, and having multiple tail-recursive "actors" (Lisp jargon) operate on the same data at the same time. Enough said. I would like to be able to notarize this app so that users who obtained it outside the app store could understand that Apple had checked it for dangerous code. If that were possible, I might even try submitting it to the app store -- but that would be another story. Do I have any hope of keeping this product available?

I have an App bundle that I signed with the certificate I received from my boss. despite signing and verifying it. it doesn't run on our test Mac without changing the trust settings. It gives an error saying that apple cannot check it for malicious software and software needs to be updated. this is the result of running the code sign verification: `codesign --display --requirements - --verbose=4 ./myapp.app Executable=/Users/*removed*/Documents/test/myapp.app/Contents/MacOS/app Identifier=com.*removed*.*removed*/ Format=app bundle with Mach-O thin (arm64) CodeDirectory v=20400 size=582872 flags=0x0(none) hashes=18208+3 location=embedded VersionPlatform=1 VersionMin=851968 VersionSDK=852736 Hash type=sha256 size=32 CandidateCDHash sha256=*removed* CandidateCDHashFull *removed* Hash choices=sha256 CMSDigest=*removed* CMSDigestType=2 Executable Segment base=0 Executable Segment limit=48218112 Executable Segment flags=0x1 Page size=4096 Launch Constraints: None CDHash=*removed* Signature size=9060 Authority=Developer ID Application: *removed* Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=*Removed* Info.plist entries=15 TeamIdentifier=*Removed* Sealed Resources version=2 rules=13 files=475 designated =&amp;gt; identifier "com.*removed*.*removed*" and anchor apple generic and certificate 1[*removed*] /* exists */ and certificate leaf[*removed*] /* exists */ and certificate leaf[subject.OU] = *removed*` I removed some info as I'm not sure if it'd be safe to share online. I apologize. The projector is written in c++ and uses wxWidgets for GUI

Hi, I have a signed and notarized .pkg file. When I distribute this to my users, they're prompted if "Installer" can access files in the Downloads folder. Most of them click "OK", so that this installer can succeed, however those that click "Don't allow" can never install the .pkg file again. I've checked the following to no obvious resolution: Quarantine flags (no obvious flags were found) System Preferences, Security, Files and Folders (Installer.app is not listed) spctl --list (The .pkg shows there, but nothing obvious about it being blocked) A workaround is to copy this .pkg file to the Desktop folder. When run, the same prompt will appear again, except for the "Desktop" folder. If you click "OK", it succeeds. Since this behavior prevents the .pkg from running from Downloads ever again, how can this be reverted/fixed?

I distribute an application in a zip file from my website. the application needs access to some files next to it to run properly. The application is correctly signed and notarized and stapled.Of course if I download it from my website, it gets the quarantine attribute. When I try to open it for the first time, a gatekeeper warning saying that the application comes from the internet, but has been checked by apple and no malware has been detected is displayed. My impression is that the application has been correctly signed and notarized. but If confirm that I wan to open it, the quarantine attribute is not deleted. spctl -a -v /path/to/Myapp.app path/to/Myapp.app: accepted source=Notarized Developer ID

Hi, I distribute my app for macOS outside AppStore. I implemented Auto Update function which worked perfectly up to Ventura 13.0. And it was broken since Ventura 13.1+ The old version of my app downloads a ZIP arhive with a new version to temporary folder and unpack it to User's Library &gt; Application Support &gt; My AppFolder. The new unpacked version gets attribute com.apple.quarantine and the old app cannot run it. Before Ventura 13.1 the new unpacked app could be run successfully and it closes the old version and replaces the old APP bundle in Applications. And then a copy of new app in a temporary folder is being deleted. In fact, the new APP could work as an agent to perform the update of my app. Both apps (old and new) are signed and notarized by one team (the same signature).

from some reason after some time my application dmg was signed and worked perfectly fine i started to get "cannot be opened because the developer cannot be verified." when clicking on the application after it was installed. when running the signing process i get Current status: Accepted...............Processing complete when checking the Submission ID received at apple it also showed approved what other issues might it be?

Submit my app to Mac App Store. workflow: Sign with cert: Developer ID Application ---&gt; Success Notarize ---&gt; Success Sign with cert: 3rd Party Mac Developer Application ---&gt; Success productbuild with cert: 3rd Party Mac Developer Installer, and get .pkg artifact---&gt; Success Transporter upload ---&gt; Success TestFlight notify, and app update to the latest version ---&gt; Success Click open, and then the ERROR comes like the screenshot photo So I'm confusing which step's wrong. And I believe my account certificates, profiles are all configured with no problem. Anybody have any clues? I've been here for many days.

Hi, in the video wwdc2022-10096 at about 05:45 it is explained how to allow other software to update your software by adding team-idetifiers an signing-identifiers to an Info.plist. I would need a few more details. Which Info.plist file do I have to change? I use pkgbuild to build the packages and productbuild to combine them. pkgbuild --analyse --root generates an .plist-file for every single package. Do I have to add the Information there? productbuild --sythesize generates an xml-file discribing the whole thing. This would refer better to the installer as a whole, but it is not an info.plist. How and where exactly to add the information? I tried to use plutil, but it doesn't like array-names to start with numbers as team-identifiers often do. Also it crashes quite often. The .plist-files generated by pkgbuild either contain an empty array or several unnamed items. [ ] Do I even need to add something threre? The other one contains several Items: [   0 => {     "BundleIsRelocatable" => 0     "BundleIsVersionChecked" => 1     "BundleOverwriteAction" => "upgrade"     "NSUpdateSecurityPolicy" => {       "AllowProcesses" => {         "123ABC" => [           0 => "com.example.pal.about"         ]       }     }     "RootRelativeBundlePath" => "Library/PreferencePanes/***.prefPane"   }   1 => {     "BundleIsRelocatable" => 0     "BundleIsVersionChecked" => 1     "BundleOverwriteAction" => "upgrade"     "NSUpdateSecurityPolicy" => {       "AllowProcesses" => {         "123ABC" => [           0 => "com.example.pal.about"         ]       }     }     "RootRelativeBundlePath" => "Library/Frameworks/***.framework"   }   2 => {     "BundleHasStrictIdentifier" => 1     "BundleIsRelocatable" => 0     "BundleIsVersionChecked" => 1     "BundleOverwriteAction" => "upgrade"     "NSUpdateSecurityPolicy" => {       "AllowProcesses" => {         "123ABC" => [           0 => "com.example.pal.about"         ]       }     }     "RootRelativeBundlePath" => "Applications/***.app"   } ] Should it look like this? A more detailed example would be great. Thanks!

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 Testing a Notarised Product DevForums post Resolving Trusted Execution Problems DevForums post App Translocation Notes DevForums post WWDC 2022 Session 10096 What’s new in privacy covers some important Gatekeeper changes in macOS 13 (starting at 04:‍32) WWDC 2023 Session 10053 What’s new in privacy covers an important change in macOS 14 (starting at 17:46) 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"