Hello I jump on my mac every 3-4 months to release new version of my apps. Process usually is "ok" some cmake/compile issues as 99% of dev is done on windows but other than that its all good. But now I'm stuck. My app can run locally/start etc just fine, but clients are panicking because they can't run them. They have undefined developer warning. I don't understand this. Its notarised and been working for 2 years. What am I doing wrong ?! How can I test it ? I tried creating new user-profile on my mac, but there is no issue, app starts. Do I need to buy ANOTHER mac to test my apps before release ?! Can any1 help how to debug this issue? I'm lost, I used finder-compress myapp.app & send it via slack to client to get him quickly going but that does not help either. - I though it was zip stripping down data or something. Anyway, very frustrated here, and lost. Can any1 help? hint? Is this good resource to check against? https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html I've run spctl --assess --type execute myApp and I'm getting rejected (bundle format is ambiguous (could be app or framework)) But then why does it notarize/sign/etc with no errors ?! I'm so lost :- (((( Any help would be greatly appreciated I've attached app content > Ok I've tested my older releases, they all have the same issue but they all work on client system. I'm so lost :- (((

Hi, I've ran into an issue which only seems to affect one of my macs. It's currently running 14.2.1 but I first saw this issue in 13.6. If I download the macOS Sonoma 14.2.1 installer (via App store) onto this particular machine, it will never execute the installer. It always reports that the installer is "damaged". Of course I did reasearch this online and you get the usual unhelpful posts which just say "re download it" and of course, I wouldn't be posting here had I not tried that. This happens with any macOS installer I download using the softwareupdate --fetch-full-installer utility as well. The thing is, if I copy this .app to another (identical as far as I can tell) Mac - it will work. So far this also seems limited to macOS installers - other third party apps are fine. I'm convinced this is related to trusted execution and something has gone wrong in the environment. I've been looking at my router logs to see if any connections may have been blocked (I'm using OPNsense) and also looking to see what connections are being made via Little Snitch and so far it looks fine. Again, other machines on the network can run these just fine. I've read through eskimo's excellent guide here: https://forums.developer.apple.com/forums/thread/706442 but I was wondering if anyone can give me some pointers to narrow this down further. As it stands, I can't trust this machine for app development if I can't even get the official Apple installers to run sucessfully.

I help a lot of developers with macOS trusted execution problems. For example, they might have an app being blocked by Gatekeeper, or an app that crashes on launch with a code signing error. If you encounter a problem that’s not explained here, start a new thread with the details. Make sure to add relevant tags — like Gatekeeper, Code Signing, and Notarization — so that I see your post. IMPORTANT macOS 14 has a new tool, syspolicy_check, that was specifically designed to help diagnose problems like this. I plan to update this post once I have more experience with it. In the meantime, however, if you hit a trusted execution problem and it reproduces on macOS 14, please try out syspolicy_check and let us know how that pans out. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Trusted Execution Problems macOS supports three software distribution channels: The user downloads an app from the App Store. The user gets a Developer ID-signed program directly from its developer. The user builds programs locally using Apple or third-party developer tools. The trusted execution system aims to protect users from malicious code. It’s comprised of a number of different subsystems. For example, Gatekeeper strives to ensure that only trusted software runs on a user’s Mac, while XProtect is the platform’s built-in anti-malware technology. Note To learn more about these technologies, see Apple Platform Security. If you’re developing software for macOS your goal is to avoid trusted execution entanglements. You want users to install and use your product without taking any special steps. If, for example, you ship an app that’s blocked by Gatekeeper, you’re likely to lose a lot of customers, and your users’ hard-won trust. Trusted execution problems are rare with Mac App Store apps because the Mac App Store validation process tends to catch things early. This post is primarily focused on Developer ID-signed programs. Developers who use Xcode encounter fewer trusted execution problems because Xcode takes care of many code signing and packaging chores. If you’re not using Xcode, consider making the switch. If you can’t, consult the following for information on how to structure, sign, and package your code: Placing Content in a Bundle Embedding Nonstandard Code Structures in a Bundle Embedding a Command-Line Tool in a Sandboxed App Creating Distribution-Signed Code for Mac DevForums post Packaging Mac Software for Distribution DevForums post Gatekeeper Basics User-level apps on macOS implement a quarantine system for new downloads. For example, if Safari downloads a zip archive, it quarantines that archive. This involves setting the com.apple.quarantine extended attribute on the file. Note The com.apple.quarantine extended attribute is not documented as API. If you need to add, check, or remove quarantine from a file programmatically, use the quarantinePropertiesKey property. User-level unarchiving tools preserve quarantine. To continue the above example, if you double click the quarantined zip archive in the Finder, Archive Utility will unpack the archive and quarantine the resulting files. If you launch a quarantined app, the system invokes Gatekeeper. Gatekeeper checks the app for problems. If it finds no problems, it asks the user to confirm the launch, just to be sure. If it finds a problem, it displays an alert to the user and prevents them from launching it. The exact wording of this alert varies depending on the specific problem, and from release to release of macOS, but it generally looks like the ones shown in Apple > Support > Safely open apps on your Mac. The system may run Gatekeeper at other times as well. The exact circumstances under which it runs Gatekeeper is not documented and changes over time. However, running a quarantined app always invokes Gatekeeper. Unix-y networking tools, like curl and scp, don’t quarantine the files they download. Unix-y unarchiving tools, like tar and unzip, don’t propagate quarantine to the unarchived files. Confirm the Problem Trusted execution problems can be tricky to reproduce: You may encounter false negatives, that is, you have a trusted execution problem but you don’t see it during development. You may also encounter false positives, that is, things fail on one specific Mac but otherwise work. To avoid chasing your own tail, test your product on a fresh Mac, one that’s never seen your product before. The best way to do this is using a VM, restoring to a snapshot between runs. For a concrete example of this, see Testing a Notarised Product. The most common cause of problems is a Gatekeeper alert saying that it’s blocked your product from running. However, that’s not the only possibility. Before going further, confirm that Gatekeeper is the problem by running your product without quarantine. That is, repeat the steps in Testing a Notarised Product except, in step 2, download your product in a way that doesn’t set quarantine. Then try launching your app. If that launch fails then Gatekeeper is not the problem, or it’s not the only problem! Note The easiest way to download your app to your test environment without setting quarantine is curl or scp. Alternatively, use xattr to remove the com.apple.quarantine extended attribute from the download before you unpack it. For more information about the xattr tool, see the xattr man page. Trusted execution problems come in all shapes and sizes. The remaining sections address the most common ones. App Blocked by Gatekeeper If your product is an app and it works correctly when not quarantined but is blocked by Gatekeeper when it is, you have a Gatekeeper problem. For advice on how to investigate such issues, see Resolving Gatekeeper Problems. App Can’t Be Opened Not all failures to launch are Gatekeeper errors. In some cases the app is just broken. For example: The app’s executable might be missing the x bit set in its file permissions. The app’s executable might be subtly incompatible with the current system. A classic example of this is trying to run a third-party app that contains arm64e code. macOS requires that third-party kernel extensions use the arm64e architecture. In other circumstances, stick to arm64 for your shipping products. If you want to test arm64e code locally, see Preparing Your App to Work with Pointer Authentication. The app’s executable might claim restricted entitlements that aren’t authorised by a provisioning profile. Or the app might have some other code signing problem. Note For more information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. In such cases the system displays an alert saying: The application “NoExec” can’t be opened. [[OK]] Note In macOS 11 this alert was: You do not have permission to open the application “NoExec”. Contact your computer or network administrator for assistance. [[OK]] which was much more confusing. A good diagnostic here is to run the app’s executable from Terminal. For example, an app with a missing x bit will fail to run like so: % NoExec.app/Contents/MacOS/NoExec zsh: permission denied: NoExec.app/Contents/MacOS/NoExec And an app with unauthorised entitlements will be killed by the trusted execution system: % OverClaim.app/Contents/MacOS/OverClaim zsh: killed OverClaim.app/Contents/MacOS/OverClaim In some cases running the executable from Terminal will reveal useful diagnostics. For example, if the app references a library that’s not available, the dynamic linker will print a helpful diagnostic: % MissingLibrary.app/Contents/MacOS/MissingLibrary dyld[88394]: Library not loaded: @rpath/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing … zsh: abort MissingLibrary.app/Contents/MacOS/MissingLibrary Code Signing Crashes on Launch A code signing crash has the following exception information: Exception Type: EXC_CRASH (SIGKILL (Code Signature Invalid)) The most common such crash is a crash on launch. To confirm that, look at the thread backtraces: Backtrace not available For steps to debug this, see Resolving Code Signing Crashes on Launch. One common cause of this problem is running distribution-signed code. Don’t do that! For details on why that’s a bad idea, see Don’t Run App Store Distribution-Signed Code. Code Signing Crashes After Launch If your program crashes due to a code signing problem after launch, you might have encountered the issue discussed in Updating Mac Software. Non-Code Signing Failures After Launch The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. If you suspect that your code is incompatible with the hardened runtime, see Resolving Hardened Runtime Incompatibilities. App Sandbox Inheritance If you’re creating a product with the App Sandbox enabled and it crashes with a trap within _libsecinit_appsandbox, it’s likely that you’re having App Sandbox inheritance problems. For the details, see Resolving App Sandbox Inheritance Problems. Library Loading Problem Most library loading problems have an obvious cause. For example, the library might not be where you expect it, or it might be built with the wrong platform or architecture. However, some library loading problems are caused by the trusted execution system. For the details, see Resolving Library Loading Problems. Explore the System Log If none of the above resolves your issue, look in the system log for clues as to what’s gone wrong. Some good keywords to search for include: gk, for Gatekeeper xprotect syspolicy, per the syspolicyd man page cmd, for Mach-O load command oddities amfi, for Apple mobile file integrity, per the amfid man page taskgated, see its taskgated man page yara, discussed in Apple Platform Security ProvisioningProfiles Here’s a log command that I often use when I’m investigating a trusted execution problem and I don’t know here to start: % log stream --predicate "sender == 'AppleMobileFileIntegrity' or sender == 'AppleSystemPolicy' or process == 'amfid' or process == 'taskgated-helper' or process == 'syspolicyd'" For general information the system log, see Your Friend the System Log. Revision History 2024-01-12 Added a specific command to the Explore the System Log section. Change the syspolicy_check callout to reflect that macOS 14 is no longer in beta. Made minor editorial changes. 2023-06-14 Added a quick call-out to the new syspolicy_check tool. 2022-06-09 Added the Non-Code Signing Failures After Launch section. 2022-06-03 Added a link to Don’t Run App Store Distribution-Signed Code. Fixed the link to TN3125. 2022-05-20 First posted.

Hi! I am wondering about certain features that I witnessed today. Base scenario: I created a developer certificate signed version of my installer package and then downloaded it via the internet. It has not been notarized. As expected, macOS prevented the opening of the package, stating that it could not be determined whether it contained for malicious content. But, several operations I then performed made this package trusted by macOS: I moved the package through a file-sharing service via Finder, namely OneDrive. The recipient machine immediately opened the unsigned package, without any interruption from the operating system. This sounds extremely unsecure. I checked manually with xattr, and indeed, the com.apple.quarantine attribute has been removed on the recipient side. I used pkgutil to explode the package, modified some files in it, then recompiled it. xattr again confirmed that the quarantine attribute has been removed. Why can pkgutil operate on untrusted packages? I have personally been extremely surprised operations as simple as these remove security hurdles in macOS. These scenarios can be harmful for end-users who have little IT knowledge. Why are they allowed? Are these scenarios considered the responsibility of end-users? Why do we notarize and sign with precious distribution certificates if it's this simple to bypass any security check on macOS? :(

I want to distribute my app with my developer ID. This works fine in a dmg or zip container if I download it on another Mac by FTP. But if I download it by HTTPS macOS brings a Popup: “Rocrail.app” is damaged and can’t be opened. You should move it to the Bin. I don't understand the diff between FTP and HTTPS download... How can I fix this?

Have been using a Mac for about a month, but am a 48-year engineer. Too many operating systems to list. Have my cross-platform self-contained Java application looking great on macOS with all the cool Mac conventions and a DMG "installer". Am attempting to get the existing self-updater working for macOS. It has conditional logic based on the operating system. But I'm stuck ... this is on a Macbook Pro 13" Retina Late 2013 2.8Ghz running macOS Big Sur 11.7.10 (fully updated). Deliberately supporting older hardware due to the nature of the application. The Process in Short Main program downloads updater program into a system temp directory Mounts updater DMG image with -mountroot in that directory Executes updater .app Exits Updater program downloads new Main program Mounts new program DMG image in the system temp directory The DMG image is the same one used for initial installations Makes back-ups of the Java and Plugins directories of existing program Copies the new Java and Plugins directories to existing Main program locations Umounts new program DMG image Either deletes back-up directories or restores them based on success or failure Restarts Main program .app Exits Main program receives special argument indicating success or failure of update Unmounts updater DMG image Displays appropriate dialog Issues The problems encountered are the mounting and unmounting of the DMG images executing hdiutil with Java Runtime.getRuntime().exec(). All mounts and unmounts have 1.5 sec. time-delayed retries for 3 attempts The initial download, mount, and execution of the updater works The mounting of the downloaded update DMG fails Running the command by hand works When the Main program is restarted the unmount of the updater DMG fails Running the command by hand works Also - these are unsigned images at this point. Have been unsure whether I would support macOS. But this is the last stumbling block. Questions Odd point - the initial download, mount and execution of the updater works Is this all because the DMG images are not signed (yet), so hdiutil is failing? Or is there something basic that I'm missing? Thank You For taking your time to read this. Any pointers would be appreciated. The Project https://github.com/Corionis/ELS/tree/Version-4.0.0 (not released) Component projects: https://github.com/Corionis

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!

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 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

To ship a product outside of the Mac App Store, you must notarise it. The notary service issues a notarised ticket, and the ultimate consumer of that ticket is Gatekeeper. However, Gatekeeper does not just check the ticket; it also applies a variety of other checks, and it’s possible for those checks to fail even if your notarised ticket is just fine. To avoid such problems showing up in the field, test your product’s compatibility with Gatekeeper before shipping it. To do this: Set up a fresh machine, one that’s never seen your product before. If your product supports macOS 10.15.x, x < 4, the best OS version to test with is 10.15.3 [1]. Download your product in a way that quarantines it (for example, using Safari). Disconnect the machine from the network. It might make sense to skip this step. See the discussion below. Install and use your product as your users would. If the product is signed, notarised, and stapled correctly, everything should work. If not, you’ll need to investigate what’s making Gatekeeper unhappy, fix that, and then retest. For detailed advice on that topic, see Resolving Trusted Execution Problems. Run this test on a fresh machine each time. This is necessary because Gatekeeper caches information about your product and it’s not easy to reset that cache. Your best option is to do this testing on a virtual machine (VM). Take a snapshot of the VM before the first test, and then restore to that snapshot when you want to retest. Also, by using a VM you can disable networking in step 3 without disrupting other work on your machine. The reason why you should disable networking in step 3 is to test that you’ve correctly stapled the notarised ticket on to your product. If, for some reason, you’re unable to do that stapling, it’s fine to skip step 3. However, be aware that this may cause problems for a user if they try to deploy your product to a Mac that does not have access to the wider Internet. For more background on this, see The Pros and Cons of Stapling. [1] macOS 10.15.4 fixes a bug that made Gatekeeper unnecessarily strict (r. 57278824), so by testing on 10.15.3 you’re exercising the worst case. The process described above is by far the best way to test your Gatekeeper compatibility because it accurately tests how your users run your product. However, you can also run a quick, albeit less accurate test, using various command-line tools. The exact process depends on the type of product you’re trying to check: App — Run spctl like this: % spctl -a -t exec -vvv WaffleVarnish.app Disk image — Run spctl like this: % spctl -a -t open -vvv --context context:primary-signature WaffleVarnish.dmg Installer package — Run spctl like this: % spctl -a -t install -vvv WaffleVarnish.pkg Other code — Run codesign like this: % codesign -vvvv -R="notarized" --check-notarization WaffleVarnish.bundle Note The last command requires macOS 10.15 or later. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision history: 2023-10-20 Added links to Resolving Trusted Execution Problems and The Pros and Cons of Stapling. Made other minor editorial changes. 2021-02-26 Fixed the formatting. 2020-04-17 Added the section discussing spctl. 2020-03-25 First version.

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?

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"

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

HOla Alguien sabe como cambiar el nombre cuando publico alguna App por error puse mi nombre personal, pero me gustaria cambiarlo... es el nombre del creador de la App