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?

Hi, We have an app that installs a number of system extensions. According to this documentation the app must be located in the Applications folder to be activated so when the app launches we check that it is running from /Applications (or a subfolder) and if it isn't we inform the user and exit. This has been working fine until a recent submission whereupon installing the app via TestFlight casuses it to be translocated when run and our check to fail. So, a couple of questions: Is it expected that an app installed via TestFlight (or indeed the AppStore) can be translocated when it is run? If yes to the above, how can we ensure that out app is running from Applications and can therefore activate its extensions? Thanks Alan

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? :(

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?

I have created an "installer" style DMG for a VST3 audio plugin. It works fine on 13.4, but fails on 14.1. Note this is when I download the DMG from GitHub. On 14.1, when I drag the plugin icon to the link to /Library/Audio/Plug-Ins/VST3, the icon snaps back and the copy is not made. It DOES work if I use xattr to remove the quarantine. I can also mount the dmg, cd into the volume and use cp -R to copy the bundle through the link. Random other facts : The dmg is built on a GitHub runner (MacOS 12.6.9) using Xcode 14.2 The plug in and the dmg are signed. The dmg is notarized and stapled. Any help would be greatly appreciated! Thanks!

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 was reading through this post: https://developer.apple.com/forums/thread/718583 I've been able to reproduce this behavior by double-clicking a DMG in the Finder while the Mac is Offline. I checked the Notarization status of the app via spctl and it shows "Notarized Developer ID". So sure enough, Quinn's comment about Gatekeeper "ingesting" the notarization ticket stapled to the DMG and automatically applying it to the app inside is 100% spot-on. However, I can't seem to get the same behavior to happen when mounting the DMG via hdiutil in Terminal. While Offline, I do a: hdiutil attach /path/to/my/dmg.dmg and then spctl -a -t exec -vvv /Volumes/path/to/my/mounted/dmg/myapp.app After the spctl I'm seeing /Volumes/path/to/my/mounted/dmg/myapp.app: rejected source=Unnotarized Developer ID origin=Developer ID Application: My Developer Creds (XXXXXXXXXX) Is there a way to get Gatekeeper to "ingest" the notarization ticket stapled to the DMG when using hdiutil while Offline? Note 1: If I use hdiutil while online, everything works as expected. Note 2: I'm testing all this via a VM of macOS 12.7.1, if that makes any difference. Thanks!

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've recently updated my development laptop, and my continuous integration build nodes (a pair of Mac minis) to macOS Sonoma. Prior to this update, my CI workflows passed without issue. Since updating, every time I attempt to run my app's unit tests, an impassible alert is shown stating: “MyApp” differs from previously opened versions. Are you sure you want to open it? Opening “MyApp” will allow it to access data from previously used versions of “MyApp”. My tests go no further, and my CI workflows fail. I found that if I switched from using Ad-Hoc code signing for my tests, that this dialog is no longer shown on my local development laptop, however it is still shown on my CI nodes. Is there some way to tell Xcode to bypass this warning? If there's not, Sonoma doesn't seem to be usable for doing testing.

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 have my macOS app, which I'm distributing outside the MAC App Store through Notarizing the App. When my end-user unzipped my App (which they downloaded from a shared URL path) and opened it, It crashed after the first time opening (by clicking on the Gatekeeper check popup: "Chrome downloaded this file today at 11:10 AM. Apple checked it for malicious software and none was detected. ") In my macOS app (distributing outside the MAC App Store through Notarizing the app), though I removed AppSandbox capability, I am still not able to read/write to the Resource folder. Error ESPlus-2023-06-28-173050_ips.txt Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “SupportTextFiles” in the folder “Resources”." UserInfo={NSFilePath=/x.app/Contents/Resources/SupportTextFiles, NSUnderlyingError=0x6000030e3c00 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

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

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.