Is it true that signing should always over-write any existing code-signing?I ask because I've had a recent case where this was done in SD Notary. The signing (of a framework) succeeded and notarization succeeded, although the app then failed when it tried to load the framework. I checked the logFileURL and there was an issue saying the framework was not signed.I repeated the exercise, this time starting with an un-signed version of the framework, and all went well. (I have no idea how the previous version was signed -- it was from a user).

Hi. We have an app whose current version has a component that is not code signed, which in turn shows up in the login items as coming from an unidentified developer. We did the required changes and, when doing a fresh install, said component does not show up anymore (yay!). The problem is when doing an upgrade, from the version that has the unsigned component to the newer one, as Ventura still shows the same component with the same description even though checking the signature shows that it is code signed. Is there some extra step we need to do so that the OS updates the state and the component is not there anymore?

We noticed there had been a new "App Management" permission option under "Privacy & Security" settings introduced in the upcoming Ventura release. It accidentally blocked some of our scripts modifying parts of our product, which, at this point, proved to be problems on our end and can be resolved by us. However, we are in general wary that there doesn't seem to be any documentation on this new option and what behaviors would run into its way. Are there any guidelines Apple can provide? Also, IF it turned out at some point we couldn't work around this option, is there a corresponding MDM payload we can grant certain apps this permission through a profile (we are largely dealing with enterprise customers)?

I am trying to build a c++ application for Mac, I have followed all the steps for codesigning the application code, codesigning the DMG, notarising the DMG and also stapling the DMG after successful notarisation. But when I try to open the application on Mac gate keeper is blocking the application from opening and opening the popup with error message as " '<Application_Name>' cannot be opened because the developer cannot be verified." What could be the reason? Please help.

Hi,My software installs frameworks in the local domain (/Library/Frameworks) that are accessed from third-party apps. Some of these apps are simply code-signed, others are sandboxed. They are obviously signed by other companies, and so far there have been no problems on the part of DYLD in loading and executing code inside our frameworks. The loader is happy to continue looking for our framework outside the app container, in the case of sandboxed apps.What changes are necessary to ensure that our frameworks remain accessible from hardened apps? Hardened Runtime, to the best of my understanding, only allows executables to load code that has been code-signed by the same team, or by Apple. I also think that hardened runtime affects only executables, and yet when I enable the ENABLE_HARDENED_RUNTIME setting in Xcode on my framework targets (via xcconfig) it clearly influences the way they are signed, and suddenly these "hardened frameworks" fail to be loaded by third-party apps, even if these apps aren't yet hardened themselves. In what its perhaps the key to solving this issue, how can one mark non-app targets to enable the library-validation exception? Why would a non-hardened app fail to load code whose only difference may be a simple flag (kill,runtime) in its signature?Maybe I'm wrong to assume that non-app targets deserve any special treatment, but the fact remains that when I enable hardened runtime, our code simply stops being "seen" and loaded by DYLD, with all other variables remaining identical.Thank you!Gabe

Hi everyone, Since macOS 12.3+ removed built-in Python, I try to bundle the official Python installer package (.pkg) in our Mac Application (.app). Therefore the user can install Python directly in the application to make one of our app functions correctly. However, this application cannot be opened because macOS cannot verify that this app is free from malware. This issue happened on macOS 12.4, but it can be opened without any error messages on macOS 10.14.6. When bundling the package, I did re-sign it using our developer ID certificate, And the app also passes the notarization process. Then I checked the following utilities on macOS 12.4 and all of them are correct. Please help me to solve this issue. Thank you very much. Checking the Gatekeeper: spctl -a -t exec -vvv --ignore-cache Spark.app Spark.app: accepted source=Notarized Developer ID origin=Developer ID Application: *** Inc (SKLFZ4533Y) Checking the signature of application: codesign -vvv --check-notarization --deep Spark.app --prepared:/Users/oz-chc/Downloads/Spark.app/Contents/Helpers/python.pkg --validated:/Users/oz-chc/Downloads/Spark.app/Contents/Helpers/python.pkg Spark.app: valid on disk Spark.app: satisfies its Designated Requirement Checking the signature of Python package after re-sign and bundle it. (I marked the fingerprint) pkgutil --check-signature Spark.app/Contents/Helpers/python.pkg Package "python.pkg": Status: signed by a developer certificate issued by Apple for distribution Notarization: trusted by the Apple notary service Signed with a trusted timestamp on: 2022-08-25 03:07:00 +0000 Certificate Chain: 1. Developer ID Installer: *** Inc (SKLFZ4533Y) Expires: 2024-10-25 04:12:29 +0000 SHA256 Fingerprint: ****** ------------------------------------------------------------------------ 2. Developer ID Certification Authority Expires: 2027-02-01 22:12:15 +0000 SHA256 Fingerprint: ****** ------------------------------------------------------------------------ 3. Apple Root CA Expires: 2035-02-09 21:40:36 +0000 SHA256 Fingerprint: ******

I have created signed some binaries with Apple development certificates and then revoked the certificate from developer account. After revocation of certificate, gatekeeper is not blocking the execution of binaries. Even evaluating these revoked certificates in keychain is showing valid certification and successful evaluation . Same applies for Installer certificate. I tried checking revocation status of binary using method "SecPolicyCreateRevocation(kSecRevocationUseAnyAvailableMethod)" but we are getting trust result as 'kSecTrustResultUnspecified'. Please tell me how to check if certificate is revoked using any utility. Also let me know if I am missing anything in revocation check call.

Hello, We are trying to codesign our osx binary which we created. $ codesign --verbose=4 --timestamp --strict --options runtime -s "Developer ID Application: Rill Data, Inc (XXX)" macOS-x64/application/rill --force macOS-x64/application/rill: replacing existing signature macOS-x64/application/rill: signed Mach-O thin (x86_64) [rill] $ codesign --verify macOS-x64/application/rill --verbose=4 macOS-x64/application/rill: valid on disk macOS-x64/application/rill: satisfies its Designated Requirement We also tried creating the pkg, we were able to install it locally but when actually executing the binary it again complained "Apple cannot check it for malicious software" We also tried getting it notarized but that also fails. $ xcrun altool --notarization-info <hash> -u <> -p <> No errors getting notarization info. Date: 2022-08-19 05:26:14 +0000 Hash: <hash> RequestUUID: <hash> Status: in progress Status Code: 2 Status Message: Package Invalid

Odd one here. I'm having trouble getting a signed, notarised, stapled app to actually run. It is packaged as a zip file. When uncompressed and run from finder, I get "“iShowU Switcher” cannot be opened because the developer cannot be verified." and "macOS cannot verify that this app is free from malware." (this is publicly available, https://shinywhitebox.com/download-thanks/17/1 - app is called iShowU Switcher, currently in development) Here's what I've checked: signed codesign --verify --deep --verbose iShowU\ Switcher.app iShowU Switcher.app: valid on disk iShowU Switcher.app: satisfies its Designated Requirement notarized spctl -a -t exec -vvv iShowU\ Switcher.app iShowU Switcher.app: accepted source=Notarized Developer ID origin=Developer ID Application: Shiny White Box Limited (PMJ275ZTUX) stapled xcrun stapler validate iShowU\ Switcher.app Processing: /Users/neil/Downloads/iShowU Switcher.app The validate action worked! So it all looks sane to me. If I remove the quarantine bit (xatter -d -r) then the app runs fine. Ideas of where to next look?

PackageKit: Begin install 8 Dec 14 10:33:18 loca lhost installd [51841： Packagekit: PKInformsystemPolicyInstal1operation failed with error:An error occurred while registering installation with Gatekeeper

Hello, I have a notarized application distributed outside the Mac App Store which is working properly at the moment. Recently I added the ability to load third-party plug-ins in the application, and thus Library Validation needs to be disabled. However, after I disabled it, the app is no longer passing Gatekeeper checks, and can only be launched via "Right Click &amp;gt; Open". If I remove the com.apple.security.cs.disable-library-validation entitlement again, the app can pass the Gatekeeper, but that prevents the app from loading third-party plug-ins. I noticed that the documentation mentioned: Because library validation is such an important security-hardening feature, Gatekeeper runs extra security checks on programs that have it disabled. If your program is blocked by Gatekeeper, check whether you’ve unnecessarily disabled library validation. and was wondering whether it has something to do with this. Appreciate any suggestions. Thanks.

For some reason, I have to develop a command-line tool for my company and pushlish it in my company. So, After my development, I try to notatize it. And after notatization, it can not wok. My step is as follow: complie it as [tool]. run commands as follows : codesign -fs [fs] --timestamp --force --deep --options runtime --entitlements [plist_path] [tool] codesign -dvvv [tool] productbuild --identifier [bundleId] --sign [cert] --timestamp --install-location --root [tool_folder] / [tool_folder_pkg] xcrun altool --notarize-app --primary-bundle-id [bundleId] --username esc@tencent.com --password [password] --file [tool_folder_pak] xcrun altool --notarization-info [notatizaion_id] --username esc@tencent.com --password [password] xcrun stapler staple [tool_folder_pkg] try to unzip the pkg pkgutil --expand [tool_folder_pkg] [folder] cd [tool_folder_pkg] tar xvf Payload .[tool] get error: zsh: killed   [tool] how can I fix it? Thanks a lot

IMPORTANT This post is now obsolete, having been replaced by: Code Signing Resources Trusted Execution Resources App Sandbox Resources Notarisation Resources App Sandbox: App Sandbox Design Guide Gatekeeper and notarisation: Developer ID landing page Signing a Mac Product For Distribution Manual Code Signing Example Testing a Notarised Product --deep Considered Harmful Update to Notarization Prerequisites (23 Dec 2019) Notarize Your Mac Software for macOS Catalina (3 Oct 2019) Notarizing Your Mac Software for macOS Catalina (3 Sep 2019) New Notarization Requirements (10 Apr 2019) Notarizing Your App Before Distribution Customizing the Notarization Workflow WWDC 2019 Session 701 Advances in macOS Security WWDC 2019 Session 703 All About Notarization Safely open apps on your Mac (from Apple Support) Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + "@apple.com" Change history: 5 Jun 2015 — First posted. 25 Mar 2020 — Updated with a bunch of notarisation resources. Changed the title to About App Sandbox, Developer ID, Notarisation. 30 Mar 2020 — Add a link to Manual Code Signing Example. 18 May 2020 — Added a link to --deep Considered Harmful.

I am trying to notarize the unity build and I do get an email from apple saying that my app is notarized, but when I test it out on my own mac, it says that the app is from an unidentified developer and is malicious software. When I run the command line tool for checking if the app is notarized or not, it tells me that the notarization was rejected and developer id is unknown. Did anyone have this issue or know how to solve it?

We complete this process without any error or issue. But, when we try to open the file it still says " can't be opened because the identity of the developer cannot be confirmed". https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution#:~:text=notarization%20workflow.-,Notarize%20your%20preexisting%20software,-Notarizing%20your%20preexisting Here are the results of running xcrun notarytool log on our notary submission. I have scrubbed it to avoid exposing sensitive information. % xcrun notarytool log --apple-id --team-id Password for:  {  "logFormatVersion": 1,  "jobId": "",  "status": "Accepted",  "statusSummary": "Ready for distribution",  "statusCode": 0,  "archiveFilename": ".dmg",  "uploadDate": "2022-07-07T02:12:43.412Z",  "sha256": "582d852371780441637e1f9d8eb36fa3d6daf1bd8538771fc79522d481908c84",  "ticketContents": [   {    "path": ".dmg",    "digestAlgorithm": "SHA-256",    "cdhash": "55df35c3d99520e5d6167a23668a66905f209f03"   },   {    "path": ".dmg/",    "digestAlgorithm": "SHA-256",    "cdhash": "9a545fd55fb481714a990753ceda696aa637df9a",    "arch": "x86_64"   }  ],  "issues": null }

I develop Adobe AIR apps in Adobe Animate CC on Mac and Windows. For the first time this year, the last publishing process ends with an error msg. On both Mac and Windows, I get this message. Adobe Animate could not sign the AIR file. Unable to build a valid certificate chain for the signer. Please help!!!

We have an application written in C and C++ that runs on Windows, Linux, and Mac. Recently a customer trying to install it on macOS Monterey received a message saying "cannot be opened because it is from an unidentified developer". To deal with this my company has joined the Apple Developer Program. So my question is how do we make use of that membership to get past this problem? Of the three platforms mentioned above, Mac accounts for the fewest customers, so we're not Mac experts. The software is built using Xcode but with makefiles that directly invoke clang or clang++. The finished product is packaged into a .dmg file. Note that we're not intending to put this software into the App Store.

I'm writing a macOS app that bundles an executable. This executable (and some of its resources) happen to be quite large. Ideally, I could compress this executable and its resources (in a .zip or similar) and extract them at runtime to keep my app's file size down. This doesn't seem possible because: Copying files (using every method that I know of) while in a sandboxed app to any location will result in those files being given the "quarantined" attribute, which causes macOS to refuse to launch copied executables The only way to avoid #1 is to keep executables packaged in the app's bundle, where they won't be quarantined. Downside here is that I can't compress or decompress because the app bundle is read-only. Is there an approach I'm not aware of here that would let me have a compressed executable + resources bundled with my sandboxed app that I could successfully decompress and execute at runtime?

The question What is wrong with our signing process? Long story short At my project we are starting to use Azure to do continuous integration and use their macOS agent pool to do macOS builds. We do signing and notarization of the build artifacts, but even though multiple tools confirm that the app is signed and notarized we still get the following dialog on the downloaded artifacts and the app gets translocated. Long story long As mentioned we use Azure pipelines macOS agent pool to do macOS builds. We have created a developer signing certificate (not a distribution one) via a typical process of creating the certificate signing request and submitting it to Apple. Then we packaged the certificate along with a private key into a .p12 fule and uploaded it to Azure's Secure File system. We do not use a provisioning profile since we are targeting macOs. During the build we use the Azure's "Install Apple certificate" task to download the .p12 file and create a keychain with it's contents. That keychain is also set as a default during this process. The project architecutre is set to x86_64 Later during the build we layout the app as follows: fullDeploy/ OurApp.app/ data/ License Agreement.txt where OurApp.app is laid out by XCode - we just copy it. Then we sign things as follows codesign \ -s "Developer ID Application: XXXXXXXXXXXXXX" \ --deep \ --timestamp \ -o runtime \ --entitlements "yyyyyyy.entitlements" \ "OurApp.app" find "data/python" -name "*.so" |\ while read f; do codesign -s "Developer ID Application: XXXXXXXXXXXXXX" "$f" --timestamp; done; ditto -c -k --rsrc --keepParent "fullDeploy" "fullDeploy.zip" codesign -s "Developer ID Application: XXXXXXXXXXXXXX" "fullDeploy.zip" --timestamp xcrun altool \ --notarize-app \ --primary-bundle-id "zzzzzzzz" \ --username "email@domain.com" \ --password "password" \ --file "fullDeploy.zip" The zip fullDeploy.zip is then subsequently tarballed and uploaded to Azure artifact storage. After a while the notarization successfully completes. However when we download the tarball from Azure, untar and unzip we get the above warning. Some additional verification: > ls -@al fullDeploy.tar -rw-r--r--@ 1 xxxxxxxx staff 143296512 Jul 5 12:13 fullDeploy.tar com.apple.macl 72 com.apple.metadata:kMDItemWhereFroms 357 com.apple.quarantine 58 > tar -xzvf fullDeploy.tar ... > ls -@al fullDeploy.zip -rw-r--r--@ 1 xxxxxxxx staff 143260582 Jun 24 13:35 fullDeploy.zip com.apple.cs.CodeDirectory 139 com.apple.cs.CodeRequirements 176 com.apple.cs.CodeRequirements-1 175 com.apple.cs.CodeSignature 9055 com.apple.quarantine 58 > codesign -dvvvv fullDeploy.zip Executable=/Users/xxxxxxxx/Downloads/fullDeploy.zip Identifier=ZZZZZZZZZZZZZZZZ Format=generic CodeDirectory v=20200 size=175 flags=0x0(none) hashes=1+2 location=embedded Hash type=sha256 size=32 CandidateCDHash sha1=7c4b454d07d7d52bfb5dceb6df615804ee387fb4 CandidateCDHashFull sha1=7c4b454d07d7d52bfb5dceb6df615804ee387fb4 CandidateCDHash sha256=205d5a079e980d6b3d545b15328f31ca873150c7 CandidateCDHashFull sha256=205d5a079e980d6b3d545b15328f31ca873150c75a7ac574c2a37177da3f696a Hash choices=sha1,sha256 CMSDigest=1bfe7216f426e2403c628233e1bb32c20bd09b5a0456ef16c8a4d685e6ba45ed CMSDigestType=2 Page size=none CDHash=205d5a079e980d6b3d545b15328f31ca873150c7 Signature size=9056 Authority=Developer ID Application: XXXXXXXXXXXXXX Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=24 Jun 2022 at 13:35:45 Info.plist=not bound TeamIdentifier=YYYYYYYYYY Sealed Resources=none Internal requirements count=1 size=176 > codesign --deep-verify --deep -vvvv fullDeploy.zip fullDeploy.zip: valid on disk fullDeploy.zip: satisfies its Designated Requirement > unzip fullDeploy.zip ... > cd fullDeploy > codesign -dvvvv OurApp.app Executable=/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/OurApp Identifier=outcompany.OurApp Format=app bundle with Mach-O thin (x86_64) CodeDirectory v=20500 size=622277 flags=0x10000(runtime) hashes=19435+7 location=embedded VersionPlatform=1 VersionMin=659200 VersionSDK=787200 Hash type=sha256 size=32 CandidateCDHash sha256=9f364417c1498c12e89f2ca5e2b8de18594ba3a6 CandidateCDHashFull sha256=9f364417c1498c12e89f2ca5e2b8de18594ba3a64f6dd268b379bda90be741b5 Hash choices=sha256 CMSDigest=9f364417c1498c12e89f2ca5e2b8de18594ba3a64f6dd268b379bda90be741b5 CMSDigestType=2 Executable Segment base=0 Executable Segment limit=38354944 Executable Segment flags=0x1 Page size=4096 CDHash=9f364417c1498c12e89f2ca5e2b8de18594ba3a6 Signature size=8975 Authority=Developer ID Application: XXXXXXXXXXXXXX Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=24 Jun 2022 at 13:35:25 Info.plist entries=27 TeamIdentifier=YYYYYYYYYY Runtime Version=12.3.0 Sealed Resources version=2 rules=13 files=8 Internal requirements count=1 size=188 > codesign --deep-verify --deep -vvvv OurApp.app --prepared:/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/libtbbmalloc.2.dylib --validated:/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/libtbbmalloc.2.dylib --prepared:/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/libembree3.3.dylib --validated:/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/libembree3.3.dylib --prepared:/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/libtbb.12.dylib --validated:/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/libtbb.12.dylib --prepared:/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/libOpenImageDenoise.1.dylib --validated:/Users/xxxxxxxx/Downloads/fullDeploy/OurApp.app/Contents/MacOS/libOpenImageDenoise.1.dylib OurApp.app: valid on disk OurApp.app: satisfies its Designated Requirement > spctl --verbose=4 --assess --type execute OurApp.app OurApp.app: accepted source=Notarized Developer ID

Hi there, I built a Mac OS desktop utility app that will make an API request, retrieve json data and write the data to an Excel file. This app was scripted in python 3.10, compiled with pyinstaller 4.10, codesigned with entitlements, hardened runtime and notarised successfully in Mojave 10.14.6. Every step was successful and without any errors. This app was tested in Mojave, Catalina, Big Sur and Monterey. In all 4 OS's, the notarised app worked perfectly. The issue seems to stem from running the app in an OS that is not logged in with my primary Apple ID. When tested in seperate Mojave and Catalina and Big Sur (Intel) machines that were logged in with different Apple IDs, the app isn't able to execute the API request, retrieve json data, and write to file. I'm running out of leads here but think it could be something to do with the entitlements in the entitlements.plist or something that I am unaware of such as additional permissions that are neccessary. These are the entitlements that I added in the plist. <key>com.apple.security.cs.allow-jit</key> <true/> <key>com.apple.security.cs.allow-unsigned-executable-memory</key> <true/> <key>com.apple.security.cs.disable-library-validation</key> <true/> <key>com.apple.security.cs.disable-executable-page-protection</key> <true/> I have tried adding this : "com.apple.security.app-sandbox" but the app would end up bouncing in the dock so this was left out. I have also tried using this line alone : "com.apple.security.cs.allow-unsigned-executable-memory" and this would also cause the app to not work. As I have been working on this issue for quite a while now and at my wits end, any heads up would be very much and greatly appreciated. Thanks in advance, Justin