I send a Requesting a Developer ID Certificate for Signing Kexts. But there was no response in the past two months. How can I know the progress?

The issue around CERTIFICATES and their RANDOM REVOCATION is one that I just can’t get my head around, as hard as I may try. I’ve read “Certificate Signing Requests Explained” and most others that one would consider relevant and I’d like to say “I get it” except…I don’t. At least not well enough to prevent what I’m encountering. I have a developer account (at the moment it needs to be renewed) and a dev team (me) that lets me do whatever in Xcode. I’ve compiled several apps for macOS, each of which runs fine, for a time. Then, after a random interval of days or sometimes weeks I get the DREADED EMAIL from Apple that reads: "Your Certificate Has Been Revoked. You have revoked your certificate, so it is no longer valid", and they don’t! Any attempt to start them generates the warning "[This App] will damage your computer. You should move it to the Trash." Each needs to be recompiled with what is apparently a valid certificate courtesy of Xcode to get them to run again, which they do, until the next email from Apple shows up and they don’t. Let me stipulate that I have done nothing overtly to revoke these certificates (6 revocations since April 22) nor have I done anything but use Xcode to automatically manage the creation of new ones. So the ask: what I do I need to do to keep this from happening? PS: I have read numerous places to ignore these emails which I have done without consequence. Only now after I am using several apps that I've created has this become problem.

This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Gatekeeper Problems Caused by Dangling Load Command Paths Gatekeeper strives to ensure that only trusted software runs on a user’s Mac. It’s important that your code pass Gatekeeper. If not, you’re likely to lose a lot of customers, and your users’ hard-won trust. The most common reason for Gatekeeper to block an app is a dangling load command. To understand this issue, you first need to understand library validation. Library validation is an important security feature on macOS. If library validation is enabled on an executable, the process running that executable can only load code signed by Apple or with the same Team ID as the executable. This prevents a wide range of dynamic library impersonation attacks. Library validation is enabled by the Hardened Runtime but you may opt out of it using the Disable Library Validation Entitlement (com.apple.security.cs.disable-library-validation) entitlement. IMPORTANT Leave library validation enabled. Only disable it if your app needs to load plug-ins from other third-party developers. When Gatekeeper checks an app it looks at the state of library validation. If library validation is disabled, Gatekeeper does an extensive check of the app’s Mach-O images in an attempt to prevent dynamic library impersonation attacks. If library validation is enabled, Gatekeeper skips that check because library validation prevents such attacks. The upshot of this is that, if you disable library validation, it’s harder to pass Gatekeeper. Note The Swift Package Manager creates a dangling load command when you build a command-line tool for the Mac. For more on that issue, see the Compiler adds RPATH to executable, making macOS Gatekeeper angry thread on Swift Forums. Find Dangling Load Command Paths If your app is rejected by Gatekeeper, look in the system log for entries like this: type: error time: 2022-05-11 15:00:36.296159 -0700 process: XprotectService subsystem: com.apple.xprotect category: xprotect message: File /Applications/DanglingRPath.app/Contents/MacOS/DanglingRPath failed on rPathCmd /Users/mrgumby/Work/TrustedExecutionFailures/CoreWaffleVarnishing.framework/Versions/A/CoreWaffleVarnishing (rpath resolved to: (path not found), bundleURL: /Applications/DanglingRPath.app) In this example the entry mentions rPathCmd, and that’s a good way to search for such problems. Also search for loadCmd, which indicates a similar problem. IMPORTANT If the paths in the log entry are all <private>, enable private data in the system log. For information on how to do that, see Recording Private Data in the System Log. For general information about the system log, see Your Friend the System Log. In this example Gatekeeper has rejected the DanglingRPath app because: It references a framework, CoreWaffleVarnishing, using an rpath-relative reference. The rpath includes an entry that points outside of the app’s bundle, to a directory called /Users/mrgumby/Work. This opens the app up to a dynamic library impersonation attack. If an attacker placed a malicious copy of CoreWaffleVarnishing in /Users/mrgumby/Work, the DanglingRPath app would load it. To find the offending rpath entry, run otool against each Mach-O image in the app looking for a dangling LC_RPATH load command. For example: % otool -l DanglingRPath.app/Contents/MacOS/DanglingRPath | grep -B 1 -A 2 LC_RPATH Load command 18 cmd LC_RPATH cmdsize 48 path @executable_path/../Frameworks (offset 12) Load command 19 cmd LC_RPATH cmdsize 56 path /Users/mrgumby/Work (offset 12) This app has two LC_RPATH commands. The one, for @executable_path/../Frameworks, is fine: It points to a location within the app’s bundle. In contrast, the one for /Users/mrgumby/Work is clearly dangling. In this example, the dangling rpath entry is in the main executable but that’s not always the case; you might find it lurking in some deeply nested dynamic library. Keep in mind that this is only an issue because the app has library validation disabled: % codesign -d --entitlements - DanglingRPath.app Executable=/Users/mrgumby/Desktop/DanglingRPath.app/Contents/MacOS/DanglingRPath [Dict] [Key] com.apple.security.cs.disable-library-validation [Value] [Bool] true If library validation were enabled, Gatekeeper would skip this check entirely, and thus the app would sail past Gatekeeper. IMPORTANT In this example the app’s main executable has library validation disabled, but that’s not always the case. It’s common to see this problem in app’s that have multiple executables — the app itself and, say, one or two embedded helper tools — where one of the other executables has library validation disabled. Finally, the above example is based on rpath-relative paths. If you see a log entry containing the text loadCmd, search for dangling paths in LC_LOAD_DYLIB load commands. Fix Dangling Load Command Paths The best way to fix this problem is to not disable library validation. Library validation is an important security feature. By disabling it, you introduce this problem and reduce the security of your app. Conversely, by re-enabling it, you fix this problem and you improve security overall. The only situation where it makes sense to disable library validation is if your app loads plug-ins from other third-party developers. In that case, fixing this problem requires you to find and eliminate all dangling load command paths. There are two possibilities here: The dangling load command path is in a Mach-O image that you built from source. Or it’s in a Mach-O image that you got from a vendor, for example, a library in some third-party SDK. In the first case, solve this problem by adjusting your build system to not include the dangling load command path. In the second case, work with the vendor to eliminate the dangling load command path. If the vendor is unwilling to do this, it’s possible, as a last resort, to fix this problem by modifying the load commands yourself. For an example of how you might go about doing this, see Embedding Nonstandard Code Structures in a Bundle. And once you’re done, and your product has shipped, think carefully about whether you want to continue working with this vendor. Revision History 2022-06-13 Added a link to a related Swift Forums thread. 2022-05-20 First posted.

This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving Hardened Runtime Incompatibilities The hardened runtime enables a number of security checks within a process. Some coding techniques are incompatible with the hardened runtime. Best practice is to enable the hardened runtime on all code so that you uncover these problems early. However, some folks only notice these problems when they go to distribute their product. Specifically, Developer ID distribution requires notarisation and the notary service requires the hardened runtime. The typical symptoms of this failure is that the program launches but then fails almost immediately afterwards. Sometimes this failure results in the program just not working, sometimes it triggers a crash, and sometimes the program terminates itself by calling exit. In some cases this failure is accompanied by diagnostic printed to stdout, so it’s worth running the program from Terminal if you can. For advice on how to do that, see Resolving Trusted Execution Problems. If you suspect that this problem is caused by a hardened runtime incompatibility, the diagnostic test is easy: Temporarily disable the hardened runtime and see if the problem goes away. Once you’ve confirmed the problem is an incompatibility with the hardened runtime, you have two choices: Fix your code to avoid the problem. Apply a hardened runtime exception entitlement to disable one specific security feature of the hardened runtime. In general, the first option is best because it leaves your product with the best security. IMPORTANT When confronted by a hardened runtime incompatibility, some folks apply all of the hardened runtime exception entitlements. This is a mistake for three reasons: Some entitlements are subsets of other entitlements. For example, there’s no point applying com.apple.security.cs.allow-unsigned-executable-memory if you’re already applying com.apple.security.cs.disable-executable-page-protection. Disabling library validation with the com.apple.security.cs.disable-library-validation entitlement makes it harder to pass Gatekeeper. For more on this, see Resolving Gatekeeper Problems Caused by Dangling Load Command Paths. The hardened runtime exists for a reason: To enhance your product’s security. Don’t apply a hardened runtime exception entitlement without first understanding what the actual problem is. Debug hardened runtime incompatibilities like you would any other problem: Step through the code, add logging, and so on. The goal is to isolate which part of your code works with the hardened runtime disabled but fails with it enabled. Once you’ve found that code, the fix is usually pretty obvious. For example, if your program needs to generate executable code on the fly, you must: Allocate that memory using mmap with the MAP_JIT flag. Write to that memory using pthread_jit_write_protect_np or one of its related APIs. See the pthread_jit_write_protect_np man page for details. Sign the problem with the com.apple.security.cs.allow-jit entitlement. If you need help with this, feel free to ask here on DevForums. If you don’t control the code that has the hardened runtime incompatibility — this happens most often when using a third-party language runtime — ask the vendor how to proceed. They might have an updated version of their code, or specific advice on what hardened runtime exception entitlements to apply. If their advice is “Apply all the hardened runtime exception entitlements!”, think carefully about your vendor choices (-:

I have an app that I have been distributing on the Mac App Store for the past year. When testing this build, I have always been able to run a debug configuration of the app from Xcode, sign in with a sandbox Apple ID account, and test the features of the app locally. The app would initially attempt to launch from Xcode, immediately close, then prompt me to login with an Apple ID. I would then enter a sandbox environment Apple ID, and the app would re-launch. I could then close the app, run from Xcode, and debug the app normally and be able to attach the debugger to view output. Today when preparing to release a new version to the Mac App Store, I went through the normal routine of trying to test the app locally using the sandbox environment to validate features. I found that I now get an error message stating: “[My App]” is damaged and can’t be opened. Delete “[My App]” and download it again from the App Store. Noting that I had previously submitted using Xcode 12.5, and was now using Xcode 13, I loaded up Xcode 12.5 and went back to the last commit on my branch that was successfully tested locally and submitted to the Mac App Store to rule out any new changes causing the issue. Reverting back has yielded the same result, so I can rule out both code changes causing this, and a change in Xcode versions. I am currently running macOS Big Sur 11.5.2 on a Mac Pro 2019. I have also checked the Security & Privacy pane of the Preferences app to see if I need to allow access to my app, but the button that usually appears to allow an app bypass validation checks never appears. How can I fix this issue and test my macOS app locally before submitting to the Mac App Store as I have previously?

Installation of tested &amp;amp; trusted 3rd party software fails during the verification process. "PKInformSystemPolicyInstallOperation failed with error:An error occurred while registering installation with Gatekeeper."

Our product is distributed as a Mac installer package, and it is only distributed by us, not via the Mac App store. Thus, we have Developer ID certificates to sign both the actual software components within the installer package (Developer ID Application With KEXT - since we have a KEXT), and the installer package itself (Developer ID Installer). Our Developer ID certificates are set to expire next month, so we just created new ones which we are switching to. However, we also maintain an archive of older product installer packages on our website for users that need to run earlier releases for some reason (running on older OS, etc). It sounds like we may need to re-sign those older installers with the new Developer ID Installer cert, as the info here makes it sound like those installers will no longer run after the cert expires: https://developer.apple.com/support/certificates/ https://developer.apple.com/support/developer-id/ We’re trying to get a definitive answer on what we need to do, before it’s too late to do it, but some of the behavior of this certificate stuff is a little confusing (also, I did file a DTS request to get clarification on this, and ultimately they referred me to posting here on the dev forums). Let’s assume all those older installers were signed with our old Developer ID Installer cert, and let’s say that cert expires on 6/1/22. My questions are: 1 ) I assume those installers will now cease to run after 6/1/22, correct? But any installs that ALREADY happened with those installers will continue to work after 6/1/22? This is what the links above suggest, but we specifically want to make sure this is the case for the KEXT, which in those older installers is signed with the older Developer ID Application With KEXT cert which also expires on 6/1/22. [Related question, is there any reliable way to test this? I assume it would be more complicated than just setting the system date on a test machine past 6/1/22…] 2 ) Assuming it is the case that those old installers will no longer run after 6/1/22, do we just need to re-sign those installer packages with our new Developer ID Installer cert? OR, do we additionally need to re-NOTARIZE the installer packages (assuming they need to run on Catalina or later)? [Logically it seems like we need to re-notarize after re-signing, and one test seemed to confirm that, while another similar test done by another developer had different results. I think what happened there was that the developer re-signed the installer with the new cert and saved that off (testA.pkg), then uploaded that installer to the notarization service and saved the result w/stapled ticket as a differently named file (testB.pkg). We figured that when running the “only re-signed" installer (testA.pkg), we would get the gatekeeper error, but we didn’t (also spctl reported it as passing notarization). I assume this is because the same binary installer had already been uploaded for notarization, and something in the OS was able to talk to the notary service and detect that this installer (testA.pkg) was the same as the one that had been uploaded for notarization, hence reporting it passed. I guess that is why the note here about testing notarization mentions testing with network connectivity disabled: https://developer.apple.com/forums/thread/130560] 3 ) Assuming we do need to re-notarize the old installers, do we need to do that before the cert that was used to sign the software components within them expires on 6/1/22? I.e. will the process of notarizing a .pkg look inside the package for executable code bundles, and then fail if a bundle was signed with a now-expired cert? For various reasons it would be difficult to break apart these old installers, re-sign their individual software components with the new Developer ID Application cert, and re-package them. Thanks for any insight!

This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Don’t Run App Store Distribution-Signed Code App Store distribution-signed code is intended to be uploaded to the App Store. You can’t run it locally. Except when you can! To avoid confusing yourself, don’t attempt to run App Store distribution-signed code. Intended Purpose App Store distribution-signed code is intended to be uploaded to the App Store. When you upload code to the App Store, it checks the code’s signature as part of the distribution process. App Store distribution-signed code is not intended to be run locally. That’s what development-signed code is for! If you want to test your App Store product before shipping it to users: For day-to-day work, use Development distribution. For limited testing, use Ad Hoc or Enterprise distribution (not available on macOS) or Developer ID distribution (only available on macOS). For wider testing, use TestFlight. Note Not all capabilities are supported by Developer ID distribution. For the details, see Developer Account Help > Supported capabilities (macOS). macOS Gotcha Most Apple platforms completely block you from running App Store distribution-signed code. The exception here is macOS, which runs distribution-signed code under some circumstances. Specifically, macOS runs distribution-signed code if the code claims no restricted entitlements. If the code claims a restricted entitlement that claim must be authorised by a provisioning profile. It’s not possible to create a profile that does that: A macOS App Development or Developer ID profile never authorises the certificate from your distribution signing identity. A Mac App Store profile never authorises execution on your machine. The lack of a valid profile means that the restriction entitlement is not authorised and your app will crash on launch. For more details on what that crash looks like, see Resolving Code Signing Crashes on Launch. For detailed information about provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. Even though there are some cases where App Store distribution-signed code will run on the Mac, the general rule is the same there as it is for other platforms: Don’t run App Store distribution-signed code. Revision History 2022-06-01 Added App Store to the title to make the subject clearer. Made similar changes throughout the text. 2022-05-31 First posted.

After uploading a new App to the App Store Connect i receive an e-mail stating:ITMS-90034: Missing or invalid signature - The bundle '...' at bundle path 'Payload/...' is not signed using an Apple submission certificate.The App don't use any capability.I've used Xcode to upload, as in a previous App which now is on the App Store.All the apps use the default configuration: "Automatically manage signing", Provisioning profile "Xcode Managed Profile", Signing Certificate Apple Development: ############The requested Signing Certificate is present in the keychain in 3 versions, the last one is valid (the older 2 are revoked).What I should correct?

Our app is weakly linked to a framework from a third-party vendor: /Library/KeyAccess/KeyAccess.app/Contents/SharedFrameworks/KeyAccess.framework/KeyAccess Our app is signed using our developer ID certificate with: --options runtime --timestamp --entitlements ourApp.entitlements Since the 3rd party framework is signed with a different developer ID, the entitlement file requests and disables library validation: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation?language=objc We have verified the code signature using the following commands: codesign --verify --strict --verbose ourApp.app codesign -dvv ourApp.app spctl -vvv --assess --type exec --ignore-cache --no-cache ourApp.app No issues are reported. We generate a dmg we code sign that too, then successfully notarize the dmg and staple the report. When viewing the log provided during notarization no issues are shown, all binary content has been properly signed. Unfortunately, if the dmg is downloaded from an online source we get a Gatekeeper warning indicating the developer cannot be verified. If we omit the entitlement (which will result in not being able to use the 3rd party framework, but the application will otherwise run) the Gatekeeper dialog disappears. Since this issue appeared only after we upgraded from Qt 5 to Qt 6, we created a small test app that just shows a "Hello World" message. In this case inclusion of the entitlement is not a problem until we attempt to pull in a trivially simple framework that we ship within the application bundle (QNtp.framework). We cannot find any code within this tiny library that e.g. uses a private API or anything else suspicious. If we bake the QNtp code into the test application directly instead no Gatekeeper warning is shown. Is there some way to get a report on WHY Gatekeeper is rejecting the code signature and notarization of the sample or our full app? Unfortunately tools like Max Inspect and Taccy have not yet revealed the cause of the issue. let myEmail = "w" + "stokes" + "@snapgene.com"

After updating from MacOS Mojave to MacOS Monterey, standard apps being freshly downloaded via webbrowser as .dmg file (not via App Store) don't start anymore, e. g. Firefox: https://www.mozilla.org/de/firefox/mac/ DBeaver: https://dbeaver.io/download/ Open Office: https://www.openoffice.de/openoffice_download_macosx.php ... The effect (always reproducable) is the following: A new dock icon pops up dock bar, keeps bouncing for about two minutes, then it stops bouncing, but neither the app starts nor an error message is shown. In parallel, a warning "CoreServicesUIAgent Connection from process XXXX does not have the required entitlement com.apple.private.iscsuia" is logged in the system log (this is always reproducable). What can be the reason that none of the apps are starting? What could I do to make them working again?

This post is part of a cluster of posts related to the trusted execution system. If you found your way here directly, I recommend that you start at the top. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Resolving App Sandbox Inheritance Problems 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 tripping over one of the following problems: Nonheritable entitlements Changing sandbox Nothing to inherit Nonheritable Entitlements The most common cause of this problem is also the most obscure. If you have a sandboxed app with an embedded program that you run as a child process, a crash in _libsecinit_appsandbox is most likely caused by the embedded program being signed with entitlements that can’t be inherited. Imagine an, SandboxInit, with an embedded helper tool, NotHeritable. When the app runs the helper tool as a child process, the helper tool crashes with a crash report like this: Exception Type: EXC_BAD_INSTRUCTION (SIGILL) … Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_secinit.dylib … _libsecinit_appsandbox.cold.7 + 49 1 libsystem_secinit.dylib … _libsecinit_appsandbox + 2096 2 libsystem_trace.dylib … _os_activity_initiate_impl + 51 3 libsystem_secinit.dylib … _libsecinit_initializer + 67 4 libSystem.B.dylib … libSystem_initializer + 286 5 dyld … invocation function for block in dyld4::Loade… 6 dyld … invocation function for block in dyld3::MachO… 7 dyld … invocation function for block in dyld3::MachO… 8 dyld … dyld3::MachOFile::forEachLoadCommand(Diagnost… 9 dyld … dyld3::MachOFile::forEachSection(void (dyld3:… 10 dyld … dyld3::MachOAnalyzer::forEachInitializer(Diag… 11 dyld … dyld4::Loader::findAndRunAllInitializers(dyld… 12 dyld … dyld4::APIs::runAllInitializersForMain() + 38 13 dyld … dyld4::prepare(dyld4::APIs&, dyld3::MachOAnal… 14 dyld … start + 388 The helper tool has trapped within _libsecinit_appsandbox. Look at the entitlements of the helper tool: % codesign -d --entitlements - SandboxInit.app/Contents/MacOS/NotHeritable … [Dict] [Key] com.apple.security.app-sandbox [Value] [Bool] true [Key] com.apple.security.inherit [Value] [Bool] true [Key] com.apple.security.get-task-allow [Value] [Bool] true The com.apple.security.app-sandbox and com.apple.security.inherit entitlements are fine: They configure the program to inherit its sandbox from its parent. The problem is the com.apple.security.get-task-allow entitlement, which is not compatible with this sandbox inheritance. The com.apple.security.get-task-allow entitlement is often automatically injected by Xcode. For information on how to prevent this, see Embedding a Command-Line Tool in a Sandboxed App. Some entitlements are compatible with sandbox inheritance. Unfortunately that list of entitlements is not documented (r. 93582428). The most commonly use ones are the hardened runtime exception entitlements documented in Hardened Runtime. The other entitlements on the list are pretty obscure. Changing Sandbox Another cause of a trap within _libsecinit_appsandbox is the child process trying to set up its own sandbox. If a sandboxed process runs another program as a child process, that child process always inherits its sandbox from the parent. If the program’s executable is signed with com.apple.security.app-sandbox but not com.apple.security.inherit — that is, it tries to set up a new sandbox — it will crash in _libsecinit_appsandbox. A process is not allowed to change its sandbox. To check for this problem, look for the following in the crash report: Application Specific Signatures: SYSCALL_SET_PROFILE This indicates that the process tried to setup its sandbox profile but that failed, in this case because it already has a sandbox profile. To fix this problem, either: In the child, add the com.apple.security.inherit entitlement so that it inherits its sandbox from the parent. In the parent, run the program so that it’s not a child process. For example, you could launch it using NSWorkspace. Nothing to Inherit Another cause of a trap within _libsecinit_appsandbox is when a nonsandboxed process runs another program as a child process and that other program’s executable has the com.apple.security.app-sandbox and com.apple.security.inherit entitlements. That is, the child process wants to inherit its sandbox from its parent but there’s nothing to inherit. To check for this problem, look for the following in the crash report: Application Specific Information: Process is not in an inherited sandbox. There are three ways you might fix this problem: Sandbox the parent. Unsandbox the child. Run the child in its own sandbox by removing the com.apple.security.inherit entitlement.

When opening a pkg file on Mojave and Catalina I'm seeing following Package Authoring Errors in Installer log (/var/log/install.log):Package Authoring Error: &lt;background&gt; has an unsupported MIME type: image/data Package Authoring Error: &lt;background_scaling&gt; has an unsupported MIME type: X-NSObject/NSNumber Package Authoring Error: &lt;background_alignment&gt; has an unsupported MIME type: X-NSObject/NSNumber Package Authoring Error: &lt;layout-direction&gt; has an unsupported MIME type: X-NSObject/NSNumberwhich is weird because background is defined in pkg Distribution XML as:&lt;background file="background.tiff" alignment="bottomleft" scaling="none" mime-type="image/tiff"/&gt;based on specification of Distribution file in https://developer.apple.com/library/archive/documentation/DeveloperTools/Reference/DistributionDefinitionRef/Chapters/Distribution_XML_Ref.htmlSimilar problems can be seen even on pkg installers that contain no background XML element. That also includes pkg files downloaded from Apple website.Is there any explanation where these errors are coming from?

I have a framework that I am trying to embed in an application.The framework uses cmake to build itself, and I can rebuild as needed to fix this problem.When I include the library in my application, with Code Sign On Copy checked, the step fails with a file not found. Tracing the output, it is trying to sign a library at Versions/A. The library should have a version of 1.10.0, and when doing otool it reports the version numbers as 1.10.0.So, where does xcode get that A for the version when trying to sign the library? What can be changed so it has the right version number?

Hi, I am testing the behavior of my app if I change it's app bundle content. I created an app with a script within it's Resources folder. I signed the app and verify that the code sign is accepted with the spctl command. Then I modify the script within the app bundle and spctl gives me a sealed resource is missing or invalid which was expected. However I thought that I wouldn't be able to launch the app bundle now that it is compromised but I was able to execute it. Do I need to make it go through GateKeeper by first downloading the app from a server? In that case if I download an non-modified app, launch it successfully then modify it, would subsequent launch fail or not? The app will be delivered through MDM and I think that GateKeeper does not verify MDM-delivered apps. Is it possible to make the app non-launchable if the files within its Resources folder have been modify/compromised? Edit: The app won't be installed to /Applications/ but to a specific folder Thank you in advance!

In one of the applications that I develop, since version 9.3 of Xcode, an embedded target binary that is launched from the main application using NSTask now fails to launch with the following error message:Sandbox: [AppName(App PID)] deny(1) forbidden-sandbox-reinitI couldn't find much information about it and it's not clear what change happened in Xcode 9.3 (also happens in 9.4 beta 1) that causes this to fail.

i have a mac app,like simpholders app,to find and manager simulator's sandbox and gouse NSTask exe command:/usr/bin/xcrunwill show errorxcrun: error: cannot be used within an App Sandbox.

Hi all, I'm attempting to distribute a notarized expiring demo variant of my Mac App Store app (TypeMetal) directly to potential customers as a download on our website, using the procedure documented here: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution I successfully complete the 9 steps listed in "Notarize Your App Automatically as Part of the Distribution Process", including choosing "Developer ID (Distribute directly to customers)" and "Upload (Send to Apple notary service)", and successfully download the resultant .app bundle, but I'm unable to run the app. It looks to me as if the system is attempting to obtain an App Store receipt for the app, when what I want is for this variant of the app to be treated as distinct from the purchased Mac App Store version, and be runnable without purchase. I have tried changing the app's bundle identifier and removing the LSApplicationCategoryType (in the Xcode target's settings, before building), but neither seems to affect these results. I'm left wondering how the system is determining that this is an .app that requires App Store sign-in/receipt-checking. When I copy the downloaded, notarized .app to a different macOS user account, log in as that user, and attempt to launch it there, the system presents a panel, prompting for the user to sign in with their Apple ID: When I attempt to launch the app in my own user account (the one I build and develop in), the system presents the same prompt in a slightly different form: Whether or not I provide a valid Apple ID sign-in in either case, the launched app then terminates with a fatal alert. (Same result in a separate user account as in my own development account.) I would like for the distributed app to be runnable by customers without requiring an App Store receipt. I have verified that my own App Store receipt-checking code is being omitted, as I intend, from the build I that submit for notarization. Is there something I need to do differently to make this work? The notarized app has passed the checks described here: Resolving Common Notarization Issues https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087721 I can provide the outputs of the codesign and spctl checks recommended on that page, if that would be helpful. The .app contains one embedded framework (OpenSSL.framework) and one command-line executable (tidy), but I believe they are correctly code-signed. I'm testing this on a 2020 M1 MacBook Air running macOS 12.3.1 (21E258), using Xcode 13.3.1 (13E500a) to do the build, upload for notarization, and export of the notarized result. Thanks very much in advance for any insight you can offer. Troy Stephens Coherence Labs, LLC

I'm trying to get a pkg file notarized.The notarization process worked fine for me until some day ago.Now, when I run the altool command, I get this error : *** Error: To use this application, you must first sign in to iTunes Connect and sign the relevant contracts. (1048)I have checked https://developer.apple.com/account/ and https://appstoreconnect.apple.com/agreements/ too see if you have any pending agreement, but there is nothing there.The command I use is 'xcrun altool --notarize-app --primary-bundle-id $MYBUNDLEID --username $MYUSERID --asc-provider $MYTEAMID --password $MYAPPPASSWORD --file $MYPKGFILE'The last time the altool command worked for me was on the 29 May.Any idea what is going wrong here?

I am yet another another developer facing the issue of having a notarized application cryptically blocked by GateKeeper with the unhelpful "unidentified developer" message. I followed Eskimo's instructions of combing the system logs, and caught an event by XprotectService: File /Applications/Cook-a-Dream.app/Contents/Resources/app_packages/PySide6/lupdate failed on rPathCmd /Users/qt/work/install/lib/QtCore.framework/Versions/A/QtCore Googling around, I found some people reporting similar problems (with other libraries) being fixed by detecting and fixing this kind of problem by deleting/changing some of the rpaths with install_name_tool. The questions: How do I confirm if the issue is indeed one of rpath? What are the general "rules" that govern what is allowed or not allowed in terms of rpaths for GateKeeper? Can I add a prophylactic step to my workflow to detect those issues before notarization?