So I've enabled Hardened Runtime on my app but want to test it actually does what it is meant to do.So I put in a simple couple of calls to location services on a button: CLLocationManager* locMan = [CLLocationManager new]; [locMan startUpdatingLocation];and expected my app to crash on Mojave since I hadn't ticked the "Location" option in the "Resource Access" section of the Hardened Runtime capabilities.Instead it carried on as normal and I saw the Location StatusItem show up in the menu bar with my app listed as something that was using Location services.So now I'm wondering if Hardened Runtime is really turned on for my app or not. Or am I misunderstanding its usage?FYI - My app is distributed via Developer ID provisioning, not the App Store.

Last login: Sun Jan 3 08:12:33 on ttys000 harshdeepuppal@harshdeeps-MacBook-Pro ~ % sudo spctl --master disable Password: objc[2629]: Class SPExecutionPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class AppWrapper is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class AppWrapperPolicyResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class AppWrapperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class SPLog is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class MIS is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class SPExecutionHistoryItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class SPExecutionPolicyItem is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class SPDeveloperPolicy is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. objc[2629]: Class GKScanResult is implemented in both /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy and /usr/sbin/spctl. One of the two will be used. Which one is undefined. spctl: option `--master' is ambiguous System Policy Basic Usage:     spctl --assess [--type type] [-v] path ... assessment     spctl --add [--type type] [--path|--requirement|--anchor|--hash] spec ... add rule(s)     spctl [--enable|--disable|--remove] [--type type] [--path|--requirement|--anchor|--hash|--rule] spec change rule(s)     spctl --status | --master-enable | --master-disable system master switch Developer Mode Usage:   spctl developer-mode <action>     enable-terminal       Add Terminal as a developer tool. Kernel Extension User Consent Usage:   spctl kext-consent <action>      Modifications only available in Recovery OS     status       Print whether kernel extension user consent is enabled or disabled.     enable       Enable requiring user consent for kernel extensions.     disable       Disable requiring user consent for kernel extensions.     add <team-id>       Insert a new Team Identifier into the list allowed to load kernel extensions without user consent.     list       Print the list of Team Identifiers allowed to load without user consent.     remove <team-id>       Remove a Team Identifier from the list allowed to load kernel extensions without user consent. harshdeepuppal@harshdeeps-MacBook-Pro ~ % 

Hi, I have a PKG file which contains three packages: MyApp.pkg, MyOtherApp.pkg and MyLibs.pkg which contains all libraries and most of resources for these apps. Some libraries are common for both apps and some are specific for certain apps. After installation I have /Applications/MyApp.app, /Applications/MyOhterApp.app, /Libraries/MyAppLibs/Versions/1.2.3/. All these directories and PKG files are signed.  I want to make it possible to install or delete these apps separately. For example, if MyApp is already installed, then user may download and install only MyOtherApp.app and its specific libraries. When user deletes MyApp, deinstaller should delete MyApp.app and it's libraries not touching files used by MyOtherApp. I want to make MyApp to be able to install or delete some of its libraries. For example, when the user activates a feature, MyApp downloads libraries for this feature. Both goals assume that at least library directory will be modified. So the question is, will everything be alright with apps signing and notarization? I'm new to MacOS and I'm not sure if I fully understand it's security policy yet. I've done some experiments with manually deleting and changing files in both library and app directories. codesign and spctl utils show that directories are modified and signs are invalid, but the app launches and works without any problems even after I modified it's executable in MyApp.app. So it seems like  I can just don't care about signatures, but I think it is not a good solution, and I'm also not sure if it works for all users with different security settings. Maybe I should pack each library separately and install them in separate directories in /Libraries/MyAppLibs/Versions/ ? I've not tried it yet. It sounds ok, but it changes file structure of MyLibs and I expect some difficulties in adapting MyApp to it. So is there a way to do it right?

I have a notarized application that's embedding a lots of frameworks. When installed on Big Sur, it can be run normally as a local non admin user. When executed as Active Directory user however I'm getting the following error message: "The application with bundle ID x.y.z is running setugid(), which is not allowed. Exiting." I removed all calls to setegid and that sort, traced calls with dtruss and I'm pretty sure no privilege elevation is being done. Any help would be much appreciated.

Hi, I'm very new to XCode and I really need some help. I've created an .app in Max8 programming language and I successfully signed and notarized it. Now I am looking for a way to create an installer for my app, which will be distributed on my website (not Apple Store). I need to understand the following, possibly with a step by step tutorial from experienced user: my app must be installed in the Applications folder within a folder that will contain also the user manual I need the installer to create an hidden folder in the Applications Support (or somewhere else) which have privileges of read and write by my app. this is just to store and check a txt file with a serial key. I'm honestly lost in XCode and don't know where to start to create the installer (which from my understanding will need also to be signed and notarized too) I have my Developer ID and Installer ID certificates in my Keychain of course. Any help is greatly appreciated. Thank you!

Hello, I've searched for other posts on this topic but I haven't found anything that provides an answer.Here's my test program snippet, using the Xcode Mac Application Obj-C starter project:- (void)applicationDidFinishLaunching:(NSNotification *)aNotification { // Insert code here to initialize your application char const * dyld_library_path_original = getenv("DYLD_LIBRARY_PATH"); char dyld_library_path_new[1024]; strcpy(dyld_library_path_new, "/Applications/MATLAB_R2020a.app/bin/maci64:"); strcat(dyld_library_path_new, dyld_library_path_original); int rc = setenv("DYLD_LIBRARY_PATH", dyld_library_path_new, 1); NSLog(@"DYLD_LIBRARY_PATH=%s, rc=%d", getenv("DYLD_LIBRARY_PATH"), rc); void * handle1 = dlopen("libeng.dylib", RTLD_NOW); NSLog(@"Test 1: dlopen(libeng.dylib) = %p, err=%s", handle1, dlerror()); void * handle2 = dlopen("/Applications/MATLAB_R2020a.app/bin/maci64/libeng.dylib", RTLD_NOW); NSLog(@"Test 2: dlopen(libeng.dylib) = %p, err=%s", handle2, dlerror()); }As you can see, I'm trying to dlopen a dylib in the installed MATLAB application. But I don't think the specific dylib matters. What matters is that I'm dlopening it using just the leaf name of the path, after setting DYLD_LIBRARY_PATH at runtime to include MATLAB's dir (Test 1). This fails.But when I dlopen it with the full path (Test 2) it works. Here's the output:DYLD_LIBRARY_PATH=/Applications/MATLAB_R2020a.app/bin/maci64:/Users/hecht/Library/Developer/Xcode/DerivedData/TestML-droybqyctybedebamivvyiixjhnn/Build/Products/Debug:/usr/lib/system/introspection, rc=0 Test 1: dlopen(libeng.dylib) = 0x0, err=dlopen(libeng.dylib, 2): image not found Test 2: dlopen(libeng.dylib) = 0x6000039041a0, err=(null)I have Hardened Runtime enabled, with these entitlements turned on:Allow DYLD Environment VariablesDisable Library ValidationThe second one is doing its job, because without it, Test 2 fails also.But the first one doesn't help in allowing me to modify DYLD_LIBRARY_PATH at runtime. If I set the environment variable before launching (Xcode &gt; Product &gt; Scheme &gt; Edit Scheme &gt; Arguments &gt; Environment Variables) then Test 1 works. Is there a way to get dyld to honor changes to this environment variable made at runtime?

Hello, I have a electron app. I want to notarize this app. But there is a problem about python module.In my case, some user will use it offline, so I need prepare common python modules for them.When I try to notarize app, Apple will return failed, and logs tell to me that python module (.so files) does not cotains a valid signature or a secure timestamp signature. What can I do to make app notarized with python module?Can I let apple ignore these python module in app or Is there a way to signature these python modules ?

Please I need help with this expired certificate

Hi,I have an automated build process that produces custom apps for different customers. The only thing that is customized is a resource in the app.I would like to be able to just code sign the entire app once and then for each customer just update and code sign the resource.After doing the initial code signing of the app "codesign -vvv --deep --strict myapp.app" shows that everything is OK.I then replace myapp.app//Contents/Resources/CustomFile with a new one and code sign it:codesign -f -s "Developer ID Application: MY Company" --options runtime --keychain "Buildsystem" "myapp.app/Contents/Resources/CustomFile"But then "codesign -vvv --deep --strict myapp.app" shows there is a problem:myapp.app: a sealed resource is missing or invalidfile modified: myapp.app/Contents/Resources/CustomFileCan anybody explain why this doesn't work?My work around is to always update the resource in an unsigned app and then code sign the entire thing.

Hi, I'm responsible for generating the macOS installer for Apache NetBeans. Up until today I've not had any issues, the DMG created has never had any issues being used on others machines. The process we have signs and notarizes the app, as expected. However when downloading this from the internet at attempting to install the app, users are reporting that it cannot be opened because it cannot be checked by Apple for malicious software. Heres a link to the app: https://dist.apache.org/repos/dist/dev/netbeans/netbeans-installers/13/Apache-NetBeans-13-bin-macosx.dmg If I try to open this myself(after downloading), I can see 2 messages in Console: 1: assessment denied for Apache-NetBeans-13-bin-macosx.dmg com.apple.message.domain: com.apple.security.assessment.outcome2 com.apple.message.signature2: bundle:UNBUNDLED com.apple.message.signature: denied:no usable signature com.apple.message.signature3: Apache-NetBeans-13-bin-macosx.dmg com.apple.message.signature5: UNKNOWN com.apple.message.signature4: 3 SenderMachUUID: 8702454A-423C-33A4-BDAA-656186E59614 2: assessment denied for Apache NetBeans 13.pkg com.apple.message.domain: com.apple.security.assessment.outcome2 com.apple.message.signature2: bundle:UNBUNDLED com.apple.message.signature3: Apache NetBeans 13.pkg com.apple.message.signature5: UNKNOWN com.apple.message.signature4: 2 com.apple.message.signature: denied:Unnotarized Developer ID SenderMachUUID: 8702454A-423C-33A4-BDAA-656186E59614 I'm struggling to work out how to further diagnose this, to allow us to release this application? The notarization of this app comes back as "Package Approved", so I don't get that reference in those messages. Any help or advice on how to continue with this?

IMPORTANT This post has been replaced by two shiny new posts: Creating Distribution-Signed Code for Mac Packaging Mac Software for Distribution See the preamble in Creating Distribution-Signed Code for Mac for more context. I’ve left the original post here just for the record. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = "eskimo" + "1" + "@" + "apple.com" I spend a lot of time helping Mac developers with notarisation and Gatekeeper problems, and many of these problems are caused by incorrect code signing. The instructions for how to sign and package a Mac product for distribution are rather scattered, so I’ve written them all down in one place. And rather than keep that to myself, I’m posting it here for everyone’s benefit. If you have any corrections, feel free to get in touch with me directly (my email address is in my signature). And if have any questions about this, it’s probably best to ask them here on DevForums. I’ve locked this thread, so just start a new thread tagging it with Code Signing, Notarization, or Gatekeeper. Or, if you want one-on-one help, open a DTS tech support incident and we can pick things up in that context. IMPORTANT None of the following has been formally reviewed, so it’s not official Apple documentation. Signing a Mac Product For Distribution The best way to sign and package an app is via Xcode: Build a version of your app to distribute using Xcode’s Product > Archive command, and then package that archive for your distribution channel via the Organizer. See Xcode Help > Distribute your app for the details. However, not all Mac products can be distributed this way. For example: An app that’s distributed outside of the Mac App Store on a disk image A product that has to be installed via an installer package An app that uses a third-party development environment In these cases you must manually sign and package your product. Note If you find this post a little abstract, and would prefer to follow a concrete example, see Manual Code Signing Example. Consult Resources for Third-Party Development Environments Many third-party development environments have their own strategies for signing and packaging the products they build. If you’re using a third-party development environment, consult its support resources for advice before continuing. Decide on a Container Format To get started, decide on your container format. Mac products support two distribution channels: An app can be distributed via the Mac App Store Apps and non-apps can be distributed outside of the Mac App Store using Developer ID signing A Mac App Store app must be submitted as an installer package. In contrast, products distributed outside of the Mac App Store can use a variety of different container formats, the most common being: Zip archive (.zip) Disk image (.dmg) Installer package (.pkg) It’s also possible to nest these. For example, you might have an app inside an installer package on a disk image. Each container format has its own pros and cons, so pick an approach based on the requirements of your product. However, this choice affects how you package your product, something discussed in more detail below. Structure Your Code Correctly All code that you distribute must be signed. There’s two parts to this: Structuring your code to support signing Actually signing it You must structure your code correctly. If you don’t, it may be hard (or in some cases impossible) to sign it. First things first, identify all the code in your product. There are many types of code, including apps, app extensions, frameworks, other bundled code (like XPC Services), shared libraries, and command-line tools. Each type of code has two key attributes Is it bundled code? (apps, app extensions, frameworks, other bundled code) Is it a main executable? (apps, app extensions, command-line tools) Both of these attributes affect how you sign the code. In addition, whether the code is bundled is critical to how you structure it. Specifically, bundled code supports the notion of nested code. For example, you might have an app extension nested within your app’s bundle. When dealing with nested code, follow these rules: Place any nested code in the appropriate nested code location. For more on that, see Placing Content in a Bundle. Do not place non-code items in a nested code location. Rather, place these in the bundle’s resources directory (typically Contents/Resources). IMPORTANT Scripts are not considered code. If you have scripts — shell, Python, AppleScript, or whatever — place them in the resources directory. These will still be signed, but as a resource rather than as code. Provisioning Profile If you have a main executable that uses a restricted entitlement, one that must be allowlisted by a provisioning profile, place the profile in your bundle at the path Contents/embedded.provisionprofile. The profile is sealed by the code signature, so do this before signing the code. If your product contains multiple executables that need a profile — for example, you have an app with an embedded Network Extension app extension, both of which need the Network Extensions entitlement — repeat this process for each of these code executables. If your product includes a non-bundled executable that uses a restricted entitlement, you must package that executable in an app-like structure. For the details, see Signing a Daemon with a Restricted Entitlement. Handling Alien Code Structures If you’re using a complex third-party library, you may find that the structure required by the library does not match up with the structure required by macOS. For an in-depth discussion of the techniques you can use to resolve this, see Embedding Nonstandard Code Structures in a Bundle. Sign Your Code Sign code using the codesign tool. Read the following sections to learn about the specific arguments to use, but also keep these general rules in mind: Do not use the --deep argument. This feature is helpful in some specific circumstances but it will cause problems when signing a complex program. For a detailed explanation as to why, see --deep Considered Harmful. Rather, sign each code item separately. For a complex app, you should create a script to do this. Sign from the inside out. That is, if A depends on B, sign B before you sign A. When you sign A, the code signature encodes information about B, and changing B after the fact can break the seal on that code signature. Basic Signing No matter what sort of code you’re signing, the basic codesign command looks like this: % codesign -s III /path/to/your/code` where III is the name of the code signing identity to use. The specific identity varies depending on your target platform. See the following sections for details. When signing bundled code (as defined in Structure Your Code Correctly) pass in the path to the bundle, not the path to the code. If you’re re-signing code — that is, the code you’re signing is already signed — pass the -f option. If you’re signing a main executable (as defined in Structure Your Code Correctly) that needs entitlements, add --entitlements EEE.entitlements, where EEE.entitlements is a path to a property list file that contains your entitlements. IMPORTANT The entitlements property list file must be in the standard XML format with LF line endings, no comments, and no BOM. If you’re not sure of the file’s provenance, use plutil to convert it to the standard format. See Ensure Properly Formatted Entitlements in Resolving Common Notarization Issues. If you’re signing non-bundled code, set the code signing identifier by adding -i BBB, where BBB is the bundle ID the code would have if it had a bundle ID. For example, if you have an app whose bundle ID is com.example.flying-animals that has a nested command-line tool called pig-jato, the bundle ID for that tool would logically be com.example.flying-animals.pig-jato, and that’s a perfectly fine value to use for BBB. Note For bundled code, you don’t need to supply a code signing identifier because codesign defaults to using the bundle ID. Mac App Store Signing If you’re distributing via the Mac App Store, use your Mac App Distribution signing identity in place of III in the example above. This will typically be named 3rd Party Mac Developer Application: TTT, where TTT identifies your team. You can also use an Apple Distribution signing identity, with the name Apple Distribution: TTT. Developer ID Signing If you’re distributing outside of the Mac App Store, use your Developer ID Application signing identity in place of III in the example above. This will typically be named Developer ID Application: TTT, where TTT identifies your team. All Developer ID signed code needs a secure timestamp; enable this by adding the --timestamp option. If you’re signing a main executable (as defined in Structure Your Code Correctly), enable the hardened runtime by adding -o runtime option. The hardened runtime enables additional security checks within your process. You may need to make minor code changes to be compatible with those additional security checks. For some specific examples, watch WWDC 2019 Session 703 All About Notarization. Failing that, you can opt out of these additional security checks using entitlements. See Hardened Runtime Entitlements Build Your Container Once you’ve signed the code in your product, it’s time to wrap it in a container for distribution. Follow the advice appropriate for your chosen container format in the following sections. If you’re using a nested container format — for example, an app inside an installer package on a disk image — work from the inside out, following the advice for each level of nesting. Build a Zip Archive Use the ditto tool to create a zip archive for your product: Create a directory that holds everything you want to distribute. Run the ditto as shown below, where DDD is the path to the directory from step 1 and ZZZ is the path where ditto creates the zip archive. % ditto -c -k --keepParent DDD ZZZ Zip archives cannot be signed (although their contents can be). Build an Installer Package Use the productbuild tool to create a simple installer package for a single app: % productbuild --sign III --component AAA /Applications PPP In this example: III is either your Mac Installer Distribution or Developer ID Installer signing identity, depending on your distribution channel. This will typically be named 3rd Party Mac Developer Installer: TTT or Developer ID Installer: TTT, where TTT identifies your team. AAA is the path to your app. PPP is the path where productbuild creates the installer package. IMPORTANT The above is the simplest possible example. There are many different ways to create installer packages. See the man pages for productbuild, productsign, pkgbuild, and pkgutil for more details. Build a Disk Image Use the hdiutil tool to create a disk image for distribution: Create a directory to act as the source for the root directory of your disk image’s volume. Populate that directory with the items you want to distribute. Use hdiutil command shown below to create the disk image, where SSS is the directory from step 1 and DDD is the path where hdiutil creates the disk image. Use codesign command shown below to sign the disk image, where III is your Developer ID Application signing identity (typically named Developer ID Application: TTT, where TTT identifies your team), BBB is a pseudo bundle ID as discussed in Basic Signing, and DDD is the path to the disk image from step 3. % hdiutil create -srcFolder SSS -o DDD % codesign -s III --timestamp -i BBB DDD IMPORTANT There are various third-party tools that can help you create a disk image in exactly the right way. For example, the tool might arrange the icons nicely, set a background image, and add a symlink to /Applications. If you use such a tool, or create your own tool for this, make sure that the resulting disk image: Is signed with your Developer ID Application signing identity Is a UDIF-format read-only zip-compressed disk image (type UDZO) Notarisation If you’re distributing outside of the Mac App Store, you must notarise the file you intend to distribute to your users. For instructions on doing this, see Customizing the Notarization Workflow. Skip the Export a Package for Notarization section because you already have the file that you want to submit. If you’re using a nested container format, only notarise the outermost container. For example, if you have an app inside an installer package on a disk image, sign the app, sign the installer package, and sign the disk image, but only notarise the disk image. The exception to this rule is if you have a custom third-party installer. In that case, see the discussion in Customizing the Notarization Workflow. Stapler Once you have notarised your product, you should staple the resulting ticket to the file you intend to distribute. Customizing the Notarization Workflow discusses how to do this for a zip archive. The other common container formats (installer package and disk image) support stapling directly. For example: % xcrun stapler staple FlyingAnimals.dmg Note Stapling is recommended but not mandatory. If you don’t staple, a user may have problems if they try to install or run your app for the first time when the Mac is offline. Change history: 20 Jan 2020 — First version. 27 Jan 2020 — Minor editorial changes. 9 Mar 2020 — Moved the details of --deep into a separate post, --deep Considered Harmful. 10 Mar 2020 — Fixed a typo. 30 Mar 2020 — Added a link to Manual Code Signing Example. 26 Feb 2021 — Fixed the formatting. Add a discussion of the entitlements file format. Minor editorial changes. 1 Mar 2021 — Added the Provisioning Profile section. 21 Oct 2021 — Updated the Structure Your Code Correctly section to reference Placing Content in a Bundle. 22 Dec 2021 — Replaced links to two DevForums posts with links to the official documentation, namely those for Signing a Daemon with a Restricted Entitlement and Embedding Nonstandard Code Structures in a Bundle. Made some other editorial changes.

This post is one of a pair of posts, the other one being Creating Distribution-Signed Code for Mac, that replaces my earlier Signing a Mac Product For Distribution post. For more background on this, see the notes at the top of Creating Distribution-Signed Code for Mac. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Packaging Mac Software for Distribution Build a zip archive, disk image, or installer package for distributing your Mac software. Overview Xcode is a great tool for creating and distributing Mac apps. Once you’ve written your code you can upload it to the App Store with just a few clicks. However, Xcode cannot do everything. For example: Some Mac software products are not apps. You might, for example, be creating a product that includes a daemon. Some Mac products include multiple components. Your daemon might include an app to configure it. Some Mac products ship outside of the App Store, and so need to be packaged for distribution. For example, you might choose to distribute your daemon and its configuration app in an installer package. Some Mac products are built with third-party developer tools. If your product cannot be built and distributed using Xcode alone, follow these instructions to package it for distribution. Note If you use a third-party developer tool to build your app, consult its documentation for advice specific to that tool. To start this process you need distribution-signed code. For detailed advice on how to create distribution-signed code, see Creating Distribution-Signed Code for Mac. If you ship your product frequently, create a script to automate the distribution process. Decide on a Container Format To get started, decide on your container format. Mac products support two distribution channels: The Mac App Store, for apps Independent distribution, for apps and non-apps, using Developer ID signing A Mac App Store app must be submitted as an installer package. In contrast, products distributed outside of the Mac App Store use a variety of different container formats, the most common being: Zip archive (.zip) Disk image (.dmg) Installer package (.pkg) You may choose to nest these containers. For example, you might ship an app inside an installer package on a disk image. Nesting containers is straightforward: Just work from the inside out, following the instructions for each container at each step. IMPORTANT Sign your code and each nested container (if the container supports signing). For example, if you ship an app inside an installer package on a disk image, sign the app, then create the installer package, then sign that package, then create the disk image, then sign the disk image. Each container format has its own pros and cons, so choose an approach based on the requirements of your product. Build a Zip Archive If you choose to distribute your product in a zip archive, use the ditto tool to create that archive: Create a directory that holds everything you want to distribute. Run the ditto tool as shown below, where DDD is the path to the directory from step 1 and ZZZ is the path where ditto creates the zip archive. % ditto -c -k --keepParent DDD ZZZ Zip archives cannot be signed, although their contents can be. Build an Installer Package If you choose to distribute your product in an installer package, start by determining your installer signing identity. Choose the right identity for your distribution channel: If you’re distributing an app on the Mac App Store, use a Mac Installer Distribution signing identity. This is named 3rd Party Mac Developer Installer: TTT, where TTT identifies your team. If you’re distributing a product independently, use a Developer ID Installer signing identity. This is named Developer ID Installer: TTT, where TTT identifies your team. For information on how to set up these installer signing identities, see Developer Account Help. Run the following command to confirm that your installer signing identity is present and correct: % security find-identity -v 1) 6210ECCC616B6A72F238DE6FDDFDA1A06DEFF9FB "3rd Party Mac Developer Installer: …" 2) C32E0E68CE92936D5532E21BAAD8CFF4A6D9BAA1 "Developer ID Installer: …" 2 valid identities found The -v argument filters for valid identities only. If the installer signing identity you need is not listed, see Developer Account Help. IMPORTANT Do not use the -p codesigning option to filter for code signing identities. Installer signing identities are different from code signing identities and the -p codesigning option filters them out. If your product consists of a single app, use the productbuild tool to create a simple installer package for it: % productbuild --sign III --component AAA /Applications PPP In this command: III is your installer signing identity. AAA is the path to your app. PPP is the path where productbuild creates the installer package. The above is the simplest possible use of productbuild. If you’re submitting an app to the Mac App Store, that’s all you need. If you have a more complex product, you’ll need a more complex installer package. For more details on how to work with installer packages, see the man pages for productbuild, productsign, pkgbuild, and pkgutil. For instructions on how to read a man page, see Reading UNIX Manual Pages. Build a Disk Image If you choose to distribute your product in a disk image: Create a directory to act as the source for the root directory of your disk image’s volume. Populate that directory with the items you want to distribute. If you’re automating this, use ditto rather than cp because ditto preserves symlinks. Use hdiutil command shown below to create the disk image, where SSS is the directory from step 1 and DDD is the path where hdiutil creates the disk image. Decide on a code signing identifier for this disk image. If you were signing bundled code, you’d use the bundle ID as the code signing identifier. However, disk images have no bundle ID and thus you must choose a code signing identifier for your image. For advice on how to do this, see the Sign Each Code section in Creating Distribution-Signed Code for Mac. Use the codesign command shown below to sign the disk image, where III is your Developer ID Application code signing identity (named Developer ID Application: TTT, where TTT identifies your team), BBB is the code signing identifier you chose in the previous step, and DDD is the path to the disk image from step 3. % hdiutil create -srcFolder SSS -o DDD % codesign -s III --timestamp -i BBB DDD For more information on code signing identities, see the Confirm Your Code Signing section in Creating Distribution-Signed Code for Mac. IMPORTANT Sign your disk image with a code signing identity, not an installer signing identity. There are various third-party tools that configure a disk image for distribution. For example, the tool might arrange the icons nicely, set a background image, and add a symlink to the Applications folder. If you use such a tool, or create your own tool for this, make sure that the resulting disk image: Is signed with your Developer ID Application code signing identity Is a UDIF-format read-only zip-compressed disk image (type UDZO) Submit Your App to the Mac App Store If you’re creating an app for the Mac App Store, submit your signed installer package using either the altool command-line tool or the Transporter app. For detailed instructions, see App Store Connect Help &gt; Reference &gt; Upload tools. Notarize Your Product If you’re distributing outside of the Mac App Store, notarize the file you intend to distribute to your users. For detailed instructions, see Customizing the Notarization Workflow. Skip the Export a Package for Notarization section because you already have the file that you want to submit. If you’re using nested containers, only notarize the outermost container. For example, if you have an app inside an installer package on a disk image, sign the app, sign the installer package, and sign the disk image, but only notarize the disk image. The exception to this rule is if you have a custom third-party installer. In that case, see the discussion in Customizing the Notarization Workflow. Staple Your Product Once you’ve notarized your product, staple the resulting ticket to the file you intend to distribute. Staple the Ticket to Your Distribution discusses how to do this for an app within a zip archive. The other common container formats, installer packages and disk images, support stapling directly. For example, to staple a tick to a disk image: % xcrun stapler staple FlyingAnimals.dmg Stapling is recommended but not mandatory. However, if you don’t staple a user might find that your product is blocked by Gatekeeper if they try to install or use it while the Mac is offline.

This post is one of a pair of posts, the other one being Packaging Mac Software for Distribution, that replaces my earlier Signing a Mac Product For Distribution post. Over the past year I’ve been trying to convert my most useful code signing posts here on DevForums to official documentation, namely: Placing Content in a Bundle Updating Mac Software Signing a Daemon with a Restricted Entitlement Embedding a Command-Line Tool in a Sandboxed App Embedding Nonstandard Code Structures in a Bundle Unfortunately in the past month or so my Day Job™, answering developer questions for DTS, has become super busy, and so I’ve not had chance to complete this work by publish a replacement for Signing a Mac Product For Distribution. This post, and Packaging Mac Software for Distribution, represent the current state of that effort. I think these are sufficiently better than Packaging Mac Software for Distribution to warrant posting them here on DevForums while I wait for the quiet time needed to finish the official work. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Creating Distribution-Signed Code for Mac Sign Mac code for distribution using either Xcode or command-line tools. Overview Before shipping a software product for the Mac, you must first create distribution-signed code, that is, code that you can package up and then submit to either the Mac App Store or the notary service. The way you do this depends on the nature of your product and how it was built: If your product is a standalone app, possibly with nested code such as an app extension, that you build using Xcode, use Xcode to export a distribution-signed app. If your product isn't a standalone app, but you build it using Xcode, create an Xcode archive, and then manually export distribution-signed code from that archive. If you build your product using an external build system, such as make, add a manual signing step to your build system. Once you have distribution-signed code, package it for distribution. For more information, see Packaging Mac Software for Distribution. Note If you use a third-party developer tool to build your app, consult its documentation for advice specific to that tool. Export an App from Xcode If your product is a standalone app that you build with Xcode, follow these steps to export a distribution-signed app: Build an Xcode archive from your project. Export a distribution-signed app from that Xcode archive. You can complete each step from the Xcode app or automate the steps using xcodebuild. To build an Xcode archive using the Xcode app, select your app’s scheme and choose Product &gt; Archive. This creates the Xcode archive and selects it in the organizer. To create a distribution-sign app from that archive, select the archive in the organizer, click Distribute App, and follow the workflow from there. Note If the button says Distribute Content rather than Distribute App, your archive has multiple items in its Products directory. Make sure that every target whose output is embedded in your app has the Skip Install (SKIP_INSTALL) build setting set; this prevents the output from also being copied into the Xcode archive’s Products directory. For more information about the Xcode archives and the organizer, see Distributing Your App for Beta Testing and Releases. To build an Xcode archive from the command line, run xcodebuild with the archive action. Once you have an Xcode archive, export a distribution-signed app by running xcodebuild with the -exportArchive option. For more information about xcodebuild, see its man page. For instructions on how to read a man page, see Reading UNIX Manual Pages. For information about the keys supported by the export options property list, run xcodebuild with the -help argument. Export a Non-App Product Built with Xcode If you build your product with Xcode but it’s not a standalone app, you can build an Xcode archive using the techniques described in the previous section but you cannot export distribution-signed code from that archive. The Xcode organizer and the -exportArchive option only work for standalone apps. To export a distribution-signed product from the Xcode archive: Copy the relevant components from the archive. Sign those components manually. The exact commands for doing this vary depending on how your product is structured, so let’s consider a specific example. Imagine your product is a daemon but it also has an associated configuration app. Moreover, the configuration app has a share extension, and an embedded framework to share code between the app and the extension. When you build an Xcode archive from this project it has this structure: DaemonWithApp.xcarchive/ Info.plist Products/ usr/ local/ bin/ Daemon Applications/ ConfigApp.app/ Contents/ embedded.provisionprofile Frameworks/ Core.framework/ … PlugIns/ Share.appex/ Contents/ embedded.provisionprofile … … … The Products directory contains two items: the daemon itself (Daemon) and the configuration app (ConfigApp.app). To sign this product, first copy these items out of the archive: % mkdir "to-be-signed" % ditto "DaemonWithApp.xcarchive/Products/usr/local/bin/Daemon" "to-be-signed/Daemon" % ditto "DaemonWithApp.xcarchive/Products/Applications/ConfigApp.app" "to-be-signed/ConfigApp.app" IMPORTANT When you copy code, use ditto rather than cp. ditto preserves symlinks, which are critical to the structure of Mac frameworks. For more information on this structure, see Placing Content in a Bundle. Symlinks are also useful when dealing with nonstandard code structures. For more details, see Embedding Nonstandard Code Structures in a Bundle. The code you copy from the Xcode archive is typically development-signed: % codesign -d -vv to-be-signed/Daemon … Authority=Apple Development: … … To ship this code, you need to re-sign it for distribution. Confirm Your Code Signing Identity To sign code for distribution you need a code signing identity. Choose the right identity for your distribution channel: If you’re distributing an app on the Mac App Store, use a Mac App Distribution code signing identity. This is named 3rd Party Mac Developer Application: TTT, where TTT identifies your team. If you’re distributing a product independently, use a Developer ID Application code signing identity. This is named Developer ID Application: TTT, where TTT identifies your team. For information on how to set up these code signing identities, see Developer Account Help. To confirm that your code-signing identity is present and correct, run the following command: % security find-identity -p codesigning -v 1) A06E7F3F8237330EE15CB91BE1A511C00B853358 "Apple Distribution: …" 2) ADC03B244F4C1018384DCAFFC920F26136F6B59B "Developer ID Application: …" 2 valid identities found The -p codesigning argument filters for code-signing identities. The -v argument filters for valid identities only. If the code-signing identity that you need isn't listed, see Developer Account Help. Each output line includes a SHA-1 hash that uniquely identifies the identity. If you have multiple identities with the same name, sign your code using this hash rather than the identity name. Identify the Code to Sign To sign your product, first identify each code item that you need to sign. For example, in the DaemonWithApp product, there are four code items: ConfigApp.app, Core.framework, Share.appex, and Daemon. For each code item, determine the following: Is it bundled code? Is it a main executable? IMPORTANT For a code item to be considered bundled code it must be the main code within a bundle. If, for example, you have an app with a nested helper tool, there are two code items: the app and the helper tool. The app is considered bundle code but the helper tool is not. In some cases, it might not be obvious whether the code item is a main executable. To confirm, run the file command. A main executable says Mach-O … executable. For example: % file "to-be-signed/ConfigApp.app/Contents/Frameworks/Core.framework/Versions/A/Core" … … Mach-O 64-bit dynamically linked shared library x86_64 … % file "to-be-signed/ConfigApp.app/Contents/PlugIns/Share.appex/Contents/MacOS/Share" … … Mach-O 64-bit executable x86_64 … The Core.framework is not a main executable but Share.appex is. To continue the DaemonWithApp example, here’s a summary of this info for each of its code items: | Code Item | Bundled Code? | Main Executable | | --------- | ------------- | --------------- | | ConfigApp.app | yes | yes | | Core.framework | yes | no | | Share.appex | yes | yes | | Daemon | no | yes | Determine the Signing Order Sign code from the inside out. That is, if A depends on B, sign B before you sign A. For the DaemonWithApp example, the signing order for the app is: Core.framework Share.appex ConfigApp.app The app and daemon are independent, so you can sign them in either order. Configure Your Entitlements A code signature may include entitlements. These key-value pairs grant an executable permission to use a service or technology. For more information about this, see Entitlements. Entitlements only make sense on a main executable. When a process runs an executable, the system grants the process the entitlements claimed by its code signature. Do not apply entitlements to library code. It doesn’t do anything useful and can prevent your code from running. When signing a main executable, decide whether it needs entitlements. If so, create an entitlements file to use when signing that executable. This entitlements file is a property list containing the key-value pairs for the entitlements that the executable claims. If you build your product with Xcode, you might be able to use the .entitlements file that Xcode manages in your source code. If not, create the .entitlements file yourself. IMPORTANT The entitlements file must be a property list in the standard XML format with LF line endings, no comments, and no BOM. If you’re not sure of the file’s provenance, use plutil to convert it to the standard format. For specific instructions, see Ensure Properly Formatted Entitlements. If you have a development-signed version of your program you can get a head start on this by dumping its entitlements. For example: % codesign -d --entitlements - --xml "to-be-signed/ConfigApp.app" | plutil -convert xml1 -o - - … &lt;dict&gt; &lt;key&gt;com.apple.application-identifier&lt;/key&gt; &lt;string&gt;SKMME9E2Y8.com.example.apple-samplecode.DaemonWithApp.App&lt;/string&gt; &lt;key&gt;com.apple.developer.team-identifier&lt;/key&gt; &lt;string&gt;SKMME9E2Y8&lt;/string&gt; &lt;key&gt;com.apple.security.app-sandbox&lt;/key&gt; &lt;true/&gt; &lt;key&gt;keychain-access-groups&lt;/key&gt; &lt;array&gt; &lt;string&gt;SKMME9E2Y8.com.example.apple-samplecode.DaemonWithApp.SharedKeychain&lt;/string&gt; &lt;/array&gt; &lt;/dict&gt; &lt;/plist&gt; Keep in mind that some entitlements vary between development and distribution builds. For example: The value of the APS Environment (macOS) Entitlement changes from development to production. The com.apple.security.get-task-allow entitlement allows the debugger to attach to your program, so you rarely apply it to a distribution-signed program. To check whether an entitlement varies in distribution builds, see the documentation for that specific entitlement in Entitlements. For information about when it makes sense to distribute a program signed with the get-task-allow entitlement, see Avoid the Get-Task-Allow Entitlement section in Resolving Common Notarization Issues). Embed Distribution Provisioning Profiles In general, all entitlement claims must be authorized by a provisioning profile. This is an important security feature. For example, the fact that the keychain-access-groups entitlement must be authorized by a profile prevents other developers from shipping an app that impersonates your app in order to steal its keychain items. However, macOS allows programs to claim some entitlements without such authorization. These unrestricted entitlements include: com.apple.security.get-task-allow com.apple.security.application-groups Those used to enable and configure the App Sandbox Those used to configure the Hardened Runtime If your program claims a restricted entitlement, include a distribution provisioning profile to authorize that claim: Create the profile on the developer web site. Copy that profile into your program’s bundle. Note If your product includes a non-bundled executable that uses a restricted entitlement, package that executable in an app-like structure. For details on this technique, see Signing a Daemon with a Restricted Entitlement. To create a distribution provisioning profile, follow the instructions in Developer Account Help. Make sure to choose a profile type that matches your distribution channel (Mac App Store or Developer ID). Once you have a distribution provisioning profile, copy it into your program’s bundle. For information about where to copy it, see Placing Content in a Bundle. To continue the DaemonWithApp example, the configuration app and its share extension use a keychain access group to share secrets. The system grants the programs access to that group based on their keychain-access-groups entitlement claim, and such claims must be authorized by a provisioning profile. The app and the share extension each have their own profile. To distribute the app, update the app and share extension bundles with the corresponding distribution provisioning profile: % cp "ConfigApp-Dist.provisionprofile" "to-be-signed/ConfigApp.app/Contents/embedded.provisionprofile" % cp "Share-Dist.provisionprofile" "to-be-signed/ConfigApp.app/Contents/PlugIns/Share.appex/Contents/embedded.provisionprofile" Modifying the app in this way will break the seal on its code signature. This is fine because you are going to re-sign the app before distributing it. IMPORTANT If you’re building your product with Xcode then you might find that Xcode has embedded a provisioning profile within your bundle. This is a development provisioning profile. You must replace it with a distribution provisioning profile. Sign Each Code Item For all code types, the basic codesign command looks like this: % codesign -s III PPP Here III is the name of the code signing identity to use and PPP is the path to the code to sign. The specific identity you use for III varies depending on your distribution channel, as discussed in Confirm Your Code Signing, above. Note If you have multiple identities with the same name, supply the identity’s SHA-1 hash to specify it unambiguously. For information on how to get this hash, see Confirm Your Code Signing, above. When signing bundled code, as defined in Identify the Code to Sign, above, use the path to the bundle for PPP, not the path to the bundle’s main code. If you’re re-signing code — that is, the code you’re signing is already signed — add the -f option. If you’re signing a main executable that needs entitlements, add the --entitlements EEE option, where EEE is the path to the entitlements file for that executable. For information on how to create this file, see Configure Your Entitlements, above. If you’re signing for Developer ID distribution, add the --timestamp option to include a secure timestamp. If you’re signing a main executable for Developer ID distribution, add the -o runtime option to enable the Hardened Runtime. For more information about the Hardened Runtime, see Hardened Runtime. If you’re signing non-bundled code, add the -i BBB option to set the code signing identifier. Here BBB is the bundle ID the code would have if it had a bundle ID. For example, if you have an app whose bundle ID is com.example.flying-animals that has a nested command-line tool called pig-jato, the bundle ID for that tool would logically be com.example.flying-animals.pig-jato, and that’s a perfectly fine value to use for BBB. Note For bundled code, you don’t need to supply a code signing identifier because codesign defaults to using the bundle ID. Repeat this signing step for every code item in your product, in the order you established in Determine the Signing Order, above. If you have a complex product with many code items to sign, create a script to automate this process. Here's the complete sequence of commands to sign the DaemonWithApp example for Developer ID distribution: % codesign -s "Developer ID Application" -f --timestamp "to-be-signed/ConfigApp.app/Contents/Frameworks/Core.framework" to-be-signed/ConfigApp.app/Contents/Frameworks/Core.framework: replacing existing signature % codesign -s "Developer ID Application" -f --timestamp -o runtime --entitlements "Share.entitlements" "to-be-signed/ConfigApp.app/Contents/PlugIns/Share.appex" to-be-signed/ConfigApp.app/Contents/PlugIns/Share.appex: replacing existing signature % codesign -s "Developer ID Application" -f --timestamp -o runtime --entitlements "ConfigApp.entitlements" "to-be-signed/ConfigApp.app" to-be-signed/ConfigApp.app: replacing existing signature % codesign -s "Developer ID Application" -f --timestamp -o runtime -i "com.example.apple-samplecode.DaemonWithApp.Daemon" "to-be-signed/Daemon" to-be-signed/Daemon: replacing existing signature Consider Deep Harmful When signing code, do not pass the --deep option to codesign. This option is helpful in some specific circumstances but it will cause problems when signing a complex product. Specifically: It applies the same code signing options to every code item that it signs, something that’s not appropriate. For example, you might have an app with an embedded command-line tool, where the app and the tool need different entitlements. The --deep option will apply the same entitlements to both, which is a serious mistake. It only signs code that it can find, and it only finds code in nested code sites. If you put code in a place where the system is expecting to find data, --deep won’t sign it. The first issue is fundamental to how --deep works, and is the main reason you should avoid it. The second issue is only a problem if you don’t follow the rules for nesting code and data within a bundle, as documented in Placing Content in a Bundle.

hi, When I try to run myApp, one of the dynamic libraries fails to load,and app exit, because it was blocked by code signing.myApp has been signed and notarized,and both valid. Here is the message I get: apple@appledeiMac ~ % /Users/apple/Desktop/workspace/code/myApp.app/Contents/MacOS/mCloud ; exit; dyld: Library not loaded: @executable_path/../Frameworks/libbase.1.dylib Referenced from: /Users/apple/Desktop/workspace/code/myApp.app/Contents/MacOS/mCloud Reason: no suitable image found. Did find: /Users/apple/Desktop/workspace/code/myApp.app/Contents/MacOS/../Frameworks/libbase.1.dylib: code signing blocked mmap() of '/Users/apple/Desktop/workspace/code/myApp.app/Contents/MacOS/../Frameworks/libbase.1.dylib' /Users/apple/Desktop/workspace/code/myApp.app/Contents/MacOS/../Frameworks/libbase.1.dylib: stat() failed with errno=1 /Users/apple/Desktop/workspace/code/myApp.app/Contents/MacOS/../Frameworks/libbase.1.dylib: code signing blocked mmap() of '/Users/apple/Desktop/workspace/code/myApp.app/Contents/MacOS/../Frameworks/libbase.1.dylib' /Users/apple/Desktop/workspace/code/myApp.app/Contents/MacOS/../Frameworks/libbase.1.dylib: stat() failed with errno=1 file system relative paths not allowed in hardened programs What is happening, and what should I do about it? I was able to get the application notarized with the com.apple.security.cs.disable-library-validation entitlement. I'm using Qt5.14.2 ,macOs 10.15.7,xcode 11.5. Thanks, Ulyssess

Hi!The problem I want to discuss is not new, but it is becoming more and more critical for the project I'm working on. So I have to rise it again.Our project is a virtual webcam for macOS implemented as a CoreMedia I/O DAL plug-in. Plug-in is installed at /Library/CoreMediaIO/Plug-Ins/DAL and can be loaded into any client application that wants to use the webcam.The problem appeared when Apple introduced 'Hardened Runtime' in macOS Mojave which by default turns on 'Library Validation' feature. Library validation disables loading for frameworks/plugins/libraries which are either: 1) not signed; 2) signed but 'Team Identifier' in signing certificate is different than certificate of a client application signature. As a result, even though our plugin is properly signed and notarized, it can't be loaded into client application with hardened runtime because of that 2nd case.First alarming incident was last year when Google Chrome on macOS enabled hardened runtime, and stopped showing our webcam in the list. I requested a technical support (case ID for TSI: 718328224), then made a feedback to Apple (FB7071665) about any possible solutions for our case, at least in the future versions of macOS. But I see there's still no reaction there.Now things are getting worse. Skype and Zoom stopped support our webcam for the same reason. Some others announced they will do this too. There's a possibility to add 'com.apple.security.cs.disable-library-validation' entitlement to the client application - that would help with our issue. But Zoom and Skype refuse to add this because of security reasons - after some security exploits were uncovered.The situation is quite critical for our product as many users use our webcam only for Zoom, Skype and similar applications.So, the question is: are there any possible workarounds for our case? I know that for audio plugins (VST, etc.) there's a special entitlement: 'com.apple.security.temporary-exception.audio-unit-host' that allows loading even unsigned plugins into hosting application. Why there's no such entitlement for DAL plugins? Or will it appear in macOS 10.16? I think it would be reasonable to add an entitlement that would only reject loading of unsigned plugins, but would allow loading of plugins with different 'Team ID' in signing certificate.